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

除了使用 AdminAPI 部署 InnoDB 複本集之外，您還可以採用現有的複寫設定。AdminAPI 會根據複寫設定的拓撲來設定 InnoDB 複本集。完成複寫設定後，您將以與從頭部署的 InnoDB 複本集相同的方式來管理它。您可以在不建立新的複本集的情況下，利用 AdminAPI 和 MySQL Router。如需更多資訊，請參閱第 9.6 節：「採用現有的複寫設定」。

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

InnoDB 複本集限制。 與 InnoDB 集群相比，InnoDB 複本集有一些限制。建議您盡可能部署 InnoDB 集群。一般而言，InnoDB 複本集本身不提供高可用性。InnoDB 複本集的限制包括：

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

使用 InnoDB 複本集的主要原因是您具有更好的寫入效能。使用 InnoDB 複本集的另一個原因是，它們允許部署在不穩定或緩慢的網路中，而 InnoDB 集群則不行。