原文
架構影響著副本集的容量和能力。本文描述了通用的架構部署和提供部署策略。
標準的副本集生產(chǎn)環(huán)境由3個成員組成。他們之間相互提供冗余和容錯能力。為了盡可能的避免復雜化，你應該根據(jù)你的應用程序需求來部署相應架構。
策略
確定副本集成員的數(shù)量
根據(jù)以下策略添加你的成員。
成員數(shù)量的上限
一個副本集最多能擁有50個成員，但是只有最多7個成員擁有投票權，如果副本集中已經(jīng)有7個投票成員，額外的成員必須為 non-voting members.
成員數(shù)量部署為基數(shù)
確保副本集的投票成員數(shù)量為基數(shù)，如果你的副本集投票成員為偶數(shù)，部署一個 arbiter來確保投票成員為基數(shù)。
arbiter成員不會持有數(shù)據(jù)副本且僅需消耗很少資源。你可以將 arbiter運行在應用服務器或者共享進程上。arbiter不持有數(shù)據(jù)副本，可能的話你應該將 arbiter部署在一個你不會放置其他成員的環(huán)境中。
pv1對比pv0的arbiters，以下版本增加了 w:1回滾的可能性
- MongoDB 3.4.1
- MongoDB 3.4.0
- MongoDB 3.2.11 or earlier
See Replica Set Protocol Versions.
警告：
一般情況下，每個副本集中僅能存在一個arbiter
容錯性
成員數(shù)量：當服務器不可用的時候仍然能有足夠的成員來進行投票以便選舉出新的主服務器。換句話來說，副本集中的成員數(shù)量和能夠參與投票的成員是不同的。沒有了主服務器，整個副本集就無法接受寫操作。容錯服務器對副本集的大小產(chǎn)生影響，但并無直接關系，參照下表：
往副本集新增一個成員并不總是增加容錯性。然而在這樣的情況下，額外的成員可以對專用功能提供支持，例如備份或者報告。
對專用功能使用隱蔽式成員和延遲成員
在一個讀取流量非常高的情況下，你可以將部分流量分發(fā)給備份服務器以提高吞吐量。隨著你的部署增長，將成員移動或者增加到備份數(shù)據(jù)中心以提高冗余性和可用性。
請務必確定你的主數(shù)據(jù)中心設施可以選舉出一個新的主服務器。
增加需求容量
現(xiàn)有的副本集成員中，一定要有支持添加新成員的剩余容量。
請在需求對于當前副本集來說達到飽和前添加新成員。
