CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章MongoDB添加secondary节点的2种方法详解由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

前言 。

前段时间维护的一个事业群的其中一条业务线的开发找到运维，提出来了一个MongoDB的优化问题，那段时间MongoDB正在从op管理移交给db进行维护，整个部门都对MongoDB的运维经验缺乏，MongoDB的优化更是一个未知的挑战。当op找到我，核心系统的公共服务平台用来进行短信服务的MongoDB集群想进行一次优化，我当仁不能让的承担了这项我都觉得可能搞不定的任务.

开发找到我提出了两点儿问题，并寻求运维团队解决这个问题，不过最终在我的理性的思考和他感性的思维碰撞下，最终我还是以胜利者的姿态胜出。我成功说服了他，并解答了他一些疑问，得到了满意的答复后再也没找我了。当然这里肯定不会就凭几句话，任你理论再怎么丰富，态度如何暧昧，不拿点儿真实数据，做点儿什么，怎么能说服经验丰富的开发认定的事儿。沟通了大半天，占据了我白天的工作时间，不过他提出来的问题还是很值得讨论.

根据开发的逻辑，是想横向扩充secondary节点，把其他要求不高的业务放到secondary节点上，减轻primary节点的压力，达到部分读写分离，使得主要业务优先保障。我觉得这个出发点是好的，但并没有就此作出回应，其一是他没有认识到这个他认为的有延迟并不是数据库集群的问题（这里不详细讲述排查的过程，下一篇文章会讲些MongoDB的写入与业务逻辑），其二是我们确实缺乏有效的资源硬件去进行扩充节点.

不同的业务场景应用不同的架构策略，扩充secondary节点有时候不能解决问题，尤其是那些实时性很高的业务，但有时候扩充secondary节点确实有效，比如硬件升级后需要做的服务迁移，需要在线扩充secondary节点来满足业务需要的更高的硬件要求.

MongoDB的secondary节点的扩充，我总结起来有两种方式:

1、rs.add()直接扩充 。

2、一致性备份后进行扩充（个人叫法） 。

1、rs.add("HOST_NAME:PORT") 。

具体的实现方式是登陆扩充节点的机器，编辑好配置文件，并建立相应的目录和权限，启动MongoDB实例就可以了.

需要注意的一点儿是这种扩充方式要保证同步源的数据量级，即保证在同步完数据前MongoDB的oplog不会被覆盖，这点儿类似与MySQL的redo log日志，如果被覆盖那么同步的数据出现不一致，导致同步失败.

需要注意的另一点是同步数据的过程中，当集群数据达到一定量级时，同步数据的大小很大就会对网络造成一定的压力，可能对业务的核心交换机造成影响，因此需要用TC工具对同步流量做限速处理。这个限速需要考虑同步源可能不会是primary，也可能是同样角色的secondary节点，令外限速同步势必会增大同步时间，这个会增大oplog被覆盖的概率，具体限速值还是要经过计算才能把握好.

2、一致性快照快速添加secondary节点（自我命名，欢迎各位交流） 。

　 a)primary节点上进行一致性快照备份 。

　 b)secondary节点上进行一致性快照恢复，仅仅对数据部分进行恢复，暂时不要对oplog进行恢复 。

     c)初始化oplog.rs集合，并恢复oplog记录 。

     d)初始化local数据库的其他两个集合db.replset.election，db.system.replset 。

　 e)修改数据库配置并重启数据库（这一步操作前实例不开启认证模式、复制集的配置）,rs.add("HOST_NAME:PORT")将secondary添加进集群并观察同步状态、校验数据的完整和一致性 。

实践的详细实践过程如下（仅供参考交流，生产环境慎用）:

1、primary上进行一致性快照备份 。

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的节点目录中

总结 。

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对我的支持.

原文链接：http://www.cnblogs.com/liyingxiao/p/9768003.html 。

最后此篇关于MongoDB添加secondary节点的2种方法详解的文章就讲到这里了,如果你想了解更多关于MongoDB添加secondary节点的2种方法详解的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。