Centos7下MongoDB365-Replica Sets（複製集）集群虛擬機下載

MongoDB複製集是一個帶有故障轉移的主從集群。是從現有的主從模式演變而來，增加了自動故障轉移和節點成員自動恢復。MongoDB複製集模式中沒有固定的主結點，在啟動後，多個服務節點間將自動選舉產生一個主結點。該主結點被稱為primary，一個或多個從結點被稱為secondaries。primary結點基本上就是master結點，不同之處在於primary結點在不同時間可能是不同的服務器。如果當前的主結點失效了，複製集中的其餘結點將會試圖選出一個新的主結點。

MongoDB複製集模式的好處：

• 一切自動化。首先，複製集模式本身做了大量的管理工作，自動管理從節點，確保數據不會不一致。
• 主節點掛掉後，會自動判斷集群中的服務器並進行故障轉移，推舉新的主節點。
• 一個複製集集群支持1-7台服務器，在一個複製集中各個服務器數據保持完全一致。

在一個MongoDB複製集集群中，各個服務器有以下幾種狀態：

• Primary 主節點，一個複製集有且僅有一台服務器處於Primary狀態，只有主節點才對外提供讀寫服務。如果主節點掛掉，複製集將投票選出一個備節點成為新的主節點。
• Secondary 備用節點，複製集允許有多台Secondary，每個備用節點的數據與主節點的數據是完全同步的。Recovering 恢復中，當複製集中某台服務器掛掉或者掉線後數據無法同步，重新恢復服務後從其他成員複製數據，這時就處於恢復過程，數據同步後，該節點又回到備用狀態。
• Arbiter 仲裁節點，該類節點可以不用單獨存在，如果配置為仲裁節點，就主要負責在複本集中監控其他節點狀態，投票選出主節點。該節點將不會用於存放數據。如果沒有仲裁節點，那麼投票工作將由所有節點共同進行。
• Down 無效節點，當服務器掛掉或掉線時就會處於該狀態。複製集的從節點讀請求，也是在各個Driver層設置slaveOk的值來實現的。

如上介紹所知，mongodb中的複製可以在多台服務器中同步數據。複製提供了冗餘和增加了數據的高可用性，防止單個節點易丟失數據的可能性，也可以用來進行讀寫分離提高客戶端操作性能。複製集中各節點的mongodb實例有相同的數據集副本。主節點可以接收客戶端所有寫操作記錄到日誌中，從庫複製主庫的操作日誌記錄應用到其數據庫中。一個客戶端只能有一個主節點，如果主節點不可用（10秒內無法連接），複製集中將選一個成員節點作為主節點。

MongoDB主備+仲裁的基本結構如下：

主節點（Primary）
在複製集中，主節點是唯一能夠接收寫請求的節點。MongoDB在主節點進行寫操作，並將這些操作記錄到主節點的oplog中。而從節點將會從oplog複製到其本機，並將這些操作應用到自己的數據集上。（複製集最多只能擁有一個主節點）
從節點（Secondaries）
從節點通過應用主節點傳來的數據變動操作來保持其數據集與主節點一致。從節點也可以通過增加額外參數配置來對應特殊需求。例如，從節點可以是non-voting或是priority 0.
仲裁節點（ARBITER）

本博主配置好的Centos7下MongoDB365-Replica Sets（複製集）集群虛擬機下載，鏈接：https://pan.baidu.com/s/1_a_Fzll4HeZQsPqx1e1cAQ
提取碼：y9wu 下載後，用Vmware Workstation打開，即可以使用.
仲裁節點即投票節點，其本身並不包含數據集，且也無法晉陞為主節點。但是，旦當前的主節點不可用時，投票節點就會參與到新的主節點選舉的投票中。仲裁節點使用最小的資源並且不要求硬件設備。投票節點的存在使得複製集可以以偶數個節點存在，而無需為複製集再新增節點 不要將投票節點運行在複製集的主節點或從節點機器上。 投票節點與其他 複製集節點的交流僅有：選舉過程中的投票，心跳檢測和配置數據。這些交互都是不加密的。

心跳檢測
複製集成員每兩秒向複製集中其他成員進行心跳檢測。如果某個節點在10秒內沒有返回，那麼它將被標記為不可用。

MongoDB副本集是有故障恢復功能的主從集群，由一個primary節點和一個或多個secondary節點組成：
節點同步過程： Primary節點寫入數據，Secondary通過讀取Primary的oplog得到複製信息，開始複製數據並且將複製信息寫入到自己的oplog。如果某個操作失敗，則備份節點停止從當前數據源複製數據。如果某個備份節點由於某些原因掛掉了，當重新啟動後，就會自動從oplog的最後一個操作開始同步，同步完成後，將信息寫入自己的oplog，由於複製操作是先複製數據，複製完成後再寫入oplog，有可能相同的操作會同步兩份，不過MongoDB在設計之初就考慮到這個問題，將oplog的同一個操作執行多次，與執行一次的效果是一樣的。

通俗理解：當Primary節點完成數據操作後，Secondary會做出一系列的動作保證數據的同步：
– 檢查自己local庫的oplog.rs集合，找出最近的時間戳。
– 檢查Primary節點local庫oplog.rs集合，找出大於此時間戳的記錄。
– 將找到的記錄插入到自己的oplog.rs集合中，並執行這些操作。

副本集的同步和主從同步一樣，都是異步同步的過程，不同的是副本集有個自動故障轉移的功能。其原理是：slave端從primary端獲取日誌，然後在自己身上完全順序的執行日誌所記錄的各種操作（該日誌是不記錄查詢操作的），這個日誌就是local數據 庫中的oplog.rs表，默認在64位機器上這個表是比較大的，占磁盤大小的5%，oplog.rs的大小可以在啟動參數中設 定：–oplogSize 1000,單位是M。

注意：在副本集的環境中，要是所有的Secondary都宕機了，只剩下Primary。最後Primary會變成Secondary，不能提供服務。

本博主配置好的Centos7下MongoDB365-Replica Sets（複製集）集群虛擬機下載，鏈接：https://pan.baidu.com/s/1_a_Fzll4HeZQsPqx1e1cAQ
提取碼：y9wu 下載後，用Vmware Workstation打開，即可以使用.