AdminAPI 包含对 InnoDB ReplicaSet 的支持，使您能够类似地管理一组 MySQL 实例，这些实例运行基于异步 GTID 的复制，该复制完全基于事务，类似于 InnoDB 集群。InnoDB ReplicaSet 由单个主服务器和多个从服务器组成（传统上称为 MySQL 复制源和副本）。

您可以使用 ReplicaSet 对象和 AdminAPI 操作来管理您的 ReplicaSet，例如，检查 InnoDB ReplicaSet 的状态，并在发生故障时手动故障转移到新的主服务器。

与 InnoDB 集群类似，MySQL Router 支持针对 InnoDB ReplicaSet 的引导，这意味着您可以自动配置 MySQL Router 以使用您的 InnoDB ReplicaSet，而无需手动配置。这种自动配置使 InnoDB ReplicaSet 成为快速简便地启动和运行 MySQL 复制和 MySQL Router 的方法。它适用于扩展 读取 并在不需要 InnoDB 集群提供的高可用性的用例中提供手动故障转移功能。

除了使用 AdminAPI 部署 InnoDB ReplicaSet 之外，您还可以采用现有的复制设置。AdminAPI 根据复制设置的拓扑结构配置 InnoDB ReplicaSet。完成复制设置后，您可以像管理从头开始部署的 InnoDB ReplicaSet 一样管理它。您可以在不创建新的 ReplicaSet 的情况下利用 AdminAPI 和 MySQL Router。有关更多信息，请参见第 9.6 节，“采用现有的复制设置”。

您可以在广域网 (WAN) 上使用 InnoDB ReplicaSet，不会影响写入性能，因为服务器实例通过异步复制通道连接，不需要对事务达成共识。但是，复制延迟在 WAN 上更大。这种延迟会导致 InnoDB ReplicaSet 中的从服务器落后于主服务器。

InnoDB ReplicaSet 限制。 与 InnoDB 集群相比，InnoDB ReplicaSet 有几个限制。建议您尽可能部署 InnoDB 集群。通常，单独的 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 集群则不允许。