在生产环境新增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。下面为具体命令：