MySQL Shell 9.0  /  MySQL InnoDB 副本集

第 9 章 MySQL InnoDB 副本集

AdminAPI 包括对 InnoDB 副本集的支持,它使您能够管理一组类似运行异步基于 GTID 的复制的 MySQL 实例,该复制完全基于事务,类似于 InnoDB 集群。InnoDB 副本集由一个主服务器和多个从服务器组成(传统上称为 MySQL 复制源和副本)。

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

与 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 集群则不允许。