複製就是在多台服務器上分佈並管理數據庫服務器。MongoDB提供了兩種複製風格：主從複製和副本集。兩種方式都是在一個主節點進行寫操作（寫入的數據被異步地應用到所有從節點上），並從節點上讀取數據。
主從複製和副本集使用了相同的複製機制，但是副本集還能保證自動故障轉移：如果主節點由於某些原因下線了，可能的話，會自動將一個從節點提升為主節點。副本集還提供了其他增強，比如更易於恢復和更高級的部署拓撲。出於這些原因，現在已經沒什麼有說服力的理由使用簡單的主從複製了。1副本集也因此是生產部署環境的推薦複製策略；因此，本章的大部分內容都是副本集的說明和例子，對主從複製只做了一個簡單的概述。
1. 只有一種情況需要選擇MongoDB的主從複製，即需要超過11個從節點時，因為副本集不能包含12個以上的成員。
8.1.1 為什麼複製很重要
所有數據庫都對其運行環境中的故障很敏感，而複製提供了一種抵禦故障的機制。這裡所指的故障都有哪些？下面是一些常見場景。
應用程序與數據庫之間的網絡連接丟失。
計劃停機，但服務器沒有按照預定計劃重新上線。任何機構的服務器都一定會安排偶爾停一下機，而其停機結果不太好預測。一次簡單的重啟至少能讓數據庫服務器下線幾分鐘，但問題是重啟完成之後又會發生什麼呢？新安裝的軟件或硬件經常會讓操作系統無法正常啟動。
斷電。雖然大多數現代化數據中心都提供了冗余電源，但無法避免數據中心內部的用戶錯誤、大範圍局部暫時限制用電或者停電造成數據庫服務器關閉。
數據庫服務器硬盤故障。硬盤通常都只有幾年的平均無故障時間，它比你想像的更容易發生故障。2
2. 可以在谷歌的「Failure Trends in a Large Disk Drive Population」（http://research.google.com/archive/disk_failures.pdf）中看到硬盤故障率的詳細分析。
除了抵禦外部故障，複製對於MongoDB的耐久性來說也很重要。如果運行時沒有開啟Journaling日誌，遇到非正常關閉，無法保證MongoDB的數據文件不受破壞。沒有Journaling日誌，就必須時刻運行複製，這才能確保在一個節點意外關閉時能有一份數據文件的正確副本。
當然，就算 開啟了 Journaling日誌也應該使用複製，畢竟你追求高可用性和快速故障轉移。此時Journaling日誌會迅速完成恢復，因為只需簡單地回放Journaling日誌就能讓故障節點重新上線。相比從現有副本 重新同步 （resyncing）或手動複製副本的數據文件，這要快得多。
無論是否開啟Journaling日誌，MongoDB的複製功能都會極大地增強整個數據庫的可靠性，因此強烈推薦使用該功能。
8.1.2 複製的使用場景
你可能會感到很驚訝，複製數據庫的用途居然能有這麼多。尤其是複製能幫助進行冗余、故障轉移、維護以及負載均衡。下面，讓我們簡單地看一些使用場景。
複製主要是用來做冗余的。本質上要保證複製節點與主節點保持同步。這些副本可以和主節點位於同一數據中心裡，也可以分佈在不同地理位置用於容災。因為複製是異步的，任何節點間的網絡延遲或分區（partition）都不會影響主節點的性能。作為另一種形式的冗余，複製節點也可以與主節點保持一定的延時，萬一用戶無意間刪除了一個集合，或者應用程序不知怎麼的破壞了數據庫，這還能提供一些防禦措施。一般情況下，這些操作都會被立即複製；延時副本讓管理員有時間做出反應，也許還能挽救他們的數據。
有一點很重要：雖然它們是一種冗余，但副本不是備份的替代品。備份是數據庫在過去某個特定時間的快照，但副本總是最新的。在一些情況下，數據集過大讓備份顯得不切實際，但通常來說，備份是種明智的做法，就算用了複製也推薦進行備份。
複製的另一個使用場景是故障轉移。你希望系統高可用，但僅在擁有冗余節點，並且在緊急情況下能切換到這些節點時，才能實現高可用。MongoDB的副本集通常都能方便地自動實現這種切換。
除了提供冗余與故障轉移，複製還可以簡化維護工作，它允許你在主節點以外的節點上執行開銷很大的操作。例如，通常都會在從節點上進行備份，不給主節點帶來額外的負載，避免停機。另一個例子是構建大索引，因為構建索引的開銷很大，可以先在某個從節點上構建索引，然後主從切換，再在新的從節點上構建索引。
最後，複製能讓你在副本間均衡讀負載。對於那些讀負載佔絕對比重的應用程序而言，這是擴展MongoDB最簡單的途徑。話雖如此，但如果出現以下場景，請不要用從節點來擴展讀操作。
所分配的硬件無法處理給定的負載。以我上一章裡提到的工作集為例，如果使用的工作數據集遠大於可用內存，那麼向從節點發送隨機讀請求仍然可能造成大量磁盤訪問，導致慢查詢。
讀寫比超過50%。誠然，這個比例有點主觀，但將它作為起始值還是挺合適的。此處的問題是主節點上的所有寫操作最終也會寫入從節點，把讀操作導向正在處理大量寫入的從節點有時會減緩複製過程，並不會提高讀吞吐量。
應用程序要求一致性讀。從節點的複製是異步進行的，因此無法保證一定能讀到主節點上最新寫入的數據。在某些極端情況下，從節點可能延遲幾個小時。
因此，你能通過複製來均衡讀負載，但僅限於特定場景。如果需要進行擴展，又出現了以上某種情況，那麼你需要不同的策略，包括分片、升級硬件或兩者兼而有之。