第五部分 架構篇 第十二章 MongoDB Replica Sets 架構（簡介）

標籤：mongodb replica set架

1、Replication簡介

MongoDB Replication即是在多個伺服器中同步複製資料，資料複製的目的為提供冗餘和提高資料的可用性，資料複製的操作即在不同的資料庫伺服器上儲存多份複製的資料集，以此來避免單機故障進而遺失資料，複製機制也允許你恢複硬體故障和服務中斷，進而起到資料的容災和備份作用。

在MongoDB中，一個複製集就是一組mongod執行個體，一個mongod執行個體作為primary也就是所謂的master服務，接收所有的寫操作，其他的mongod執行個體作為secondaries也就是所謂的slave服務，它們的業務來自於primary，以便於得到和primary相同的資料集。

1.1、Primary（master）

primary服務接收來自用戶端的所有些操作，一個複製集架構中僅僅只能有一個primary服務，因為僅僅只允許一個複製集的成員接收寫操作，複製集架構提供嚴格規定所有的讀必須來自primary，MongoDB通過oplog日誌來支援資料的變更。

以下是基於primary的複製集基礎架構圖：

1.2、secondaries（slave）

secondaries服務複製primary的主日誌(oplog)來對它們的資料集進行操作，Secondaries資料集反映的是primary資料集，如果primary服務不可達，Replica Set架構會自動選擇一個Secondaries來作為Primary，預設情況下，用戶端從Primary進行讀操作，然而用戶端可以直接發送讀操作給一個Secondaries服務來擷取資料。用戶端從Secondaries服務讀取的資料不一定反映的是Primary的資料。

以下是基於Secondaries的複製集架構：

1.3、Arbiter(仲裁者)基於上述的兩種架構，你可以可以在其中添加一個額外的mongod執行個體作為replica set架構的仲裁者(arbiter),arbiter不會持有一個資料集，arbiter僅僅在當primary不可達時，要選擇一個Secondary來作為primary的選舉中投票使用，如果你的replica set架構有很多的成員，添加一個arbiter在primary的初級選舉中會獲得更多的票數，Arbiter不需要專門的硬體來支援。以下是添加Arbiter的Replica Set架構：
注意：一個arbiter將永遠都是一個arbiter，也就是說在一個Replica Set架構中一個仲裁者將永遠是一個仲裁者，一個Primary可以變成一個Secondary，一個Secondary在重新的選舉中也可以成為一個Primary。但是仲裁者在架構中不管發生都不能變化。
1.3.1、Replica Set Arbiter(複製集仲裁者)在前面我們已經講到了一個Arbiter（仲裁者）不會持有資料集的備份，也不能成為一個Primary服務來接收用戶端的寫操作，Replica Set也許在選擇Primary有Arbiter(仲裁者)來增加選票，Aribter（仲裁者）允許複製集有不均勻的成員數量，它卻沒有像成員複製資料的開銷。注意：不要在和Primary服務以及Secondary服務成員同一台主機上運行一個Arbiter（仲裁者），僅僅添加一個Arbiter（仲裁者）作為一個Replica Set的固定成員，如果你添加一個Arbiter（仲裁者）作為一個Replica Set的臨時成員，這個Replica Set也許在選舉中造成投票不公平。那麼怎麼在一個Replica Set架構中添加一個Arbiter（仲裁者）呢？Arbiters（仲裁者）是一個mongod執行個體，作為Replica Set架構的一部分，但是它不會持有資料集，Arbiter（仲裁者）參與Primary的選舉，以便打破選舉中的綁架關係，如果一個Replica Set有均勻的成員，添加一個Arbiter（仲裁者）需要有一些極少的必備條件，它不需要硬體的支援，你可以在一個應用服務或者監控主機上部署一個Arbiter(仲裁者)服務。注意事項：

• 不要在一個Replica Set架構的成員的機器上部署一個Arbiter(仲裁者)服務。
• Arbiter(仲裁者)不儲存資料，但是當一個Arbiter（仲裁者）的mongod進程被添加到一個Replica Set架構中，Arbiter(仲裁者)會像其他任何一個mongod進程一樣開始啟動一個帶有滿容量的journal的資料檔案集合。
• Arbiter允許在一個Replica Set中設定一個投票選舉的基數。如架構所示：

1.3.2、添加一個Arbiter(仲裁者)

• 建立一個仲裁者的資料目錄（如dbpath），mongod執行個體用這個目錄來儲存配置資料，該目錄不會儲存一個來自primary主日誌複製的資料集合。如下所示:

mkdir /data/arb

• 開啟一個Arbiter服務，需要指定資料目錄和Replica Set名稱，如下所示：

mongod --port 30000 --dbpath /data/arb --replSet rs

• 使用rs.addArb()方法將Arbiter服務添加到一個Replica Set，同時串連到Primary服務。

rs.addArb("m1.example.net:30000")

此時便在m1.example.net主機上運行了一個連接埠在30000的Arbiter(仲裁者)服務。
1.3.3、(Security)安全 Authentication(認證)當Arbiter運行在一個需要認證的Replica Set的架構中時，Arbiter(仲裁者)交換憑據對該群組成員進行身分識別驗證，通過mongodb的加密認證進程，MongoDB認證交換加密的安全性憑證，此時Arbiter(仲裁者)服務需要一個key檔案去驗證Replica Set架構。 Communication(溝通)在一個部署有Arbiter(仲裁者)的Replica Set架構中，僅僅只有Arbiter和其他成員的溝通，如選舉投票、心跳、和配置資料的這些資料中不進行加密。注意：當然如果你的MongoDB使用SSL部署，MongoDB將加密Replica Set架構中所有成員的溝通，關於SSL的MongoDB中應用在後面的章節會依依列出。-------------------------------------------------------------MongoDB系列博文更新--------------------------------------------------------------------------------------------

第一部分 基礎篇 第一章 走進MongoDB

第一部分 基礎篇 第二章 安裝MongoDB

第一部分 基礎篇 第三章 MongoDB體繫結構

第一部分 基礎篇 第四章 MongoDB快速入門

第一部分 基礎篇 第四章 MongoDB查詢

第二部分 應用篇 第五章 MongoDB進階查詢

第二部分 應用篇 第六章 MongoDB GridFS

第二部分 應用篇 第七章 MongoDB MapReduce

第三部分 管理篇 第八章 MongoDB服務管理

第三部分 管理篇 第九章 MongoDB shell之系統命令、使用者命令

第三部分 管理篇 第九章 MongoDB shell之eval、進程

第四部分 效能篇 第十章 MongoDB 索引

第四部分 效能篇 第十一章 MongoDB 效能監控

第五部分 架構篇 第十二章 MongoDB Replica Sets 架構（簡介）