承接之前的文章继续介绍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>
PRIMARY>
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
[mongodb@rac4 bin]$ ./mongo 127.0.0.1:28018
MongoDB shell version: 2.0.1
connecting to: 127.0.0.1:28018/test
PRIMARY> rs.status()
{
"set" : "myset",
"date" : ISODate("2011-11-06T14:16:13Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "10.250.7.220:28018",
"health" : 1,
"state" : 1,
...
},
{
"_id" : 1,
"name" : "10.250.7.220:28019",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
....
},
{
"_id" : 2,
"name" : "10.250.7.220:28020",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
....
}
],
"ok" : 1
}
PRIMARY>
再次测试，测试主库变成secondary节点。
对于前一篇文章多节点的，比如4个primary，secondary节点，一个仲裁者，当两个节点down了之后，不会出现的文章说的down 1/2的机器整个集群不可用，但是如果down 3/4的机器时，整个集群将不可用！
日志记录中描述的 “majority of” 并没有给出一个具体的数值，目前所做的实验是多于1/2的时候,整个集群就不可用了
Sun Nov 6 19:34:16 [rsMgr] can't see a majority of the set, relinquishing primary