共计 6769 个字符，预计需要花费 17 分钟才能阅读完成。
【问题说明】
在生产环境新增 secondary：10.9.197.6:27017，数据量 140G，却同步了一天还未追上数据，通过如下方式查看同步情况：
查看主从复制状态命令，以下两种方式结果是一致的：
方式一：
use admin
db.runCommand({ replSetGetStatus : 1} )
指定的值不会影响命令的输出。此命令提供的数据源自于包含在由副本集的其他成员发送到当前实例的心跳中的数据。由于心跳的频率，这些数据可能是几秒钟过期。详情请参考官档：https://docs.mongodb.com/manual/reference/command/replSetGetStatus/
方式二：
rs.status()
查看复制状态，发现状态是 ”stateStr” : “RECOVERING”。信息为 ”infoMessage” : “could not find member to sync from”，使用 rs.syncFrom(“10.9.161.130:27017”) 也无法让其继续正常同步。具体信息如下：
kk-comic-shard01:RECOVERING> rs.status()
{
“set” : “kk-comic-shard01”,
“date” : ISODate(“2017-02-07T02:12:17.613Z”),
“myState” : 3,
“term” : NumberLong(5),
“heartbeatIntervalMillis” : NumberLong(2000),
“members” : [
{
“_id” : 2,
“name” : “10.9.95.69:27017”,
“health” : 1,
“state” : 7,
“stateStr” : “ARBITER”,
“uptime” : 41966,
“lastHeartbeat” : ISODate(“2017-02-07T02:12:14.490Z”),
“lastHeartbeatRecv” : ISODate(“2017-02-07T02:12:15.696Z”),
“pingMs” : NumberLong(0),
“configVersion” : 19
},
{
“_id” : 4,
“name” : “10.9.161.130:27017”,
“health” : 1,
“state” : 1,
“stateStr” : “PRIMARY”,
“uptime” : 41966,
“optime” : {
“ts” : Timestamp(1486433534, 636),
“t” : NumberLong(5)
},
“optimeDate” : ISODate(“2017-02-07T02:12:14Z”),
“lastHeartbeat” : ISODate(“2017-02-07T02:12:14.489Z”),
“lastHeartbeatRecv” : ISODate(“2017-02-07T02:12:16.435Z”),
“pingMs” : NumberLong(0),
“electionTime” : Timestamp(1486103572, 783),
“electionDate” : ISODate(“2017-02-03T06:32:52Z”),
“configVersion” : 19
},
{
“_id” : 5,
“name” : “10.9.184.101:27017”,
“health” : 1,
“state” : 2,
“stateStr” : “SECONDARY”,
“uptime” : 41966,
“optime” : {
“ts” : Timestamp(1486433534, 629),
“t” : NumberLong(5)
},
“optimeDate” : ISODate(“2017-02-07T02:12:14Z”),
“lastHeartbeat” : ISODate(“2017-02-07T02:12:14.489Z”),
“lastHeartbeatRecv” : ISODate(“2017-02-07T02:12:16.438Z”),
“pingMs” : NumberLong(0),
“syncingTo” : “10.9.161.130:27017”,
“configVersion” : 19
},
{
“_id” : 6,
“name” : “10.9.197.6:27017”,
“health” : 1,
“state” : 3,
“stateStr” : “RECOVERING”,
“uptime” : 41985,
“optime” : {
“ts” : Timestamp(1486391572, 534),
“t” : NumberLong(5)
},
“optimeDate” : ISODate(“2017-02-06T14:32:52Z”),
“maintenanceMode” : 487,
“infoMessage” : “could not find member to sync from”,
“configVersion” : 19,
“self” : true
}
],
“ok” : 1
}
kk-comic-shard01:RECOVERING> rs.printSlaveReplicationInfo()
source: 10.9.184.101:27017
syncedTo: Tue Feb 07 2017 10:15:24 GMT+0800 (CST)
0 secs (0 hrs) behind the primary
source: 10.9.197.6:27017
syncedTo: Mon Feb 06 2017 22:32:52 GMT+0800 (CST)
42152 secs (11.71 hrs) behind the primary
【问题原因】
主要的最后一个操作是从“2017-02-07T02:12:14.489Z”，而 secondary 最后一个操作是“2017-02-06T14:32:52Z”，大约相差 12 小时。该 window 可能会超过复制 oplog window（oplog 中第一个和最后一个操作条目之间的时间差）。简单地说，在主服务器上有太多的操作以使 secondary 服务器赶不上。
在初始同步期间，secondary 同步来自的数据是给定时间点的数据。当该时间点的数据被同步时，secondary 连接到 oplog 并应用根据 oplog 条目之间在所述时间点进行改变。只要 oplog 保存上述时间点之间的所有操作，就可以正常同步下去。但 OPLOG 的大小有限，它是有上限的固定集合。因此，如果在初始同步期间主机上发生的操作比 oplog 可以保持的更多，最早的操作 ”fade out”。secondary 所有的操作都可以要“构建”相同的数据作为主，拒绝完成同步，状态一直是 RECOVERY 模式。
【解决办法】
经上面分析，有两种解决办法：
方法一：停止应用，这样主库不会有操作，就不会使得 oplogwindow 小于主库的操作。
方法二：调大 oplog 大小
如果不能停库的情况下，显然方法一是不合适的，应该选择方法二：调大 oplog 大小
修改 oplog 大小
方法 1: 不停服务情况下
参考官档：https://docs.mongodb.com/v3.2/tutorial/change-oplog-size/
1 Restart a Secondary in Standalone Mode on a Different Port
1) db.shutdownServer()
2) 用其他端口以单机模式重新启动该实例，不使用 –replSet 参数
方法一：根据生产环境参数文件设置启动 mongo，即将非默认情况参数进行指定
如下参数根据生产参数文件来设置，情况不一：
/data/servers/app/mongodb-3.2.8/bin/mongod –port 37017 –dbpath /data/servers/data/mg27017/data/ –directoryperdb –wiredTigerDirectoryForIndexes –nojournal &
该方法较为麻烦，建议选择下面的方法二：
方法二：将参数文件进行修改：注释 replSet 部分，修改 port 为 37017，然后以改完后的控制文件来启动 mongo
/data/servers/app/mongodb-3.2.8/bin/mongod -f /data/servers/data/mg27017/mongod.conf
下面截图显示的是只要更改的部分，端口号改为任意的没被占用的即可, 此处改为 37017
netstat -anp | grep $port 查看端口号是否已启动
2 Create a Backup of the Oplog (Optional)
在单机模式（非 replSet 方式）下备份该 37017 端口已存在的 oplog,oplog 对应的集合为 local 数据库下的 oplog.rs。下面为具体命令：
/data/servers/app/mongodb-3.2.8/bin/mongodump –db local –collection ‘oplog.rs’ –port 37017 –host=127.0.0.1 -uroot -p111111111 –authenticationDatabase=admin -o /data/servers/data/mg27017/dump
【命令说明】
-o(–out) 是制定输出目录。该目录需要执行备份的用户拥有相应权限，不用提前创建
–authenticationDatabase 是用户名和密码对应的认证数据库，如果环境不需要密码认证，则 -u、-p、–authenticationDatabase 不需要指定
3 Recreate the Oplog with a New Size and a Seed Entry
保存 oplog 中的最后一个条目
登陆 local 数据库
use local
定义对象：db
db = db.getSiblingDB(‘local’)
使用 temp 集合来保存最后一个条目，这个集合保证里面没有数据：db.temp.drop()，在删除前确认下该数据是否可以删除，如果不可以删除，使用另一个集合也是一样的。此处 temp 没有数据
使用 db.collection.save() 方法：找到自然顺序的逆向排序后的最后一个条目，并将其保存到一个临时的集合里面
db.temp.save(db.oplog.rs.find( {}, {ts: 1, h: 1} ).sort({$natural : -1} ).limit(1).next())
插入后结果为
4 Remove the Existing Oplog Collection
删除 local 下的 oplog.rs 集合，结果返回为 true
db = db.getSiblingDB(‘local’)
db.oplog.rs.drop()
5 Create a New Oplog
创建 oplog.rs 固定集合，设置大小为 4G，该大小根据实际情况来定
db.runCommand({ create: “oplog.rs”, capped: true, size: (4* 1024 *1024*1024) } )
6 Insert the Last Entry of the Old Oplog into the New Oplog
将之前保存的 oplog 的最后一个条目插入到新的 oplog 里
db.oplog.rs.save(db.temp.findOne() )
跟 temp 结果比对是一致的
7 Restart the Member
关闭单机实例，要用 admin 才能关闭
use admin
db.shutdownServer()
将之前更改的操作还原，启动 mongo
/data/servers/app/mongodb-3.2.8/bin/mongod -f /data/servers/data/mg27017/mongod.conf
查看主从复制状态，确保状态正常
db.runCommand({ replSetGetStatus : 1} ) 或者 rs.status()
8 Repeat Process for all Members that may become Primary
对要更改 oplog 大小的所有 secondary 成员重复此过程。
9 Change the Size of the Oplog on the Primary
对于主库，需要先将主库切成从库，再重复上述 oplog 调整过程
•方法一：
rs.stepDown()
• 方法二：
config=rs.conf()
config.members[2].priority = 6
rs.reconfig(config)
此处数字 2 为 rs.conf() 里要变成主库的 secondary 所在的次序，从 0 开始算，与 id 无关。priority 数字最大即变成主库。旧的主库调整完后，记得要将 priority 变为 1。
方法 2: 停服务情况下
该方法操作最为简便，但是需要停服务。具体步骤为
1 关闭 mongod 实例 (所有节点)
use admin
db.shutdownServer()
2 删除 local 数据库下的所有文件（PRIMARY 节点）
rm -rf /data/servers/data/mg27017/local/*
3 删除 mongo 数据目录（secondary）
如果不确定谁是主库，就 mv 下数据目录
rm -rf /data/servers/data/mg27017/data/*
4 修改所有节点配置文件（oplogsize）
oplogSizeMB: 4096
5 重启所有节点 mongod
/data/servers/app/mongodb-3.2.8/bin/mongod -f /data/servers/data/mg27017/mongod.conf
该方法会导致主库如果异常，没有从库可切换，不建议使用该方式
【小节】
设置多大的 oplog 合适呢，可以根据现在数据大小，io 和大致的 oplog window 时间预估一个合适的大小
rs.printReplicationInfo()
log length start to end: 当 oplog 写满时可以理解为时间窗口
oplog last event time: 最后一个操作发生的时间
：
