【Mongodb】Replica Set 的選舉策略之三
承接之前的文章繼續介紹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
參考文章:
http://blog.nosqlfan.com/html/2523.html
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/22664653/viewspace-710335/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【Mongodb】 Replica set 的 選舉策略之二MongoDB
- 【Mongodb】 Replica set 的選舉策略之一MongoDB
- 【Mongodb】ReplicaSet的選舉策略之三MongoDB
- 【Mongodb】如何建立mongodb的replica setMongoDB
- mongodb 3.0 replica set 配置MongoDB
- [MONGODB]: WHEN ARBITER REQUIRED FOR REPLICA SETMongoDBUI
- 【Mongodb】 Replica set 的讀寫分離MongoDB
- MongoDB Replica Set 副本集實踐MongoDB
- MongoDB搭建Replica Set複製集MongoDB
- mongodb replica set 和 nodejs中使用mongoose連線replicaMongoDBNodeJS
- docker 下部署mongodb Replica Set 叢集DockerMongoDB
- mongodb複製集(replica set)搭建及管理MongoDB
- 【MongoDB】高可用方案之副本集(Replica Set)MongoDB
- 【Mongodb】 replica set 新增和刪除節點。MongoDB
- MongoDB副本集replica set (二)--副本集環境搭建MongoDB
- 【Mongodb】 replica set 兩種新增節點方法的日誌分析MongoDB
- MongoDB系列-解決面試中可能遇到的MongoDB複製集(replica set)問題MongoDB面試
- 小丸子學MongoDB系列之——部署Replica Set+Sharded ClusterMongoDB
- MongoDB的選舉過程MongoDB
- mongodb replica sets 測試MongoDB
- mongodb叢集shard_replica的搭建方法MongoDB
- MongoDB 複製集模式Replica SetsMongoDB模式
- Simple Automated Backups for MongoDB Replica SetsMongoDB
- MongoDB系列二:Replica Sets安裝與配置MongoDB
- 用通俗易懂的方法解釋MongoDB的選舉機制MongoDB
- Keepalived中Master和Backup角色選舉策略薦AST
- mongodb複製集(replica sets)+分片(sharding)環境搭建MongoDB
- MongoDB 入門教程系列之三:使用 Restful API 操作 MongoDBMongoDBRESTAPI
- 演算法--列舉策略演算法
- 利用Mongodb的複製集搭建高可用分片,Replica Sets + Sharding的搭建過程MongoDB
- MongoDB系列三:Replica Sets在生產環境中安裝配置的注意事項MongoDB
- Java列舉的策略設計模式 -DEVJava設計模式dev
- MongoDB寫入資料策略MongoDB
- 副本集選舉
- MongoDB新的均衡策略和自動合併MongoDB
- MySQL遠端備份策略舉例MySql
- MongoDB最簡單的入門教程之三 使用Java程式碼往MongoDB裡插入資料MongoDBJava
- ZooKeeper 工作、選舉 原理