mongoDB 复制集的维护过程中，我们经常会遇到这样的需求：

1. 新增 secondary节点
2. 将 primary或secondary节点迁移到其他新机器

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

1、rs.add()直接添加
2、冷拷贝数据、启动、添加 （适用于 主-从-从 PSS架构）
3、热拷贝数据、启动、添加（适用于主-从-仲裁 PSA架构）

1、rs.add()直接添加

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

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

全量同步期间，集群的负载会变高，如果业务程序的read_timeout 、write_timeout 设置的比较低可能会有感知，对此可以调大业务程序链接mongoDB的几个timeout参数，尽量在业务低峰期操作。

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

2、冷拷贝数据、启动、添加 （适用于 主-从-从 PSS架构）

生产上大库（例如1T以上）的加节点，建议采样下面的方法：

假设节点标识为：主节点：M ， 2个备节点：S1 S2 ， 新加入的节点为S3
注：生产基本上都是一主两备（PSS架构），如果还是一主一备一仲裁(PSA架构)，建议乘早改掉，官方都不推荐了。

1、关停一个从节点S1的MongoDB进程

2、scp拷贝这个S1的数据到新的节点S3

3、启动step1关停的从节点S1的MongoDB进程，自动加回集群

4、启动新的节点S3的MongoDB进程

5、在原先的主节点M上，执行添加S3节点的操作

6、S3节点会加入后会根据oplog中的信息，尝试增量同步，等一段时间完成增量同步后即可加入集群

oplog 在MongoDB>=3.6+ 版本（希望没记错）已经可以在线调整了。
看下当前的oplog存多久的，就可估算出能不能撑到拷完数据，如果担心不够大就先在线调整下就行。

oplog是MongoDB数据库的操作日志，记录了MongoDB数据库的所有写操作，类似MySQL数据库的binlog日志。
在MongoDB副本集中，oplog从主节点被复制到次级节点，通过次级节点对日志进行重做，实现次级节点与主节点数据一致。
oplog日志保存在local.oplog.rs集合中。

oplog大小修改根据数据库版本，有2种不同的方法：

在MongoDB 3.4及更早的版本中，直接删除并重建local.oplog.rs集合来调整操作日志的大小；
在MongoDB 3.6及后续的版本中，使用replSetResizeOplog命令来调整操作日志的大小；
从MongoDB 4.0开始，MongoDB禁止删除local.oplog.rs集合，所以只能用replSetResizeOplog来修改oplog的大小了。

这里演示在MongoDB 4.2版本上修改oplog的大小，先在次级节点上修改操作日志的大小，最后在主机点上修改。

1. 登录 从节点
$ mongo --host xx.xx.xx  --port   27.07  -u username  -p 'passwd'   --authenticationDatabase admin

2. 开启从节点可写，在线调整oplog大小
>  rs.slaveOk()
> use local
> db.oplog.rs.stats().maxSize
NumberLong(1970031616) 

注：修改副本集节点oplog的大小，oplog必须大于990MB,这里改为100G

> db.adminCommand({replSetResizeOplog:1,size:10000})
 {
     "ok" : 1,
     "$clusterTime" : {
         "clusterTime" : Timestamp(1593527768, 1),
         "signature" : {
             "hash" : BinData(0,"7fw3+0veB35tVTFl83c57kvM0OI="),
             "keyId" : NumberLong("6841443127941660675")
         }
     },
     "operationTime" : Timestamp(1593527768, 1)
 }

3. 压缩oplog.rs以回收磁盘空间（可选）
>  use local
> db.runCommand({"compact" : "oplog.rs"})

注： 当执行压缩时，副本集成员无法复制oplog条目，可能会导致主节点的操作日志被覆盖，从节点无法同步数据而产生重新完全同步，建议在无业务的时间段内执行压缩操作

3、热拷贝数据、启动、添加（适用于主-从-仲裁 PSA架构）

如果是 PSA架构，没有secondary 节点可以停了用于数据的冷拷贝，有担心直接添加secondary节点，在同步完数据前MongoDB的oplog被覆盖同步失败，那么可以考虑将现有主/从节点数据导出，灌到新的从节点，然后将新的从节点加入集群。

1. 用mongodump 将所有数据从现有的有主/从节点数据导出
2.启动新的从节点（不开启热证），用 mongorestore 将导出的数据导入到新的从节点
3. 将新的从节点加入集群，开启认证，重启新的从节点

践过程中数据库实例前期去掉认证和复制集参数，是方便我们下面的一些需要用户权限的操作，避免建立管理员账号，后续加入集群后自行同步了primary节点的账号。
重启后登录secondary节点验证服务的可用性和数据一致性时，使用集群的管理账号进入，否则会报认证的错误。

第1种方式操作时间周期长，不可控的影响范围大费时费精力

对3种方式，操作繁琐但不用担心oplog被覆盖，且操作期间不会过多担忧网络流量的问题，仅仅考虑网络传输的流量影响。
操作时间短，操作的步骤多，容易出现其他问题。

能用上第2种，尽量用第2，省时问题少！

参考

复制集指南 > 复制集维护教程 > 修改Oplog大小
https://mongoing.com/docs/tutorial/change-oplog-size.html

MongoDB 中文手册
(MongoDB 4.2发布于2019年8月13日)
https://mongodb.net.cn/manual

MongoDB添加secondary节点的两种方法
https://www.cnblogs.com/liyingxiao/p/9768003.html

MongoDB更改oplog的大小
https://www.cnblogs.com/lijiaman/p/13215564.html

调整 Oplog 占用容量
https://cloud.tencent.com/document/product/240/76746