windows平台搭建Mongo資料庫複寫集（類似叢集）（三）

標籤：oar   3.3   接下來   還原   應用程式   資料   set   恢複   環境   

在本篇裡面，咱們重點總結一下複製集,以及分析一下它的工作原理

一、常見情境 

應用程式和資料庫之間的網路連接丟失 

計劃停機、斷電、資料庫服務硬碟故障等等

複製可以進行容錯移轉，複製能讓你在副本間均衡讀負載，保證複製節點與主節點保持同步

二、工作原理 

複本集依賴於兩個基礎機制：oplog和“心跳”（heartbeat）.oplog讓資料的複製成為可能，而“心跳”則監控健康情況並出發容錯移轉；

2.1 關於oplog 

oplog是MongoDB複製的關鍵，oplog是一個固定集合，位於每個複製節點的local資料庫中，記錄了對資料庫的所有變更，每次用戶端向主節點寫入資料，就會自動向主節點的oplog裡添加愛一條記錄，其中部落格了足夠的資訊來再現資料。一旦寫操作被複製到某個從節點上，從節點的oplog也會儲存一條記錄。

local資料庫裡儲存了所有的複本集中繼資料和oplog，因為本身不能被複製；

 

那我們詳細在看oplog

在此注意，每個從節點都有一份自己的oplog，從節點使用長輪詢的方式立即應用來自主節點oplog的新條目。如果叢節點在主節點的oplog中找不到自己要同步的點，那麼就永久停止複製。這是會在日誌中有如下異常：

replcation data too stale, halting

caught syncException 

調整oplog的大小，利用命令db.getReplicationInfo()可以查看分配了多少oplog空間，同時利用如下命令可以改變預設oplog大小

 

[html] view plain copy 

1. mongod.exe --replSet myapp --oplogSize 1024   

 

 

2.2 心跳檢測以及容錯移轉

 

複本集的心跳檢測有助於選舉和容錯移轉。預設情況下，每個複本集成員每隔2s ping一次其他成員。這樣一來系統就可以弄清自己的健康情況了。運行rs.status()也可以看到健康狀態。

注意：在三個節點中，如果兩個從節點都被殺掉了，在主節點的log會多如下一句話：

 

replSet can‘t see a majority of the set, 

replSet Secondary 

意思是沒有多數節點，主節點就把自己降級為從節點；

三、管理

由於複本集存在許多潛在的複雜配置項，接下來我們詳細介紹這些複雜設定項目；

3.1 配置細節可以用rs.initiate()和rs.add()方法初始化複本集合。利用config.members.push({})增加節點；  其他的一些方法： 3.2 容錯移轉與恢複恢複是在故障後講複本集還原到原始狀態的過程。有兩大類故障需要處理。第一類就是包含所有的無損故障，直接重啟服務就好。第二種是明確故障，主要是資料檔案損壞等等，非正常關閉mongodb服務，如果不更改主機名稱和連接埠號碼則重新執行資料檔案夾，啟動後資料後同步過來。如果修改屬性，則要用rs.reconfig(); 3.3 部署策略複本集最多包含12個節點，提供自動容錯移轉的最小複本集合配置就是先前例子中。包含兩個副本和一個仲裁節點。在生產環境中，仲裁機節點可以運行在應用伺服器上，而副本則運行在自己的機器上。對於多數環境而言，這樣配置經濟又高校 轉自：http://blog.csdn.net/sxb0841901116/article/details/40686521

windows平台搭建Mongo資料庫複寫集（類似叢集）（三）