MongoDB的reconfig命令

 

reconfig命令用于重新配置现有副本集，覆盖现有副本集配置。 要运行该方法，必须连接到副本集的主节点。在某些情况下，rs.reconfig（）方法可以触发当前primary节点降级。 当主节点不存在时，它会强制关闭所有客户端连接。 由于选举新的主节点可能需要一段时间，因此在尽可能在可运维时间执行reconfig命令，以最大限度地减少写入可用性的损失。

常见用法

1、将节点设置为延迟备份节点

cfg = rs.conf()
cfg.members[1].priority = 0
cfg.members[1].hidden = true
cfg.members[1].slaveDelay = 3600
rs.reconfig(cfg)

2、将节点设置为hidden节点

cfg = rs.conf()
cfg.members[0].priority = 0
cfg.members[0].hidden = true
rs.reconfig(cfg)

3、替换节点的成员

cfg = rs.conf()
cfg.members[0].host = "mongo2.example.net"
rs.reconfig(cfg)

4、设置副本集节点的优先级

cfg = rs.conf()
cfg.members[0].priority = 0.5
cfg.members[1].priority = 2
cfg.members[2].priority = 2
rs.reconfig(cfg)

优先级的有效取值是0~1000，可为小数，默认为1

从MongoDB 3.2开始

Non-voting members must have priority of 0.
Members with priority greater than 0 cannot have 0 votes.

注：如果将当前Secondary节点的优先级设置的大于Primary节点的优先级，会导致当前Primary节点的退位。对于没有投票权的Secondary节点，votes和priority必须同时设置为0。

5、禁用chainingAllowed

默认情况下，允许级联复制。

即备份集中如果新添加了一个节点，这个节点很可能是从其中一个Secondary节点处进行复制，而不是从Primary节点处复制。

MongoDB根据ping时间选择同步源，一个节点向另一个节点发送心跳请求，就可以得知心跳请求所耗费的时间。MongoDB维护着不同节点间心跳请求的平均花费时间，选择同步源时，会选择一个离自己比较近而且数据比自己新的节点。

如何判断节点是从哪个节点处进行复制的呢？

rs.status().members[1].syncingTo

当然，级联复制也有显而易见的缺点：复制链越长，将写操作复制到所有Secondary节点所花费的时间就越长。

可通过如下方式禁用

cfg=rs.conf()
cfg.settings.chainingAllowed=false
rs.reconfig(cfg)

将chainingAllowed设置为false后，所有Secondary节点都会从Primary节点复制数据。

为Secondary节点显式指定复制源

rs.syncFrom("node3:27019")

禁止Secondary节点创建索引

有时，并不需要Secondary节点拥有和Primary节点相同的索引，譬如这个节点只是用来处理数据备份或者离线的批量任务。这个时候，就可以阻止Secondary节点创建索引。

在MongoDB 3.4版本中，不允许直接修改，只能在添加节点时显式指定

myapp:PRIMARY> cfg=rs.conf()
myapp:PRIMARY> cfg.members[2].buildIndexes=false
false
myapp:PRIMARY> rs.reconfig(cfg)
{
    "ok" : 0,
    "errmsg" : "priority must be 0 when buildIndexes=false",
    "code" : 103,
    "codeName" : "NewReplicaSetConfigurationIncompatible"
}
myapp:PRIMARY> cfg.members[2].buildIndexes=false
false
myapp:PRIMARY> cfg.members[2].priority=0
myapp:PRIMARY> rs.reconfig(cfg)
{
    "ok" : 0,
    "errmsg" : "New and old configurations differ in the setting of the buildIndexes field for member node3:27017; to make this c
hange, remove then re-add the member",    "code" : 103,
    "codeName" : "NewReplicaSetConfigurationIncompatible"
}
myapp:PRIMARY> rs.remove("node3:27017")
{ "ok" : 1 }
myapp:PRIMARY> rs.add({_id: 2, host: "node3:27017", priority: 0, buildIndexes:false})
{ "ok" : 1 }