MongoDB添加secondary节点的两种方法

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

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

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

　　不一样的业务场景应用不一样的架构策略，扩充secondary节点有时候不能解决问题，尤为是那些实时性很高的业务，但有时候扩充secondary节点确实有效，好比硬件升级后须要作的服务迁移，须要在线扩充secondary节点来知足业务须要的更高的硬件要求。

    MongoDB的secondary节点的扩充，我总结起来有两种方式：一、rs.add()直接扩充 二、一致性备份后进行扩充（我的叫法）

　　一、rs.add("HOST_NAME:PORT")

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

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

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

   二、一致性快照快速添加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添加进集群并观察同步状态、校验数据的完整和一致性

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

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

 

 1 #primary节点或者其余secondary节点备份数据
 2 [root@172-16-3-190 mongodb]# /opt/app/mongodb/bin/mongodump -uroot -ppwd4mysql --authenticationDatabase=admin --port=27017 --oplog -o /tmp/dump_mongo/
 3 2018-08-20T15:42:47.028+0800 writing admin.system.users to 
 4 2018-08-20T15:42:47.030+0800 done dumping admin.system.users (1 document)
 5 2018-08-20T15:42:47.030+0800 writing admin.system.version to 
 6 2018-08-20T15:42:47.031+0800 done dumping admin.system.version (2 documents)
 7 2018-08-20T15:42:47.032+0800 writing super_hero.user_address to 
 8 2018-08-20T15:42:47.032+0800 writing super_hero.user_info to 
 9 2018-08-20T15:42:47.033+0800 done dumping super_hero.user_address (1 document)
10 2018-08-20T15:42:47.033+0800 done dumping super_hero.user_info (1 document)
11 2018-08-20T15:42:47.034+0800 writing captured oplog to 
12 2018-08-20T15:42:47.036+0800 dumped 1 oplog entry
13 
14 #查看备份的文件
15 [root@172-16-3-190 mongodb]# ls -lh /tmp/dump_mongo/
16 total 12K
17 drwxr-xr-x 2 root root 4.0K Aug 20 15:42 admin
18 -rw-r--r-- 1 root root 110 Aug 20 15:42 oplog.bson
19 drwxr-xr-x 2 root root 4.0K Aug 20 15:42 super_hero
20 
21 #传递备份到准备添加为secondary的节点上
22 [root@172-16-3-190 tmp]# scp -r -P22222 /tmp/dump_mongo/ liyingxiao@172.16.3.189:/tmp

 

二、secondary节点一致性快照恢复

 1 #auth=true
 2 #replSet = repl_mongo
 3 #clusterAuthMode=keyFile
 4 #keyFile=/opt/app/mongodb/keyfile/mongodb.key
 5 
 6 ##恢复数据
 7 [root@172-16-3-189 we_ops_admin]# /opt/app/mongodb/bin/mongorestore --oplogReplay --port=27017 /tmp/dump_mongo/                                          
 8 2018-08-20T15:56:32.161+0800 preparing collections to restore from
 9 2018-08-20T15:56:32.193+0800 reading metadata for super_hero.user_info from /tmp/dump_mongo/super_hero/user_info.metadata.json
10 2018-08-20T15:56:32.194+0800 reading metadata for super_hero.user_address from /tmp/dump_mongo/super_hero/user_address.metadata.json
11 2018-08-20T15:56:32.222+0800 restoring super_hero.user_address from /tmp/dump_mongo/super_hero/user_address.bson
12 2018-08-20T15:56:32.300+0800 restoring super_hero.user_info from /tmp/dump_mongo/super_hero/user_info.bson
13 2018-08-20T15:56:32.867+0800 no indexes to restore
14 2018-08-20T15:56:32.867+0800 finished restoring super_hero.user_address (1 document)
15 2018-08-20T15:56:32.881+0800 no indexes to restore
16 2018-08-20T15:56:32.881+0800 finished restoring super_hero.user_info (1 document)
17 2018-08-20T15:56:32.881+0800 restoring users from /tmp/dump_mongo/admin/system.users.bson
18 2018-08-20T15:56:32.993+0800 replaying oplog
19 2018-08-20T15:56:32.997+0800 done

三、初始化oplog.rs集合，并恢复oplog记录

　　建立oplog.rs集合并初始化大小

1 use local
2 db.createCollection("oplog.rs",{"capped":true,"size":100000000})

　　恢复一致性备份的oplog.rs集合的数据到secondary节点

1 [root@172-16-3-189 we_ops_admin]# /opt/app/mongodb/bin/mongorestore -d local -c oplog.rs --port=27017 /tmp/dump_mongo/oplog.bson  
2 2018-08-20T16:12:49.848+0800 checking for collection data in /tmp/dump_mongo/oplog.bson
3 2018-08-20T16:12:49.852+0800 restoring local.oplog.rs from /tmp/dump_mongo/oplog.bson
4 2018-08-20T16:12:49.925+0800 no indexes to restore
5 2018-08-20T16:12:49.925+0800 finished restoring local.oplog.rs (1 document)
6 2018-08-20T16:12:49.925+0800 done

四、初始化db.replset.election，db.system.replset集合，其中replset.election须要查询主节点数据并将这些数据存储到secondary节点，或者两个结合自行save到secondary节点。另集合system.replset加入复制集后可自动识别primary节点内容（这里我采起自行同步数据）

1 #primary节点
2 repl_mongo:PRIMARY> db.replset.election.find()
3 { "_id" : ObjectId("5b7a6ee5de7a24b82a686139"), "term" : NumberLong(1), "candidateIndex" : NumberLong(0) }
4 #secondary节点
5 db.replset.election.save({ "_id" : ObjectId("5b7a6ee5de7a24b82a686139"), "term" : NumberLong(1), "candidateIndex" : NumberLong(0) })

五、修改数据库配置并重启，添加secondary节点到复制集群中

#auth=true
#replSet = repl_mongo
#clusterAuthMode=keyFile
#keyFile=/opt/app/mongodb/keyfile/mongodb.key

[root@172-16-3-189 we_ops_admin]# /opt/app/mongodb/bin/mongod --shutdown -f /opt/app/mongodb/mongo.conf 
killing process with pid: 5331
[root@172-16-3-189 we_ops_admin]# vim /opt/app/mongodb/mongo.conf  #注释去掉并重启
[root@172-16-3-189 we_ops_admin]# /opt/app/mongodb/bin/mongod -f /opt/app/mongodb/mongo.conf            
about to fork child process, waiting until server is ready for connections.
forked process: 5722
child process started successfully, parent exiting

#添加secondary节点
repl_mongo:PRIMARY> rs.add({"_id":1,"host":"172.16.3.189:27017"})
{
        "ok" : 1,
        "operationTime" : Timestamp(1534752953, 1),
        "$clusterTime" : {
                "clusterTime" : Timestamp(1534752953, 1),
                "signature" : {
                        "hash" : BinData(0,"Tt9nzhoVYdUtGFZnc1Kg1exl0Hc="),
                        "keyId" : NumberLong("6591702943026642945")
                }
        }
}

六、登陆添加的secondary节点，验证复制集状态，数据完整和一致性。

1 [root@172-16-3-189 we_ops_admin]# /opt/app/mongodb/bin/mongo -uroot -ppwd4mysql --authenticationDatabase=admin --port=27017

　　重点介绍第二种省时省心但费力费操做的添加secondary节点的方法，实践过程当中数据库实例前期去掉认证和复制集参数，是方便咱们下面的一些须要用户权限的操做，避免创建管理员帐号，后续加入集群后自行同步了primary节点的帐号。重启后登陆secondary节点验证服务的可用性和数据一致性时，使用集群的管理帐号进入，不然会报认证的错误。

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