AdminAPI 包含對 InnoDB ReplicaSet 的支援，讓您可以管理一組類似執行非同步 GTID 型複寫的 MySQL 執行個體，其完全以交易為基礎，適用於 InnoDB Cluster。InnoDB ReplicaSet 包含單一主要節點和多個次要節點（傳統上稱為 MySQL 複寫來源和複本）。

您可以使用 ReplicaSet 物件和 AdminAPI 操作來管理您的 ReplicaSet，例如，檢查 InnoDB ReplicaSet 的狀態，以及在發生故障時手動容錯移轉至新的主要節點。

與 InnoDB Cluster 類似，MySQL Router 支援針對 InnoDB ReplicaSet 的引導程序，這表示您可以自動設定 MySQL Router 以使用您的 InnoDB ReplicaSet，而無需手動設定。此自動設定使 InnoDB ReplicaSet 成為快速且輕鬆啟動並執行 MySQL 複寫和 MySQL Router 的方法。它適用於擴展 讀取，並在不需要 InnoDB Cluster 提供的高可用性的使用案例中提供手動容錯移轉功能。

除了使用 AdminAPI 部署 InnoDB ReplicaSet 之外，您還可以採用現有的複寫設定。AdminAPI 會根據複寫設定的拓樸來設定 InnoDB ReplicaSet。完成複寫設定後，您可以像管理從頭開始部署的 InnoDB ReplicaSet 一樣管理它。您可以使用 AdminAPI 和 MySQL Router，而無需建立新的 ReplicaSet。如需更多資訊，請參閱第 9.6 節，「採用現有的複寫設定」。

您可以透過廣域網路 (WAN) 使用 InnoDB ReplicaSet，而不會影響寫入效能，因為伺服器執行個體透過非同步複寫通道連線，且不需要在交易上達成共識。但是，在 WAN 上，複寫延遲會比較大。此延遲會導致 InnoDB ReplicaSet 中的次要伺服器比主要伺服器延遲更多。

InnoDB ReplicaSet 限制。 與 InnoDB Cluster 相比，InnoDB ReplicaSet 有一些限制。建議您盡可能部署 InnoDB Cluster。一般來說，InnoDB ReplicaSet 本身不提供高可用性。InnoDB ReplicaSet 的限制包括：

沒有自動容錯移轉。在主要節點無法使用的情況下，需要使用 AdminAPI 手動觸發容錯移轉，才能再次進行任何變更。但是，次要執行個體仍然可供讀取使用。
無法防止由於意外停止或無法使用而導致的部分資料遺失：在意外停止時未完成的交易可能會遺失。
無法防止在意外結束或無法使用後出現不一致的情況。如果手動容錯移轉在先前的主要節點仍然可用時升級次要執行個體，例如，由於網路分割，則分裂大腦情況可能會導致資料不一致。
InnoDB ReplicaSet 不支援多個主要節點模式。無法保證允許寫入所有成員的傳統複寫拓樸的資料一致性。
讀取擴展有限。InnoDB ReplicaSet 基於非同步複寫，因此無法像群組複寫那樣調整流程控制。
所有次要成員都從單一來源複寫。對於某些特定的使用案例，這可能會影響單一來源，例如，大量的少量更新。
僅支援執行 MySQL 8.0 版及更新版本的執行個體。
僅支援以 GTID 為基礎的複寫，二進位記錄檔位置複寫與 InnoDB ReplicaSet 不相容。
僅支援以列為基礎的複寫 (RBR)，不支援以陳述式為基礎的複寫 (SBR)。
不支援複寫篩選器。
不允許在任何執行個體上使用未管理的複寫通道。
ReplicaSet 最多包含一個主要執行個體。支援一個或多個次要執行個體。雖然您可以新增至 ReplicaSet 的次要執行個體數目沒有限制，但連線至 ReplicaSet 的每個 MySQL Router 都必須監控每個執行個體。因此，新增至 ReplicaSet 的執行個體越多，監控就越多。
ReplicaSet 必須由 MySQL Shell 管理。例如，複寫帳戶由 MySQL Shell 建立和管理。不支援在 MySQL Shell 外部變更執行個體的設定，例如，直接使用 SQL 陳述式來變更主要執行個體。請務必使用 MySQL Shell 來處理 InnoDB ReplicaSet。

使用 InnoDB ReplicaSet 的主要原因是您擁有更好的寫入效能。使用 InnoDB ReplicaSet 的另一個原因是，它們允許部署在不穩定或速度較慢的網路上，而 InnoDB Cluster 則不允許。