多主機復制是一種數據庫復制方法，它允許數據由一組計算機存儲，并由該組的任何成員更新。 所有成員都響應客戶數據查詢。 多主復制系統負責將每個成員所做的數據修改傳播到組的其余部分，并解決不同成員所做的并發更改之間可能出現的任何沖突。

多主機復制可以與主副本復制形成對比，其中組的單個成員被指定為給定數據片段的主節點，并且是唯一允許修改該數據項的節點。 其他希望修改數據項的成員必須首先聯系主節點。 只允許一個主控可以更容易地實現組成員之間的一致性，但不如多主控復制靈活。

多主機復制也可以與故障轉移集群形成對比，在故障轉移集群中，被動副本服務器正在復制主數據，以便在主服務器停止運行時為接管做準備。 主服務器是唯一活躍的客戶端交互服務器。

通常，多主系統中的通信和復制是通過一種共識算法來處理的，但也可以通過特定于軟件的自定義或專有算法來實現。

多主復制的主要目的是提高可用性和加快服務器響應時間。

• 可用性：如果一個 master 發生故障，其他 master 會繼續更新數據庫。
• 分布式訪問：Masters 可以位于多個物理站點，即分布在整個網絡中。

• 一致性：大多數多主復制系統只是松散一致，即惰性和異步，違反了 ACID 屬性。
• 性能：Eager 復制系統很復雜，會增加通信延遲。
• 完整性：隨著涉及的節點數量增加和延遲增加，沖突解決等問題可能變得棘手。

許多目錄服務器基于輕量級目錄訪問協議 (LDAP) 并實現多主復制。

目錄服務器中更普遍的多主復制實現之一是 Microsoft 的 Active Directory。 在 Active Directory 中，在一個域控制器上更新的對象然后通過多主復制復制到其他域控制器。 不需要所有域控制器都相互復制，因為這會導致大型 Active Directory 部署中的網絡流量過大。 相反，域控制器具有復雜的更新模式，可確保及時更新所有服務器，而不會產生過多的復制流量。 然而，靈活的單主操作可以更好地滿足某些 Active Directory 需求。

CA Directory 支持多主機復制。

OpenDS（及其后繼產品OpenDJ）從1.0版本開始實現了多主機。OpenDS/OpenDJ多主機復制是異步的，它使用一個帶有發布-訂閱機制的日志，允許擴展到大量節點。 OpenDS/OpenDJ 復制在條目和屬性級別解決沖突。 OpenDS/OpenDJ 復制可以在廣域網上使用。

OpenLDAP 是廣泛使用的開源 LDAP 服務器，自 2.4 版（2007 年 10 月）[1] 起實現了多主復制。

Amazon Aurora 由復制重做記錄的寫入節點和 6 個存儲節點組成。 寫入器節點將更改發送到每個存儲節點，每個存儲節點檢查沖突然后報告更改的確認或拒絕。

Apache CouchDB 使用一個簡單的、基于 HTTP 的多主復制系統，該系統是通過使用僅附加數據存儲和多版本并發控制 (MVCC) 而構建的。

每個文檔都包含一個修訂 ID，因此每條記錄都存儲了所有先前修訂 ID 的演變時間線，這些修訂 ID 導致了它自己——這為 CouchDB 的 MVCC 系統提供了基礎。

此外，它還為整個數據庫保留一個按順序索引。 復制過程僅復制文檔的最后修訂版，因此僅在源數據庫上的所有先前修訂版不會復制到目標數據庫。

CouchDB 復制器充當一個簡單的 HTTP 客戶端，同時作用于源數據庫和目標數據庫。 它比較數據庫的當前序列 ID，計算修訂差異，并根據在源數據庫的歷史記錄中找到的內容對目標進行必要的更改。 雙向復制只是交換源值和目標值進行另一次復制的結果。