摘要:申明本文由筆者首發于深入淺出復制中文社區深入淺出復制由于自己開了,所以將之前比較好的文章挪過來便于大家瀏覽。新增由于網絡問題導致失敗重試機制。
申明
本文由筆者首發于
InfoQ:《深入淺出MongoDB復制》
MongoDB中文社區:《深入淺出MongoDB復制》
由于自己開了blog,所以將之前比較好的文章挪過來便于大家瀏覽。
綜述筆者最近在生產環境中遇到許多復制相關問題,查閱網上資料發現官方文檔雖然系統但是不夠有深度,網上部分深度文章則直接以源碼展示,不利于大家了解。所以本文則是結合前兩者最終給讀者以簡單的方式展現MongoDB復制的整個架構。本文分為以下5個步驟:
MongoDB復制簡介
MongoDB添加從庫
MongoDB復制流程詳解
MongoDB高可用
MongoDB復制總結
1、MongoDB復制簡介本章節首先會給大家簡單介紹一些MongoDB復制的一些基本概念,便于大家對后面內容的理解。
1.1、基本介紹MongoDB有副本集及主從復制兩種模式,今天給大家介紹的是副本集模式,因為主從模式在MongoDB 3.6也徹底廢棄不使用了。MongoDB副本集有Primary、Secondary、Arbiter三種角色。今天給大家介紹的是Primary與Secondary數據同步的內部原理。MongoDB副本集架構如下所示:
1.2、MongoDB OplogMongoDB Oplog是MongoDB Primary和Secondary在復制建立期間和建立完成之后的復制介質,就是Primary中所有的寫入操作都會記錄到MongoDB Oplog中,然后從庫會來主庫一直拉取Oplog并應用到自己的數據庫中。這里的Oplog是MongoDB local數據庫的一個集合,它是Capped collection,通俗意思就是它是固定大小,循環使用的。如下圖:
MongoDB Oplog中的內容及字段介紹:
</>復制代碼
{
"ts" : Timestamp(1446011584, 2),
"h" : NumberLong("1687359108795812092"),
"v" : 2,
"op" : "i",
"ns" : "test.nosql",
"o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" }
}
ts: 操作時間,當前timestamp + 計數器,計數器每秒都被重置
h:操作的全局唯一標識
v:oplog版本信息
op:操作類型
i:插入操作
u:更新操作
d:刪除操作
c:執行命令(如createDatabase,dropDatabase)
n:空操作,特殊用途
ns:操作針對的集合
o:操作內容,如果是更新操作
o2:操作查詢條件,僅update操作包含該字段
1.3、MongoDB復制發展
MongoDB目前已經迭代了很多個版本,下圖我匯總了目前市面上常用版本中MongoDB在復制的一些重要改進。
具體細節大家可以參考MongoDB官方Release Note:https://docs.mongodb.com/manu...
2、MongoDB添加從庫 2.1、添加從庫命令MongoDB添加從庫比較簡單,在安裝從庫之后,直接在主庫執行rs.add()或者replSetReconfig命令即可添加,這兩個命令其實在最終都調用replSetReconfig命令執行。大家有興趣可以去翻閱MongoDB客戶端JS代碼。
2.2、具體步驟然后我們來看副本集加一個新從庫的大致步驟,如下圖,右邊的Secondary是我新加的從庫。
通過上圖我們可以看到一共有7個步驟,下面我們看看每一個步驟MongoDB都做了什么:
1、 主庫收到添加從庫命令
2、 主庫更新副本集配置并與新從庫建立心跳機制
3、 從庫收到主庫發送過來的心跳消息與主庫建立心跳
4、 其他從庫收到主庫發來的新版本副本集配置信息并更新自己的配置
5、 其他從庫與新從庫建立心跳機制
6、 新從庫收到其他從庫心跳信息并跟其他從庫建立心跳機制
7、 新加的節點將副本集配置信息更新到local.system.replset集合中,MongoDB會在一個循環中查詢local.system.replset是否配置了replset 信息,一旦查到相關信息觸發開啟復制線程,然后判斷是否需要全量復制,需要的話走全量復制,不需要走增量復制。
8、 最終同步建立完成
副本集所有節點之前都有相互的心跳機制,每2秒一次,在MongoDB 3.2版本以后我們可以通過heartbeatIntervalMillis參數來控制心跳頻率。
上述過程大家可以結合副本集節點狀態來看(rs.status命令):
STARTUP //在副本集每個節點啟動的時候,mongod加載副本集配置信息,然后將狀態轉換為STARTUP2
STARTUP2 //加載配置之后決定是否需要做Initial Sync,需要則停留在STARTUP2狀態,不需要則進入RECOVERING狀態
RECOVERING //處于不可對外提供讀寫的階段,主要在Initial Sync之后追增量數據時候。
3、 MongoDB復制流程詳解上面我們知道添加一個從庫的大致流程,那我們現在來看主從數據同步的具體細節。當從庫加入到副本集的時候,會判斷自己是需要Initial Syc(全量同步)還是增量同步。那是通過什么條件判斷的呢?
3.1、判斷全量同步及增量同步如果local數據庫中的oplog.rs 集合是空的,則做全量同步。
如果minValid集合里面存儲的是_initialSyncFlag,則做全量同步(用于init sync失敗處理)
如果initialSyncRequested是true,則做全量同步(用于resync命令,resync命令只用于master/slave架構,副本集無法使用)
以上三個條件有一個條件滿足就需要做全量同步。
我們可以得出在從庫最開始加入到副本集的時候,只能先進行Initial Sync,下面我們來看看Initial Sync的具體流程
3.2、全量同步流程(Init sync) 3.2.1、 尋找同步源這里先說明一點,MongoDB默認是采取級聯復制的架構,就是默認不一定選擇主庫作為自己的同步源,如果不想讓其進行級聯復制,可以通過chainingAllowed參數來進行控制。在級聯復制的情況下,你也可以通過replSetSyncFrom命令來指定你想復制的同步源。所以這里說的同步源其實相對于從庫來說就是它的主庫。那么同步源的選取流程是怎樣的呢?
MongoDB從庫會在副本集其他節點通過以下條件篩選符合自己的同步源。
如果設置了chainingAllowed 為false,那么只能選取主庫為同步源
找到與自己ping時間最小的并且數據比自己新的節點 (在副本集初始化的時候,或者新節點加入副本集的時候,新節點對副本集的其他節點至少ping兩次)
該同步源與主庫最新optime做對比,如果延遲主庫超過30s,則不選擇該同步源。
在第一次的過濾中,首先會淘汰比自己數據還舊的節點。如果第一次沒有,那么第二次需要算上這些節點,防止最后沒有節點可以做為同步源了。
最后確認該節點是否被禁止參與選舉,如果是則跳過該節點。
通過上述篩選最后過濾出來的節點作為新的同步源。
其實MongoDB同步源在除了在Initial Sync和增量復制 的時候選定之后呢,并不是一直是穩定的,它可能在以下情況下進行變更同步源:
ping不通自己的同步源
自己的同步源角色發生變化
自己的同步源與副本集任意一個節點延遲超過30s
3.2.2、 刪除MongoDB中除local以外的所有數據庫 3.2.3、 拉取主庫存量數據這里就到了Initial Sync的核心邏輯了,我下面以圖和步驟的方式給大家展現MongoDB在做Initial Sync的具體流程。
注:本圖是針對于MongoDB 3.4之前的版本
同步流程如下:
</>復制代碼
* 0. Add _initialSyncFlag to minValid collection to tell us to restart initial sync if we crash in the middle of this procedure
* 1. Record start time.(記錄當前主庫最近一次oplog time)
* 2. Clone.
* 3. Set minValid1 to sync target"s latest op time.
* 4. Apply ops from start to minValid1, fetching missing docs as needed.(Apply Oplog 1)
* 5. Set minValid2 to sync target"s latest op time.
* 6. Apply ops from minValid1 to minValid2.(Apply Oplog 2)
* 7. Build indexes.
* 8. Set minValid3 to sync target"s latest op time.
* 9. Apply ops from minValid2 to minValid3.(Apply Oplog 3)
10. Cleanup minValid collection: remove _initialSyncFlag field, set ts to minValid3 OpTime
注:以上步驟直接copy的MongoDB源碼中的注釋。
以上步驟在Mongo 3.4 Initial Sync 有如下改進:
在創建的集合的時候同時創建了索引(與主庫一樣),在MongoDB 3.4版本之前只創建_id索引,其他索引等待數據copy完成之后進行創建。
在創建集合和拷貝數據的同時,也將oplog拷貝到本地local數據庫中,等到數據拷貝完成之后,開始應用本地oplog數據。
新增由于網絡問題導致Initial Sync 失敗重試機制。
在Initial Sync期間發現collection 重命名了會重新開始Initial Sync。
上述4個新增特性提升了Initial Sync的效率并且提高了Initial Sync的可靠性,所以大家使用MongoDB最好使用最新版本MongoDB 3.4或者3.6,MongoDB 3.6 更是有一些令人興奮的特性,這里就不在此敘述了。
全量同步完成之后,然后MongoDB會進入到增量同步的流程。
上面我們介紹了Initial Sync,就是已經把同步源的存量數據拿過來了,那主庫后續寫入的數據怎么同步過來呢?下面還是以圖跟具體的步驟來給大家介紹:
注:這里不一定是Primary,剛剛提到了同步源也可能是Secondary,這里采用Primary主要方便大家理解。
我們可以看到上述有6個步驟,那每個步驟具體做的事情如下:
1、 Sencondary 初始化同步完成之后,開始增量復制,通過produce線程在Primary oplog.rs集合上建立cursor,并且實時請求獲取數據。
2、 Primary 返回oplog 數據給Secondary。
3、 Sencondary 讀取到Primary 發送過來的oplog,將其寫入到隊列中。
4、 Sencondary 的同步線程會通過tryPopAndWaitForMore方法一直消費隊列,當每次達到一定的條件之后,條件如下:
總數據大于100MB
已經取到部分數據但沒到100MB,但是目前隊列沒數據了,這個時候會阻塞等待一秒,如果還沒有數據則本次取數據完成。
上述兩個條件滿足一個之后,就會將數據給prefetchOps方法處理,prefetchOps方法主要將數據以database級別切分,便于后面多線程寫入到數據庫中。如果采用的WiredTiger引擎,那這里是以Docment ID 進行切分。
5、 最終將劃分好的數據以多線程的方式批量寫入到數據庫中(在從庫批量寫入數據的時候MongoDB會阻塞所有的讀)。
6、 然后再將Queue中的Oplog數據寫入到Sencondary中的oplog.rs集合中。
上面我們介紹MongoDB復制的數據同步,我們知道除了數據同步,復制還有一個重要的地方就是高可用,一般的數據庫是需要我們自己去定制方案或者采用第三方的開源方案。MongoDB則是自己在內部已經實現了高可用方案。下面我就給大家詳細介紹一下MongoDB的高可用。
4.1、觸發切換場景首先我們看那些情況會觸發MongoDB執行主從切換。
1、 新初始化一套副本集
2、 從庫不能連接到主庫(默認超過10s,可通過heartbeatTimeoutSecs參數控制),從庫發起選舉
3、 主庫主動放棄primary 角色
主動執行rs.stepdown 命令
主庫與大部分節點都無法通信的情況下
修改副本集配置的時候(在Mongo 2.6版本會觸發,其他版本待確定)
修改以下配置的時候:
_id
votes
priotity
arbiterOnly
slaveDelay
hidden
buildIndexes
4、 移除從庫的時候(在MongoDB 2.6會觸發,MongoDB 3.4不會,其他版本待確定)
4.2、心跳機制通過上面觸發切換的場景,我們了解到MongoDB的心跳信息是MongoDB判斷對方是否存活的重要條件,當達到一定的條件時,MongoDB主庫或者從庫就會觸發切換。下面我給大家詳細介紹一下心跳機制
我們知道MongoDB副本集所有節點都是相互保持心跳的,然后心跳頻率默認是2秒一次,也可以通過heartbeatIntervalMillis來進行控制。在新節點加入進來的時候,副本集中所有的節點需要與新節點建立心跳,那心跳信息具體是什么內容呢?
心跳信息內容:
</>復制代碼
BSONObjBuilder cmdBuilder;
cmdBuilder.append("replSetHeartbeat", setName);
cmdBuilder.append("v", myCfgVersion);
cmdBuilder.append("pv", 1);
cmdBuilder.append("checkEmpty", checkEmpty);
cmdBuilder.append("from", from);
if (me > -1) {
cmdBuilder.append("fromId", me);
}
注:上述代碼摘抄MongoDB 源碼中構建心跳信息片段。
具體在MongoDB日志中表現如下:
</>復制代碼
command admin.$cmd command: replSetHeartbeat { replSetHeartbeat: "shard1", v: 21, pv: 1, checkEmpty: false, from: "10.13.32.244:40011", fromId: 3 } ntoreturn:1 keyUpdates:0
那副本集所有節點默認都是每2秒給其他剩余的節點發送上述信息,在其他節點收到信息后會調用ReplSetCommand命令來處理心跳信息,處理完成會返回如下信息:
</>復制代碼
result.append("set", theReplSet->name());
MemberState currentState = theReplSet->state();
result.append("state", currentState.s); // 當前節點狀態
if (currentState == MemberState::RS_PRIMARY) {
result.appendDate("electionTime", theReplSet->getElectionTime().asDate());
}
result.append("e", theReplSet->iAmElectable()); //是否可以參與選舉
result.append("hbmsg", theReplSet->hbmsg());
result.append("time", (long long) time(0));
result.appendDate("opTime", theReplSet->lastOpTimeWritten.asDate());
const Member *syncTarget = replset::BackgroundSync::get()->getSyncTarget();
if (syncTarget) {
result.append("syncingTo", syncTarget->fullName());
}
int v = theReplSet->config().version;
result.append("v", v);
if( v > cmdObj["v"].Int() )
result << "config"
注:以上信息是正常情況下返回的,還有一些不正常的處理場景,這里就不一一細說了。
4.3、切換流程
前面我們了解了觸發切換的場景以及MongoDB副本集節點之前的心跳機制。下面我們來看切換的具體流程:
1、從庫無法連接到主庫,或者主庫放棄Primary角色。
2、從庫會根據心跳消息獲取當前該節點的角色并與之前進行對比
3、如果角色發生改變就開始執行msgCheckNewState方法
4、在msgCheckNewState 方法中最終調用electSelf 方法(會有一些判斷來決定是否最終調用electSelf方法)
5、electSelf 方法最終向副本集其他節點發送replSetElect命令來請求投票。
命令如下:
</>復制代碼
BSONObj electCmd = BSON(
"replSetElect" << 1 <<
"set" << rs.name() <<
"who" << me.fullName() <<
"whoid" << me.hbinfo().id() <<
"cfgver"
具體日志表現如下:
</>復制代碼
2017-12-14T10:13:26.917+0800 [conn27669] run command admin.$cmd { replSetElect: 1, set: "shard1", who: "10.13.32.244:40015", whoid: 4, cfgver: 27, round: ObjectId("5a31de4601fbde95ae38b4d2") }
6、其他副本集收到replSetElect會對比cfgver信息,會確認發送該命令的節點是否在副本集中,確認該節點的優先級是否是該副本集所有節點中優先級最大的。最后滿足條件才會給該節點發送投票信息。
7、發起投票的節點最后會統計所得票數大于副本集可參與投票數量的一半,則搶占成功,成為新的Primary。
8、其他從庫如果發現自己的同步源角色發生變化,則會觸發重新選取同步源。
4.4、Rollback
我們知道在發生切換的時候是有可能造成數據丟失的,主要是因為主庫宕機,但是新寫入的數據還沒有來得及同步到從庫中,這個時候就會發生數據丟失的情況。
那針對這種情況,MongoDB增加了回滾的機制。在主庫恢復后重新加入到復制集中,這個時候老主庫會與同步源對比oplog信息,這時候分為以下兩種情況:
1、 在同步源中沒有找到比老主庫新的oplog信息。
2、 同步源最新一條oplog信息跟老主庫的optime和oplog的hash內容不同。
針對上述兩種情況MongoDB會進行回滾,回滾的過程就是逆向對比oplog的信息,直到在老主庫和同步源中找到對應的oplog,然后將這期間的oplog全部記錄到rollback目錄里的文件中,如果但是出現以下情況會終止回滾:
對比老主庫的optime和同步源的optime,如果超過了30分鐘,那么放棄回滾。
在回滾的過程中,如果發現單條oplog超過512M,則放棄回滾。
如果有dropDatabase操作,則放棄回滾。
最終生成的回滾記錄超過300M,也會放棄回滾。
上述我們已經知道了MongoDB的回滾原理,但是我們在生產環境中怎么避免回滾操作呢,因為畢竟回滾操作很麻煩,而且針對有時序性的業務邏輯也是不可接受的。那MongoDB也提供了對應的方案,就是WriteConcern,這里就不細說了,有興趣的朋友可以仔細了解。其實這也是在CAP中做出一個選擇。
5、 MongoDB復制總結
MongoDB復制內部原理已經給大家介紹完畢,以上其實還涉及很多細節沒能一一列出。大家有興趣可以自己去整理。這里還需要說明一點就是MongoDB版本迭代速度比較快,所以本文只針對于MongoDB 2.6 到MongoDB 3.4 版本,不過在某些版本可能會存在一些細節的變動,但是大體上的邏輯還是沒有改變。最后大家如果有什么問題,也可以與我聯系。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/19192.html
摘要:與歐盟的通用數據保護規定的時間越來越近了。因此無論是否加入了歐盟,只要你正在以任何方式處理歐盟公民的數據,就必須服從的條約。保留個人資料通過使用特定的生存時間索引,管理員可以自動將數據庫中的歐盟公民數據過期。 ??與歐盟的通用數據保護規定的(GDPR)1時間越來越近了。從2018年5月25日起,任何一個未能滿足新法規的組織將面臨高達全球收入4%的罰款,或者是2000萬歐元——無論哪種罰...
摘要:與歐盟的通用數據保護規定的時間越來越近了。因此無論是否加入了歐盟,只要你正在以任何方式處理歐盟公民的數據,就必須服從的條約。保留個人資料通過使用特定的生存時間索引,管理員可以自動將數據庫中的歐盟公民數據過期。 ??與歐盟的通用數據保護規定的(GDPR)1時間越來越近了。從2018年5月25日起,任何一個未能滿足新法規的組織將面臨高達全球收入4%的罰款,或者是2000萬歐元——無論哪種罰...
摘要:查詢結果支持操作。文件存儲該軟件實現了一個稱為的協議,這個協議是用來幫助從數據庫中存儲和獲取文件的。支持被稱為定量集合的定長集合。目前提供多種語言的。在系統重啟之后,由搭建的持久化緩存層可以避免下層的數據源過載。 MongoDB是一個開源的,高性能,無模式(或者說是模式自由),使用C++語言編寫的面向文檔的數據庫。正因為MongoDB是面向文檔的,所以它可以管理類似JSON的文檔集合。...
閱讀 1657·2021-09-22 15:21
閱讀 2874·2021-09-09 09:32
閱讀 2705·2021-09-02 09:52
閱讀 3317·2019-08-30 14:02
閱讀 2232·2019-08-26 13:25
閱讀 1464·2019-08-26 13:24
閱讀 1615·2019-08-26 10:31
閱讀 1566·2019-08-26 10:16