ron sta 副本 增加節點 img font 基礎 ocl 狀態

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

一、常見場景

應用程序和數據庫之間的網絡連接丟失

計劃停機、斷電、數據庫服務硬盤故障等等

復制可以進行故障轉移，復制能讓你在副本間均衡讀負載，保證復制節點與主節點保持同步

二、工作原理

副本集依賴於兩個基礎機制：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數據庫復制集（類似集群）（三）