2、secondary节点一致性快照恢复
3、初始化oplog.rs集合，并恢复oplog记录
创建oplog.rs集合并初始化大小
恢复一致性备份的oplog.rs集合的数据到secondary节点
4、初始化db.replset.election，db.system.replset集合，其中replset.election需要查询主节点数据并将这些数据存储到secondary节点，或者两个结合自行save到secondary节点。另集合system.replset加入复制集后可自动识别primary节点内容（这里我采取自行同步数据）
5、修改数据库配置并重启，添加secondary节点到复制集群中
6、登录添加的secondary节点，验证复制集状态，数据完整和一致性。
重点介绍第二种省时省心但费力费操作的添加secondary节点的方法，实践过程中数据库实例前期去掉认证和复制集参数，是方便我们下面的一些需要用户权限的操作，避免建立管理员账号，后续加入集群后自行同步了primary节点的账号。重启后登录secondary节点验证服务的可用性和数据一致性时，使用集群的管理账号进入，否则会报认证的错误。
总结如上两种扩充方式，对于方式1的扩充简单省事，需要保证oplog不被覆盖和评估同步流量的影响问题，是我们通常进行横向复制集添加secondary节点的方法。对于第二种方式，操作繁琐但不用担心oplog被覆盖，且操作期间不会过多担忧网络流量的问题，仅仅考虑网络传输的流量影响。第一种方式操作时间周期长，不可控的影响范围大费时费精力，第二种方式操作时间短，操作的步骤多，容易出现其他问题。
MongoDB secondary节点出现recovering状态
MongoDB做了replica sets之后,secondary节点出现recovering状态
在一次mongo集群挂掉后，重启，发现有一台服务器的mongo节点一直处于recovering状态，不能变为secondary或者primary。
查询官方文档后，找到解决方案，在此记录。
出现原因
备份节点的工作原理过程可以大致描述为，备份节点定期轮询主节点上的数据操作，然后对自己的数据副本进行这些操作，从而保证跟主节点的数据同步。
至于主节点上的所有数据库状态改变的操作，都会存放在一张特定的系统表中。备份节点则是根据这些数据进行自己的数据更新。
上面提到的数据库状态改变的操作，称为oplog（operation log，主节点操作记录）。oplog存储在local数据库的"oplog.rs"表中。副本集中备份节点异步的从主节点同步oplog，然后重新执行它记录的操作，以此达到了数据同步的作用。
关于oplog有几个注意的地方：
oplog只记录改变数据库状态的操作 存储在oplog中的操作并不是和主节点执行的操作完全一样，例如"$inc"操作就会转化为"$set"操作 oplog存储在固定集合中(capped collection)，当oplog的数量超过oplogSize，新的操作就会覆盖旧的操作数据同步
在副本集中，有两种数据同步方式：
initial sync（初始化）：这个过程发生在当副本集中创建一个新的数据库或其中某个节点刚从宕机中恢复，或者向副本集中添加新的成员的时候，默认的，副本集中的节点会从离它最近的节点复制oplog来同步数据，这个最近的节点可以是primary也可以是拥有最新oplog副本的secondary节点。 该操作一般会重新初始化备份节点，开销较大 replication（复制）：在初始化后这个操作会一直持续的进行着,以保持各个secondary节点之间的数据同步。initial sync
当遇到上面例子中无法同步的问题时，只能使用以下两种方式进行initial sync了
第一种方式就是停止该节点，然后删除目录中的文件，重新启动该节点。这样，这个节点就会执行initial sync 注意：通过这种方式，sync的时间是根据数据量大小的，如果数据量过大，sync时间就会很长 同时会有很多网络传输，可能会影响其他节点的工作 第二种方式，停止该节点，然后删除目录中的文件，找一个比较新的节点，然后把该节点目录中的文件拷贝到要sync的节点目录中总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对七叶笔记的支持。
