本文介紹了MongoDB複製集的架構和特點，強調了使用複製集提供數據的高可用性和冗餘性的重要性。複製集由Primary節點和Secondary節點組成，確保數據一致性。複製集還具有數據分發、讀寫分離和異地容災等附加功能。使用MongoDB複製集可以提供穩定可靠的數據存儲和高可用性。 ...
MongoDB複製集
複製集架構
在生產環境中，強烈不建議使用單機版的MongoDB伺服器。原因如下：
單機版的MongoDB無法保證系統的可靠性。一旦進程發生故障或是伺服器宕機，業務將直接不可用。此外，一旦伺服器上的磁碟損壞，數據會直接丟失，而此時並沒有任何副本可用。
為了確保數據的高可用性和冗餘性，我們建議使用Mongodb複製集（Replication Set）。複製集由一組Mongod實例（進程）組成，其中包含一個Primary節點和多個Secondary節點。所有的數據寫入操作都會被寫入Primary節點，並且Secondary節點會從Primary節點同步寫入的數據，以保持複製集內所有成員存儲相同的數據集。這樣可以提供數據的高可用性。複製集的功能依賴於兩個方面：
- 數據寫入時將數據迅速複製到另一個獨立節點上，確保數據的冗餘性和可用性。
- 在接受寫入的節點發生故障時，系統能夠自動選舉出一個新的替代節點，以確保系統的連續性和可用性。
在實現高可用性的同時，Mongodb複製集還具有其他幾個附加作用：
數據分發：複製集可以將數據從一個區域複製到另一個區域，從而減少另一個區域的讀取延遲。
讀寫分離：複製集還支持讀寫分離的功能。通過將不同類型的壓力分別在不同的節點上執行，可以有效地分擔系統的負載。
異地容災：複製集還可以實現異地容災。在數據中心發生故障時，可以快速切換到異地部署的節點。
早期版本的MongoDB使用了一種Master-Slave的架構，該做法在MongoDB 3.4版本之後已經廢棄。因為Master-Slave 其中Master 宕機後不能自動恢復，只能靠人為操作，可靠性也差，操作不當就存在丟數據的風險。
三節點複製集模式
常見的複製集架構通常由3個成員節點組成，其中存在幾種不同的模式，具體取決於配置和需求。
PSS模式（官方推薦模式）
在常見的複製集架構中，PSS（Primary+Secondary+Secondary）模式是一種常見的配置，它由一個主節點和兩個備節點組成。
在這種模式下，如果主節點不可用，複製集會智能地選擇其中一個備節點作為新的主節點，並繼續正常的操作。這種自動切換的機制確保了系統的連續性和可用性，同時減少了數據丟失的風險。舊的主節點在可用時重新加入複製集。
PSA模式
PSA（Primary+Secondary+Arbiter）模式是一種常見的架構配置。它由一個主節點、一個備節點和一個仲裁者節點組成。
在這種PSA模式下，Arbiter節點的主要作用是作為一個仲裁者來參與選舉投票。它不存儲數據副本，也不提供實際的業務讀寫操作。因此，即使Arbiter節點發生故障，也不會對業務產生直接影響，只會影響選舉投票過程。主節點負責處理所有的業務讀寫操作，並且有一個完整的數據副本。備節點也存儲了一個完整的數據副本，併在主節點故障時承擔主節點的角色。而Arbiter節點則參與選舉投票，幫助複製集在主節點發生故障時選擇一個新的主節點。
典型三節點複製集環境搭建
即使只有一臺伺服器，以單節點模式啟動複製集也是一個值得考慮的選擇。
- 單機多實例啟動複製集
- 單節點啟動複製集
複製集註意事項
關於硬體:
- 由於正常的複製集節點都有可能成為主節點，它們的地位是相等的。因此，為了確保系統的穩定性，必須確保各節點的硬體配置保持一致。
- 為了避免多個節點同時宕機，每個節點使用的硬體必須具有獨立性。這樣可以保證即使一個節點宕機，其他節點仍然可以正常工作，確保系統的連續性和可靠性。
關於軟體:
- 在複製集中，每個節點的軟體版本必須保持一致，這樣可以避免出現無法預料的問題。
- 值得註意的是，增加節點並不會提高系統的寫入性能。
環境準備:
- 安裝 MongoDB並正確配置好環境變數
- 確保你的電腦硬碟上有充足的空間，至少需要10GB或更多的可用空間。
準備配置文件
為了實現複製集的最佳性能和可靠性，建議將複製集的每個mongod進程部署在不同的伺服器上。目前我們在一臺機器上運行3個進程，因此需要對它們進行以下配置：
- 配置不同的埠：（28017/28018/28019）
- 配置不同的數據目錄：
mkdir ‐p /data/db1
mkdir ‐p /data/db2
mkdir ‐p /data/db3
- 配置不同的日誌文件路徑：(例如：/data/db1/mongod.log)
創建配置文件 /data/db1/mongod.conf 時，你可以進行以下設置：
# /data/db1/mongod.conf
systemLog:
destination: file
path: /data/db1/mongod.log
logAppend: true
storage:
dbPath: /data/db1
net:
bindIp: 0.0.0.0
port: 28017
replication:
replSetName: rs0
processManagement:
fork: true
我們可以按照以上步驟修改埠和路徑，分別配置 db2 和 db3。請確保配置文件使用 YAML 格式。
啟動 MongoDB 進程
mongod ‐f /data/db1/mongod.conf
mongod ‐f /data/db2/mongod.conf
mongod ‐f /data/db3/mongod.conf
註意：如果啟用了 SELinux，可能阻止上述進程啟動。簡單起見請關閉 SELinux。
# 永久關閉,將SELINUX=enforcing改為SELINUX=disabled,設置後需要重啟才能生效
vim /etc/selinux/config
# 查看SELINUX
/usr/sbin/sestatus ‐v
總結
在本文中，我們介紹了MongoDB複製集的架構和特點。我們強調了在生產環境中使用單機版MongoDB的風險，並推薦使用複製集來保證數據的高可用性和冗餘性。
複製集由一組Mongod實例組成，其中包含一個Primary節點和多個Secondary節點。所有的數據寫入操作都會被寫入Primary節點，並且Secondary節點會從Primary節點同步寫入的數據，以保持複製集內所有成員存儲相同的數據集。
最後，我們提供了在典型三節點複製集環境中搭建的步驟和註意事項，包括準備配置文件和啟動MongoDB進程。下一章節我們將講解如何配置複製集和集群安全驗證及其連接方式。
