MongoDB 第14章 Replica Sets 架構(成員深入理解)
在學習復制的概念之前,首先接著前面一章節的還有點未完結的內容做個簡單的介紹,主要是自動故障轉移、異步復制、以及附加功能,這些在此只做簡單的介紹,在以后的相關章節中會專門深入學習。
1、自動故障轉移
當Primary服務和架構中其他成員中斷通信超過10秒,Replica Set將嘗試選舉其他成員成為一個新的Primary服務,獲得多票數的Scondary將成為Primary。
架構如下:
說明:
在一個Replica Set架構中,如果Primary不可達,則會在除Primary之外的其他成員中自動選舉一個Scondary來作為新的Primary,使Replica Set保證可用,起到自動故障轉移的目的。
2、異步復制
Secondaries從Primary異步應用所有的操作,正在異步應用Primary操作時,集合可能繼續工作,但是此時并不會復制數據到其他成員,所以當客戶端通過Secondary節點返回數據時可能不是數據集得最新數據。
3、附加功能
Replica Set提供了大量的選項,以便支持應用的需要。比如你可以部署一個多數據中心的Replica Set,或者通過調整成員的優先級去控制選舉結果,Replica Set可以支持成員的報表、容災恢復,或者備份功能。
4、復制概念(本章重點)
該章節主要描述和提供了關于Replica Set的操作、配置、和行為的實例,關于Replica Set的簡介,以及文檔的管理命令請學習前面相關章節。
4.1、Replica Set Memebers(成員)
MongoDB一個Replica Set是一組mongod進程,提供了冗余和高可用特性,一個Replica Set的成員包括如下:
Primary:primary接收所有的寫操作
Secondary:從primary復制所有的操作來持有一份相同的數據集,Secondary也許添加一些特殊用途的配置,比如,Secondary沒有選舉權和優先級設置為0等。
當然也可以添加一個arbiter(仲裁者)在一個Replica Set架構中,Arbiter不能持有一份復制的數據,然后仲裁者在Replica Set架構中扮演一個控制選舉的角色,當Replica Set中primary不可達,需要重新選舉其他成員作為新的primary時。
一個Replica Set最多可以有12個成員,然后在同一時間中只有7個成員能夠被投票選舉。
一個Replica Set最小的架構包括:1個primary、1個secondary、1個arbiter,然后大多數的部署將保持三個成員來存儲數據:一個primary和兩個secodary成員。
4.2、Primary
在前面的章節已經了解過了primary基礎知識,在此章節深入學習,在一個Replica Set架構中,當且僅有一個primary服務用于接收所有的寫操作,MongoDB在primary應用寫操作了,同時記錄primary寫操作的主日志(oplog),Secondary成員復制這個日志同時根據該復制日志進行復制數據集合的操作。
如下為一個三個成員的Replica Set架構:
說明:
Replica Set所有成員都可以接收讀操作,默認情況下,從primary進行讀操作,可以通過配置來更改讀操作行為。
默認情況下,客戶端直接通過primary進行讀操作,以此來保證返回的是一個文檔最新的版本,然而通過分配一些讀操作給secondary成員,以此來改善系統的讀吞吐量或者減少當一個應用不需要完整的數據時不可預知的問題。
注意:當指定一個primary之外的成員能接收讀操作時,你必須格外的小心,因為secondary成員可能并沒有從primary同步最新的數據集合。
原理結構如下:
如果選擇一個沒有primary的讀模式,也許應用獲取不到實時的數據,因為secondary會有一些耽擱,MongoDB驅動提供了五種讀模式:
* primary:默認模式,所有的讀操作來自當前Replica Set架構的primary。
* primaryPreferrd:大多數情況下,讀操作通過primary,但是當primary不可達時,讀操作通過secondary進行
* secondary:所有讀操作通過secondary成員進行。
* secondaryPreferred:該模式下,讀操作通過secondary進行,但是當secondary不可達時,讀操作會自動通過primary進行。
* nearset:讀操作通過replica set架構中網絡延誤最近的成員進行,不管該成員是什么類型。
Replica Set有且僅有一個primary成員。如果當前primary成員不可達,會自動選擇一個其他成員作為新的primary,來保證整個架構的可用。
4.3、Secondaries
在前面已經介紹過secondary,它主要通過primary日志來進行數據的復制操作,有一些延遲,如果一個應用直接通過secondary來讀取數據,可能獲取的不是Replica Set架構最新的數據,一個Replica Set架構中可以有一個或者多個secondary成員,如下是三個成員的Replica Set架構,包括兩個secondary成員:
盡管客戶端不能直接通過Secondary進行寫操作,客戶端能通過secondary進行數據讀取操作,一個secondary也可以在primary不可達的情況下轉換成primary,同時也可以自主制定一些配置來賦予secondary特殊功能:
如阻止一個secondary成員在選舉中成為primary,此時只需將該成員的優先級(priority)設置為0即可。
(1)、Replica Set成員優先級0介紹
一個優先級(priority)為0的secondary成員不可能在primary不可達時轉變為新的primary,優先級為0的成員不能觸發選舉事件,但是它可以持有一份復制的數據集合,也可以進行讀操作和選舉,配置一個成員的優先級為0,主要是為了阻止該成員成為primary,在多數據中心部署中這是非常有用的。
如下一個三個成員的Replica Set架構中,在第一個數據中心的主機上,一個primary成員和一個secondary成員,在的第二個數據中心的主機上一個優先級為0的secondary不可能成為primary。
(2)、優先級為0成員的作用
一個優先級為0的成員通常作為一個數據備份,在一些Replica Set架構中,也許不可能在一個合適的時間添加一個新的成員,一個持有當前數據備份的一個備用成員可以替代一些不可用的成員。
在許多的案例中,你不需要通過設置優先級為0去將成員作為備份成員,在不同的硬件以及地理分布式部署中,優先級0的備用確保僅有符合條件的成員才能成為primary。
如果在架構中已經有7個成員有投票選舉權時,將其他的成員配置為非選投票成員時,可以通過該方法實現。
(3)、優先級為0成員和故障轉移
通過配置一個優先級為0成員,考慮潛在的故障模式,包括所有可能的網絡分區,始終確保你的主要數據中心包含符合規則的選舉成員和確定成員。
(4)、配置
注意:rs.resconfig()方法可以使當前的primary服務下臺,當一個primary下臺(不可達)之后,mongod會關閉所有的客戶端連接,這個過程將花費10到20秒。為了成功的配置replica set,大多數成員必須是可訪問的,如果你的replica set成員是偶數,可以添加一個arbiter來確保獲取多數選票的成員成為primary。
(1)、檢索當前replica set配置
rs.conf()費那個發返回一個replica set包含當前replica set配置的文檔。
一個mongo客戶端連接到一個primary,運行rs.conf()方法同時分配給一個變量,如下:
? ? ? cfg = rs.conf()
該方法會返回一個Replica Set架構包含所有成員配置的文檔。
(2)、分配優先級值為0
為了分配一個優先級值給Replica Set中的一個成員,訪問該成員的配置文檔實用一個數組索引,在下面的例子中改變數組角標為2的成員的優先級為0
? ? ?cfg.members[2].priority = 0
該配置只有當重新配置replica set之后才能生效。
(3)、重新配置replica set
使用rs.reconfig()方法重新配置replica set用于更新配置文檔。
在rs.reconfig()方法中使用cfg變量即可。
? ? rs.reconfig(cfg)
如阻止一個應用通過secondary進行讀操作,此時只需要將該成員在Replica Set架構中隱藏即可。
隱藏Replica set成員
(1)、一個隱藏的成員仍然保持一份主要的數據集合,但是客戶端應用程序對其不可見,一個隱藏成員必須總優先級始終為0,不可能變為primary,且使用db.isMaster()方法不能顯示隱藏成員,如下是一個五個成員的replica set架構,四個成員都持有primary的數據集合,但是有一個成員是隱藏成員。
(2)、讀操作
客戶端不會通過一個隱藏成員來進行讀操作,因此這些成員不能接受其他成員基礎復制操作,使用隱藏成員任務有如報表、備份,延遲的成員應該被隱藏。
在一個分片集群中,mongos路由不能和隱藏成員進行交互。
(3)、選舉
如果你停止一個隱藏成員,以此來確保集合有更多活躍的成員或者primary停止。
由于備份的目的,可以避免停止隱藏成員使用db.fsyncLock()和db.fsyncUnlock()非那操作去刷新所有的寫操作在備份操作中對mongod實例進行枷鎖。
如通過運行一個歷史快照來從一個確認的錯誤中恢復,如無意中刪除數據庫。
MongoDB 邊緣數據中心管理 EDCM
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。