目录
AdminAPI 包括对 InnoDB ReplicaSet 的支持，这使您能够管理一组 MySQL 实例，这些实例类似地运行基于 GTID 的异步复制（完全基于事务）到 InnoDB Cluster。InnoDB ReplicaSet 由单个主节点和多个辅助节点（传统上称为 MySQL 复制源和副本）组成。
您使用
ReplicaSet对象和 AdminAPI 操作来管理您的 ReplicaSets，例如，检查 InnoDB ReplicaSet 的状态，并在发生故障时手动故障转移到新的主节点。
与 InnoDB Cluster 类似，MySQL Router 支持针对 InnoDB ReplicaSet 的引导，这意味着您可以自动配置 MySQL Router 以使用您的 InnoDB ReplicaSet，而无需手动配置它。这种自动配置使 InnoDB ReplicaSet 成为启动和运行 MySQL 复制和 MySQL Router 的快速简便的方法。它使其适合
reads在不需要 InnoDB Cluster 提供的高可用性的用例中扩展和提供手动故障转移功能。
除了使用 AdminAPI 部署 InnoDB ReplicaSet 之外，您还可以采用现有的复制设置。AdminAPI 根据复制设置的拓扑结构配置 InnoDB ReplicaSet。完成复制设置后，您可以像从头开始部署 InnoDB ReplicaSet 一样管理它。您可以在不创建新 ReplicaSet 的情况下利用 AdminAPI 和 MySQL Router。有关详细信息，请参阅 第 9.5 节，“采用现有的复制设置”。
您可以在广域网 (WAN) 上使用 InnoDB ReplicaSet 而不会影响写入性能，因为服务器实例通过异步复制通道连接并且不需要对事务达成共识。但是，WAN 上的复制滞后较大。这种滞后导致 InnoDB ReplicaSet 中的辅助服务器进一步落后于主服务器。
InnoDB 副本集限制。 与 InnoDB Cluster 相比，InnoDB ReplicaSet 有几个限制。建议您尽可能部署 InnoDB Cluster。通常，InnoDB ReplicaSet 本身不提供高可用性。InnoDB ReplicaSet 的局限性包括：
没有自动故障转移。在主节点不可用的情况下，需要使用 AdminAPI 手动触发故障转移，然后才能再次进行任何更改。但是，辅助实例仍可用于读取。
无法防止由于意外停止或不可用而导致部分数据丢失：在意外停止时未完成的事务可能会丢失。
在意外退出或不可用后无法防止不一致。如果手动故障转移提升了一个辅助实例，而前一个主实例仍然可用，例如，由于网络分区，裂脑情况可能会导致数据不一致。
InnoDB ReplicaSet 不支持多主模式。允许写入所有成员的经典复制拓扑无法保证数据一致性。
读取横向扩展是有限的。InnoDB ReplicaSet 基于异步复制，因此无法像 Group Replication 那样调整流量控制。
所有次要成员都从单一来源复制。对于某些特定的用例，这可能会影响单一来源，例如，大量的小更新。
仅支持运行 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 ReplicaSets 的主要原因是你有更好的写入性能。使用 InnoDB ReplicaSets 的另一个原因是它们允许在不稳定或慢速网络上部署，而 InnoDB Cluster 则不允许。