前段时间维护的一个事业群的其中一条业务线的开发找到运维,提出来了一个MongoDB的优化问题,那段时间MongoDB正在从op管理移交给db进行维护,整个部门都对MongoDB的运维经验缺乏,MongoDB的优化更是一个未知的挑战。当op找到我,核心系统的公共服务平台用来进行短信服务的MongoDB集群想进行一次优化,我当仁不能让的承担了这项我都觉得可能搞不定的任务。
开发找到我提出了两点儿问题,并寻求运维团队解决这个问题,不过最终在我的理性的思考和他感性的思维碰撞下,最终我还是以胜利者的姿态胜出。我成功说服了他,并解答了他一些疑问,得到了满意的答复后再也没找我了。当然这里肯定不会就凭几句话,任你理论再怎么丰富,态度如何暧昧,不拿点儿真实数据,做点儿什么,怎么能说服经验丰富的开发认定的事儿。沟通了大半天,占据了我白天的工作时间,不过他提出来的问题还是很值得讨论。
根据开发的逻辑,是想横向扩充第二节点,把其他要求不高的业务放到第二节点上,减轻主要节点的压力,达到部分读写分离,使得主要业务优先保障。我觉得这个出发点是好的,但并没有就此作出回应,其一是他没有认识到这个他认为的有延迟并不是数据库集群的问题(这里不详细讲述排查的过程,下一篇文章会讲些MongoDB的写入与业务逻辑),其二是我们确实缺乏有效的资源硬件去进行扩充节点。
不同的业务场景应用不同的架构策略,扩充第二节点有时候不能解决问题,尤其是那些实时性很高的业务,但有时候扩充第二节点确实有效,比如硬件升级后需要做的服务迁移,需要在线扩充第二节点来满足业务需要的更高的硬件要求。
<强> MongoDB的二级节点的扩充,我总结起来有两种方式:
1, rs.add()直接扩充
2,一致性备份后进行扩充(一个人叫法)
具体的实现方式是登陆扩充节点的机器,编辑好配置文件,并建立相应的目录和权限,启动MongoDB实例就可以了。
需要注意的一点儿是这种扩充方式要保证同步源的数据量级,即保证在同步完数据前MongoDB的oplog不会被覆盖,这点儿类似与MySQL的重做日志日志,如果被覆盖那么同步的数据出现不一致,导致同步失败。
需要注意的另一点是同步数据的过程中,当集群数据达到一定量级时,同步数据的大小很大就会对网络造成一定的压力,可能对业务的核心交换机造成影响,因此需要用TC工具对同步流量做限速处理。这个限速需要考虑同步源可能不会是主要的,也可能是同样角色的第二节点,令外限速同步势必会增大同步时间,这个会增大oplog被覆盖的概率,具体限速值还是要经过计算才能把握好。
)主要节点上进行一致性快照备份
b)第二节点上进行一致性快照恢复,仅仅对数据部分进行恢复,暂时不要对oplog进行恢复
,,,,c)初始化oplog.rs集合,并恢复oplog记录
,,,,d)初始化当地数据库的其他两个集合db.replset.election, db.system.replset
e)修改数据库配置并重启数据库(这一步操作前实例不开启认证模式,复制集的配置),rs.add (“HOST_NAME:港口”)将辅助添加进集群并观察同步状态,校验数据的完整和一致性
1,主要上进行一致性快照备份
