MongoDB 副本集管理（不定时更新）

简介：

前面介绍完了副本集的搭建、用户的管理、参数和日常操作的说明，那副本集搭建好该如何管理呢？现在来说明下副本集的日常查看和管理。

说明：

1）查看命令行参数：db.serverCmdLineOpts()

zjy:PRIMARY> db.serverCmdLineOpts()
{
    "argv" : [
        "mongod",
        "-f",
        "/etc/mongodb/mongodb_27017.conf"
    ],
    "parsed" : {
        "config" : "/etc/mongodb/mongodb_27017.conf",
        "diaglog" : 3,
        "net" : {
            "maxIncomingConnections" : 50,
            "port" : 27017,
            "unixDomainSocket" : {
                "pathPrefix" : "/tmp"
            }
        },
        "processManagement" : {
            "fork" : true,
            "pidFilePath" : "/var/run/mongo_27017.pid"
        },
        "replication" : {
            "replSet" : "zjy/127.0.0.1:27018"
        },
        "storage" : {
            "dbPath" : "/usr/local/mongo1/",
            "mmapv1" : {
                "nsSize" : 16
            }
        },
        "systemLog" : {
            "destination" : "file",
            "logAppend" : true,
            "path" : "/var/log/mongodb/mongodb1.log"
        }
    },
    "ok" : 1
}

2）查看副本集状态：rs.status()

zjy:PRIMARY> rs.status()
{
    "set" : "zjy",  #副本集名称
    "date" : ISODate("2015-06-30T04:07:29.380Z"), #执行时间
    "myState" : ,
    "members" : [  #成员
        {
            "_id" : ,
            "name" : "127.0.0.1:27017", #成员名称
            "health" : ,
            "state" : ,   #成员状态，1：Primary
            "stateStr" : "PRIMARY", #状态描述
            "uptime" : , #副本集运行时间，Primary为MongoDB运行时间，单位秒
            "optime" : Timestamp(1435301307, 10),  #最近一次更改数据库的时间：1435301307;每秒执行操作数据库的次数：10
"optimeDate" : ISODate("2015-06-26T06:48:27Z"),#最后一个操作发生的时间
            "electionTime" : Timestamp(, ),
            "electionDate" : ISODate("2015-06-29T20:35:50Z"),#最后选举时间
            "configVersion" : ,
            "self" : true    #执行该命令函数的成员
        },
        {
            "_id" : ,
            "name" : "127.0.0.1:27018",
            "health" : ,
            "state" : , #成员状态，2：Secondary
            "stateStr" : "SECONDARY",
            "uptime" : ,
            "optime" : Timestamp(, ),
            "optimeDate" : ISODate("2015-06-26T06:48:27Z"),
            "lastHeartbeat" : ISODate("2015-06-30T04:07:28.589Z"), #最后一次收到其他成员心跳时间
            "lastHeartbeatRecv" : ISODate("2015-06-30T04:07:27.784Z"),
            "pingMs" : ,  #心跳发送到达时间，根据其选择从哪个成员进行同步
            "syncingTo" : "127.0.0.1:27017", #同步成员地址
            "configVersion" :
        },
        {
            "_id" : ,
            "name" : "127.0.0.1:27019",
            "health" : ,
            "state" : ,
            "stateStr" : "SECONDARY",
            "uptime" : ,
            "optime" : Timestamp(, ),
            "optimeDate" : ISODate("2015-06-26T06:48:27Z"),
            "lastHeartbeat" : ISODate("2015-06-30T04:07:28.521Z"),
            "lastHeartbeatRecv" : ISODate("2015-06-30T04:07:28.521Z"),
            "pingMs" : ,
            "syncingTo" : "127.0.0.1:27017",
            "configVersion" :
        }
    ],
    "ok" :
}

mongod实例每隔两秒就会向其他成员发送一个心跳包，并且通过rs.status()中返回的成员的health来判断成员的状态。如果primary节点不可用了，那么复制集中的所有secondary节点都会触发一次选举操作。选出新的primary节点。如果secondary节点有多个，则会选举拥有最新oplog时间戳记录的或者有较高权限的节点成为primary（注意：如果secondary停止时间过长，导致primary节点的oplog内容被循环写覆盖掉，则需要手动同步secondary节点）。

3）添加、删除副本集成员：rs.add，rs.addArb()，rs.remove()，rs.reconfig()

，添加成员
rs.add('127.0.0.1:27020')
在添加成员之前，需要在目标成员里加上repset参数。

，添加复杂的成员：
rs.add({"_id":,"host":"192.168.200.252:27017","priority":,"hidden":true,"slaveDelay":60})
不会成为主节点（被动节点），隐藏节点、延迟60s同步数据。适用于当作备份；
rs.add({"_id":,"host":"192.168.200.252:27017","votes":})
没有选举权限的节点，即使只剩下单个服务器的副本集，也不会成为Secondary
rs.add({"_id":,"host":"192.168.200.252:27017","buildIndexes":false})
不会同步索引的创建
rs.add({"_id":,"host":"192.168.200.252:27017","arbiterOnly":true}) rs.addArb()
只选举，不会同步数据

以上都可以通过rs.reconfig()来实现。
，删除成员
rs.remove('127.0.0.1:27020')

4）查看副本集的配置：rs.config()

zjy:PRIMARY> rs.config()
{
    "_id" : "zjy",      #副本集名称
    "version" : ,
    "members" : [       #各成员的配置选项
        {
            "_id" : ,
            "host" : "127.0.0.1:27017",
            "arbiterOnly" : false,
            "buildIndexes" : true,
            "hidden" : false,
            "priority" : ,
            "tags" : {

            },
            "slaveDelay" : ,
            "votes" :
        },
...
...
...
    ],
    "settings" : {
        "chainingAllowed" : false,
        "heartbeatTimeoutSecs" : ,
        "getLastErrorModes" : {

        },
        "getLastErrorDefaults" : {
            "w" : ,
            "wtimeout" :
        }
    }
}

5）修改任一Secondary的同步源：replSetSyncFrom（rs.syncFrom()），需要在Secondary上执行。

查看其中的一个Secondary的同步源
zjy:SECONDARY> db.adminCommand({"replSetGetStatus":}).syncingTo
127.0.0.1:
# 本机是27019实例，暂时需要把这个实例从27018上同步:
zjy:SECONDARY> db.adminCommand({"replSetSyncFrom":"127.0.0.1:27018"}) <==> rs.syncFrom("127.0.0.1:27018")
{
    "syncFromRequested" : "127.0.0.1:27018",
    "prevSyncTarget" : "127.0.0.1:27017",
    "ok" :
}
zjy:SECONDARY> db.adminCommand({"replSetGetStatus":}).syncingTo
127.0.0.1:27018
也可以通过rs.status()来查看其同步源
zjy:SECONDARY> rs.status().syncingTo
127.0.0.1:

6）让任一Secondary进入维护模式：replSetMaintenance，必须在Secondary里的admin下运行，之后会进入RECOVERING状态。

在副本集上执行某个耗时的操作，会让成员进入recovering模式，不会有读请求发送给他，如何一个成员远落后主，可以强制让其进入维护模式。

zjy:SECONDARY> rs.status().members
[
...
...
    {
        "_id" : ,
        "name" : "127.0.0.1:27019",
        "health" : ,
        "state" : ,
        "stateStr" : "SECONDARY",
        "uptime" : ,
        "optime" : Timestamp(, ),
        "optimeDate" : ISODate("2015-06-26T06:48:27Z"),
        "syncingTo" : "127.0.0.1:27018",
        "configVersion" : ,
        "self" : true
    }
]
zjy:SECONDARY> db.adminCommand({"replSetMaintenance":true})
{ "ok" :  }
zjy:RECOVERING> rs.status().members
[
...
...
    {
        "_id" : ,
        "name" : "127.0.0.1:27019",
        "health" : ,
        "state" : ,
        "stateStr" : "RECOVERING",
        "uptime" : ,
        "optime" : Timestamp(, ),
        "optimeDate" : ISODate("2015-06-26T06:48:27Z"),
        "syncingTo" : "127.0.0.1:27018",
        "maintenanceMode" : ,
        "configVersion" : ,
        "self" : true
    }
]

看到127.0.0.: 进入了RECOVERING

当进入维护模式之后，该节点的数据就不能读取了：

zjy:RECOVERING> db.aoe.find()
Error: error: {
    "$err" : "not master or secondary; cannot currently read from this replSet member",
    "code" :
}

退出维护模式：

zjy:RECOVERING> db.adminCommand({"replSetMaintenance":false})
{ "ok" :  }
zjy:SECONDARY> rs.status().members
[
...
...
    {
        "_id" : ,
        "name" : "127.0.0.1:27019",
        "health" : ,
        "state" : ,
        "stateStr" : "SECONDARY",
        "uptime" : ,
        "optime" : Timestamp(, ),
        "optimeDate" : ISODate("2015-06-26T06:48:27Z"),
        "syncingTo" : "127.0.0.1:27017",
        "configVersion" : ,
        "self" : true
    }
]

7）限制副本集自动寻找数据源的功能：chainingAllowed

由于配置好的副本集都是自动的对同步源进行分配，根据pingMS来寻找最新的数据源，可能某个Secondary是另一个Secondary的同步源。下面就可以关闭自动分配，同步源指到Primary上：

zjy:PRIMARY> rs.config().settings
{
    "chainingAllowed" : true,
    "heartbeatTimeoutSecs" : ,
    "getLastErrorModes" : {

    },
    "getLastErrorDefaults" : {
        "w" : ,
        "wtimeout" :
    }
}
zjy:PRIMARY> var cfg=rs.config()
zjy:PRIMARY> cfg.settings.chainingAllowed
true
zjy:PRIMARY> cfg.settings.chainingAllowed=false
false
zjy:PRIMARY> cfg.settings.chainingAllowed
false
zjy:PRIMARY> rs.reconfig(cfg)
{ "ok" :  }
zjy:PRIMARY> rs.config().settings
{
    "chainingAllowed" : false,
    "heartbeatTimeoutSecs" : ,
    "getLastErrorModes" : {

    },
    "getLastErrorDefaults" : {
        "w" : ,
        "wtimeout" :
    }
}

取消自动数据源分配的功能，可以有效的防止复制链的出现。但在一定的程度上会加大对Primary的压力。

8）主节点变成备份节点：rs.stepDown(time)，rs.freeze(time)

rs.stepDown(time) 可以让主节点退成备份节点，timie单位是秒，默认60s。60s内主被副本集的其他成员获得，时间到后，会重新进行选举，一般都会重新成为主（优先级）。

rs.freeze(time)：阻止选举，始终出于备份节点状态。比如主节点需要做一些维护，不希望其他成员选举为主节点，可以在每个备份节点上执行。强制他们出于备份节点状态。

zjy:PRIMARY> rs.stepDown()    #退位60秒，60秒内成为备份节点。
...
...
--30T12::01.670- I NETWORK  trying reconnect to 127.0.0.1: (127.0.0.1) failed
--30T12::01.671- I NETWORK  reconnect 127.0.0.1: (127.0.0.1) ok
zjy:SECONDARY> 

zjy:SECONDARY> rs.freeze()    #10秒内保持备份节点状态。
{ "ok" :  }

9）复制延迟状态查看

zjy:PRIMARY> db.printReplicationInfo()  #主上执行，
configured oplog size:   .249984741211MB   #oplog大小
log length start to end: 4086845secs (.23hrs) #oplog使用的时间长度
oplog first event time:  Thu May   :: GMT- (EDT) #最先一次操作时间
oplog last event time:   Tue Jun   :: GMT- (EDT) #最后一次操作时间
now:                     Tue Jun   :: GMT- (EDT) #当前时间

zjy:SECONDARY> db.printSlaveReplicationInfo() #从上执行，各个从的落后时间
source: 127.0.0.1:
    syncedTo: Tue Jun   :: GMT- (EDT)
     secs ( hrs) behind the primary    #落后时间
source: 127.0.0.1:
    syncedTo: Tue Jun   :: GMT- (EDT)
     secs ( hrs) behind the primary 

10）