【Mongodb】Replica Set 的选举策略之三-CSDN博客

承接之前的文章继续介绍replica set 选举机制。

创建两节点的Replica Sets，一主一备secondary，如果Secondary宕机，Primary会变成Secondary！这时候集群里没有Primary了！为什么会出现这样的情况呢。

[mongodb@rac4 bin]$ mongo 127.0.0.1:27018 init1node.js

MongoDB shell version: 2.0.1

connecting to: 127.0.0.1:27018/test

[mongodb@rac4 bin]$ ./mongo 127.0.0.1:27019

MongoDB shell version: 2.0.1

connecting to: 127.0.0.1:27019/test

RECOVERING>

SECONDARY>

SECONDARY> use admin

switched to db admin

SECONDARY> db.shutdownServer()

Sun Nov 6 20:16:11 DBClientCursor::init call() failed

Sun Nov 6 20:16:11 query failed : admin.$cmd { shutdown: 1.0 } to: 127.0.0.1:27019

server should be down...

Sun Nov 6 20:16:11 trying reconnect to 127.0.0.1:27019

Sun Nov 6 20:16:11 reconnect 127.0.0.1:27019 failed couldn't connect to server 127.0.0.1:27019

Sun Nov 6 20:16:11 Error: error doing query: unknown shell/collection.js:150

secondary 当机之后，主库有PRIMARY变为SECONDARY

[mongodb@rac4 bin]$ mongo 127.0.0.1:27018

MongoDB shell version: 2.0.1

connecting to: 127.0.0.1:27018/test

PRIMARY>

SECONDARY>

从日志中可以看出：从库down了之后，主库的变化

Sun Nov 6 20:16:13 [rsHealthPoll] replSet info 10.250.7.220:27019 is down (or slow to respond): DBClientBase::findN: transport error: 10.250.7.220:27019 query: { replSetHeartbeat: "myset", v: 1, pv: 1, checkEmpty: false, from: "10.250.7.220:27018" }

Sun Nov 6 20:16:13 [rsHealthPoll] replSet member 10.250.7.220:27019 is now in state DOWN

Sun Nov 6 20:16:13 [conn7] end connection 10.250.7.220:13217

Sun Nov 6 20:16:37 [rsMgr] can't see a majority of the set, relinquishing primary

Sun Nov 6 20:16:37 [rsMgr] replSet relinquishing primary state

Sun Nov 6 20:16:37 [rsMgr] replSet SECONDARY

这是和MongoDB的Primary选举策略有关的，如果情况不是Secondary宕机，而是网络断开，那么两个节点都会选取自己为Primary，因为他们能连接上的只有自己这一个节点。而这样的情况在网络恢复后就需要处理复杂的一致性问题。而且断开的时间越长，时间越复杂。所以MongoDB选择的策略是如果集群中只有自己一个节点，那么不选取自己为Primary。

所以正确的做法应该是添加两个以上的节点，或者添加arbiter，当然最好也最方便的做法是添加arbiter，aribiter节点只参与选举，几乎不会有压力，所以你可以在各种闲置机器上启动arbiter节点，这不仅会避免上面说到的无法选举Primary的情况，更会让选取更快速的进行。因为如果是三台数据节点，一个节点宕机，另外两个节点很可能会各自选举自己为Primary，从而导致很长时间才能得出选举结果。实际上集群选举主库上由优先级和数据的新鲜度这两个条件决定的。

官方文档：

Example: if B and C are candidates in an election, B having a higher priority but C being the most up to date:

1 C will be elected primary

2 Once B catches up a re-election should be triggered and B (the higher priority node) should win the election between B and C

3 Alternatively, suppose that, once B is within 12 seconds of synced to C, C goes down.

B will be elected primary.

When C comes back up, those 12 seconds of unsynced writes will be written to a file in the rollback directory of your data directory (rollback is created when needed).

You can manually apply the rolled-back data, see Replica Sets - Rollbacks.

重新搭建replica set 集群不过这次加上仲裁者:

[mongodb@rac4 bin]$ cat init2node.js

rs.initiate({

_id : "myset",

members : [

{_id : 0, host : "10.250.7.220:28018"},

{_id : 1, host : "10.250.7.220:28019"},

{_id : 2, host : "10.250.7.220:28020", arbiterOnly: true}

]

})

[mongodb@rac4 bin]$ ./mongo 127.0.0.1:28018 init2node.js