mongodb複製集內部機制(mongodb bully演算法)
帶著副本集的問題來看吧!
- 副本集故障轉移,主節點是如何選舉的?能否手動干涉下架某一臺主節點。
- 官方說副本集數量最好是奇數,為什麼?
- mongodb副本集是如何同步的?如果同步不及時會出現什麼情況?會不會出現不一致性?
- mongodb的故障轉移會不會無故自動發生?什麼條件會觸發?頻繁觸發可能會帶來系統負載加重?
Bully演算法
mongodb副本集故障轉移功能得益於它的選舉機制。選舉機制採用了Bully演算法,可以很方便從分散式節點中選出主節點。一個分散式叢集架構中一般都有一個所謂的主節點,可以有很多用途,比如快取機器節點元資料,作為叢集的訪問入口等等。主節點有就有吧,我們幹嘛要什麼Bully演算法?要明白這個我們先看看這兩種架構:
- 指定主節點的架構,這種架構一般都會申明一個節點為主節點,其他節點都是從節點,如我們常用的mysql就是這樣。但是這樣架構我們在第一節說了整個叢集如果主節點掛掉了就得手工操作,上架一個新的主節點或者從從節點恢復資料,不太靈活。
- 不指定主節點,叢集中的任意節點都可以成為主節點。mongodb也就是採用這種架構,一但主節點掛了其他從節點自動接替變成主節點。
好了,問題就在這個地方,既然所有節點都是一樣,一但主節點掛了,怎麼選擇出來下一個節點是誰來做為主節點呢?這就是Bully演算法解決的問題。
那什麼是Bully演算法,Bully演算法是一種協調者(主節點)競選演算法,主要思想是叢集的每個成員都可以宣告它是主節點並通知其他節點。別的節點可以選擇接受這個聲稱或是拒絕並進入主節點競爭。被其他所有節點接受的節點才能成為主節點。節點按照一些屬性來判斷誰應該勝出。這個屬性可以是一個靜態ID,也可以是更新的度量像最近一次事務ID(最新的節點會勝出)。詳情請參考
選舉
那mongodb是怎進行選舉的呢?官方這麼描述:
We use a consensus protocol to pick a primary. Exact details will be spared here but that basic process is:
- get maxLocalOpOrdinal from each server.
- if a majority of servers are not up (from this server’s POV), remain in Secondary mode and stop.
- if the last op time seems very old, stop and await human intervention.
- else, using a consensus protocol, pick the server with the highest maxLocalOpOrdinal as the Primary.
大致翻譯過來為使用一致協議選擇主節點。基本步驟為:
- 得到每個伺服器節點的最後操作時間戳。每個mongodb都有oplog機制會記錄本機的操作,方便和主伺服器進行對比資料是否同步還可以用於錯誤恢復。
- 如果叢集中大部分伺服器down機了,保留活著的節點都為 secondary狀態並停止,不選舉了。
- 如果叢集中選舉出來的主節點或者所有從節點最後一次同步時間看起來很舊了,停止選舉等待人來操作。
- 如果上面都沒有問題就選擇最後操作時間戳最新(保證資料是最新的)的伺服器節點作為主節點。
這裡提到了一個一致協議(其實就是bully演算法),這個和資料庫的一致性協議還是有些區別,一致協議主要強調的是通過一些機制保證大家達成共識;而一致性協議強調的是操作的順序一致性,比如同時讀寫一個數據會不會出現髒資料。一致協議在分散式裡有一個經典的演算法叫“Paxos演算法”,後續再介紹。
上面有個問題,就是所有從節點的最後操作時間都是一樣怎麼辦?就是誰先成為主節點的時間最快就選誰。
選舉觸發條件
選舉不是什麼時刻都會被觸發的,有以下情況可以觸發。
- 初始化一個副本集時。
- 副本集和主節點斷開連線,可能是網路問題。
- 主節點掛掉。
選舉還有個前提條件,參與選舉的節點數量必須大於副本集總節點數量的一半,如果已經小於一半了所有節點保持只讀狀態。
日誌將會出現:
1 | can'tseeamajority of the set,relinquishing primary |
主節點掛掉能否人為干預?答案是肯定的。
- 可以通過replSetStepDown命令下架主節點。這個命令可以登入主節點使用
1 db.adminCommand({replSetStepDown:1}) 如果殺不掉可以使用強制開關
1 db.adminCommand({replSetStepDown:1,force:true}) 或者使用 rs.stepDown(120)也可以達到同樣的效果,中間的數字指不能在停止服務這段時間成為主節點,單位為秒。
- 設定一個從節點有比主節點有更高的優先順序。
先檢視當前叢集中優先順序,通過rs.conf()命令,預設優先順序為1是不顯示的,這裡標示出來。rs.conf();{
"_id" : "rs0",
"version" : 9,
"members" : [
{
"_id" : 0,
"host" : "192.168.1.136:27017" },
{
"_id" : 1,
"host" : "192.168.1.137:27017" },
{
"_id" : 2,
"host" : "192.168.1.138:27017" }
]
}我們來設定,讓id為1的主機可以優先成為主節點。
1 2 3 4 5 cfg=rs.conf() cfg.members[0].priority=1 cfg.members[1].priority=2 cfg.members[2].priority=1 rs.reconfig(cfg) 然後再執行rs.conf()命令檢視優先順序已經設定成功,主節點選舉也會觸發。
1 2 3 相關推薦
mongodb複製集內部機制(mongodb bully演算法)
帶著副本集的問題來看吧! 副本集故障轉移,主節點是如何選舉的?能否手動干涉下架某一臺主節點。 官方說副本集數量最好是奇數,為什麼? mongodb副本集是如何同步的?如果同步不及時會出現什麼情況?會不會出現不一致性? mongodb的故障轉移會不會無故
部署MongoDB複製集(副本集)
環境 作業系統:Ubuntu 18.04 MongoDB: 4.0.3 伺服器 首先部署3臺伺服器,1臺主節點 + 2臺從節點 3臺伺服器的內容ip分別是: 10.140.0.5 (主節點)
MongoDB複製集與Raft協議異同點分析
此文已由作者溫正湖授權網易雲社群釋出。 歡迎訪問網易雲社群,瞭解更多網易技術產品運營經驗。 一、日誌複製流程: a、raft leader節點在接收client請求後,先將請求寫到日誌中,再將日誌通過AppendEntries RPC傳送到follow上。如果收到了大多數follow的確認
Ubuntu 18.04下部署MongoDB複製集(副本集)
環境 作業系統: 18.04 MongoDB: 4.0.3 伺服器 首先部署3臺伺服器,1臺主節點 + 2臺從節點 3臺伺服器的內容ip分別是: 10.140.0.5 (主節點) 10.140.0.6 (從節點01)
認識MongoDB複製集
從這一篇開始,我們要踏上MongoDB進階之路啦,想想還有點小開心呢。一筐豬鎮樓。 引入複製集 我們先來想一個場景,如果本地專案使用MongoDB,都是下載,安裝,連線一條龍服務。這實際也就是單點模式,那如果我們專案要上線了,這個時候還是一個數據庫,就可能出問題。比如我們寫了個淘寶(噓,假裝是
Windows搭建MongoDB複製集
上篇,我們已經知道了什麼是MongoDB的複製集,不知道的可以檢視上篇哦,傳送門來了。 光說不練,假把式,咱來自己搭建一個複製集。先下載安裝哦,不知道的檢視上篇哦,https://blog.csdn.net/qq_33774822/article/details/83585156。 咱
mongodb複製集Replica Set使用簡介
MongoDB高可用 對於MongoDB,可以支援使用單機模式提供服務,但是在實際的生產環境中,單機模式將面臨很大的風險,一旦這個資料庫服務出現問題,就會導致線上的服務出現錯誤甚至崩潰。因此,在實際生產環境下,需要對MongoDB做相應的主備處理,提高資料庫服務的可用性。 對於提高可用性,一些博文裡提到了
MongoDB複製集搭建
最近在學習mongodb,看文件時看到複製集這塊覺得挺有意思,於是便動手搭建了一下mongodb複製集 mongodb的複製至少需要兩個節點。其中一個是主節點,負責處理客戶端請求,其餘的都是從節點,負責
Raft與MongoDB複製集協議比較
在一文搞懂raft演算法一文中,從raft論文出發,詳細介紹了raft的工作流程以及對特殊情況的處理。但演算法、協議這種偏抽象的東西,僅僅看論文還是比較難以掌握的,需要看看在工業界的具體實現。本文關注MongoDB是如何在複製集中使用raft協議的,對raft協議做了哪些擴充套件。 閱讀本文,需要對Mong
mongodb複製集操作步驟
複製集的好處: <1> 資料備份。每一個從節點都是一個備份 <2> 資料恢復。當主節點機器死掉後,可以讓從節點成為主節點,保證程式正常執行 <3> 讀寫分離。即主節點寫、從節點讀。如果所有的讀寫操作全部放在主
MongoDB複製集簡單操作
一、MongoDB複製集介紹 1、如下圖所示有一個數據庫叢集,叢集中有三臺資料庫伺服器,一臺活躍伺服器和兩臺備份伺服器。當活躍伺服器A發生故障時,會根據權重演算法從備份伺服器B和C中選出B作為新的活躍伺服器,而當A恢復時當成備份伺服器,繼續加入到整個資料庫叢集中工作,這就是MongoDB的副本集。 2、配
MongoDB複製集搭建(Window10系統下)
一、獲取mongodb安裝包 本示例mongo版本:mongodb-win32-x86_64-3.4.17.zip 二 、安裝mongo (1)解壓 mongodb-win32-x86_64-3.4.17.zip,解壓之後檔名可自定義。Mongo
三、MongoDB複製集
一、複製集特性 資料一致性 主是唯一的 沒有MySql那樣的雙主結構 大多數原則 叢集存活節點數小於等於1/2時,只可讀,不可寫 從庫無法寫入 MySql從庫的readonly對具有super許可權的賬戶無效 自動容災
mongoDB複製集維護和切換——記憶體限制
使用mongoDB是因為用到了graylog,部署執行2-3個月之後,發現mongoDB佔用實體記憶體巨大,50G+,公司的資料架構居然質問我為什麼不設定-Xmx堆記憶體大小,我尼瑪只能呵呵醉了! 簡單說mongoDB似乎沒有配置項可以限制使用實體記憶體,粗略理解mongo
利用log4mongo-java+mongodb複製集搭建java日誌系統
The log4mongo-java 0.6 release added full support for replica sets. While earlier releases would work with replica sets, you could specify only one host
MongoDB 複製集(Replica Set)
複製集(replica Set)或者副本集是MongoDB的核心高可用特性之一,它基於主節點的oplog日誌持續傳送到輔助節點,並重放得以實現主從節點一致。再結合心跳機制,當感知到主節點不可訪問或宕機的情形下,輔助節點通過選舉機制來從剩餘的輔助節點中推選一
MongoDB 複製集
本文主要講述了MongoDB複製集的配置,動態修改及部分原理,最後建立了一個自動化部署的指令碼。 1 原理 資料集是多臺伺服器之間維護相同的資料副本,提高伺服器的可用性。主伺服器負責讀寫,從伺服器保持和主伺服器同樣的資料集,從伺服器為只讀狀態。
MongoDB複製集
六.複製集常用方法總結 1.rs.conf() 或者rs.config(); 檢視複製集配置 2.rs.add(); 增加複製集節點 rs.add('192.168.42.242:27017') rs.add({"_id":3,"host":"192.168.42.242:27017","priorit
MongoDB複製集搭建(Windows)
叢集環境準備 首先確保Windows下安裝了Mongodb,具體下載地址載網址是:https://www.mongodb.com/download-center#community。 直接下載msi安裝版:mongodb-win32-x86_64-2008plus-ss
搭建mongodb複製集
mongodb的複製集是保證mongodb高可用的一種方式,它比傳統的主從架構更優秀,因為傳統的主從架構在主服務區宕機之後,不能自己切換服務,只有人工來切換,而複製集有一套內部的選舉機制,可以保證主伺服器在宕機之後,能選出新的主伺服器,從而保證高可用。前一段時間,自