前段时间维护的一个事业群的其中一条业务线的开发找到运维，提出来了一个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、一致性备份后扩充

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

       b)secondary节点上进行一致性快照恢复

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

       d)rs.add("HOST_NAME:PORT")将secondary添加进集群并观察同步状态、校验数据的完整和一致性

　　总结如上两种扩充方式，对于方式1的扩充简单省事，需要保证oplog不被覆盖和评估同步流量的影响问题，是我们通常进行横向复制集添加secondary节点的方法。对于第二种方式，操作繁琐但不用担心oplog被覆盖，且操作期间不会过多担忧网络流量的问题，仅仅考虑网络传输的流量影响。第一种方式操作时间周期长，不可控的影响范围大费时费精力，第二种方式操作时间短，操作的步骤多，容易出现其他问题。