目录
-
9.1 部署InnoDB ReplicaSet
-
9.2 配置InnoDB ReplicaSet实例
-
9.3 创建InnoDB副本集
-
9.4 添加实例到ReplicaSet
-
9.5 采用现有的复制设置
-
9.6 更改主实例
-
9.7 强制创建新的主实例
-
9.8 标记副本集
-
9.9 检查InnoDB ReplicaSet状态
-
9.10 升级InnoDB ReplicaSet
AdminAPI 包括对 InnoDB ReplicaSet 的支持,它使您能够管理一组 MySQL 实例,类似地运行基于 GTID 的异步复制(完全基于事务)到 InnoDB Cluster。InnoDB ReplicaSet 由单个主节点和多个辅助节点(传统上称为 MySQL 复制源和副本)组成。
您可以使用对象和 AdminAPI 操作来管理 ReplicaSet ReplicaSet
,例如,检查 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 一样对其进行管理。您可以利用 AdminAPI 和 MySQL Router,而无需创建新的 ReplicaSet。有关更多信息 ,请参阅第 9.5 节 “采用现有复制设置”。
您可以通过广域网 (WAN) 使用 InnoDB ReplicaSet,而不会影响写入性能,因为服务器实例通过异步复制通道连接,并且不需要在事务上达成共识。然而,WAN 上的复制延迟更大。这种滞后导致 InnoDB ReplicaSet 中的辅助服务器进一步落后于主服务器。
InnoDB 副本集限制。 与 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 ReplicaSets的主要原因是你有更好的写入性能。使用 InnoDB ReplicaSets 的另一个原因是它们允许部署在不稳定或慢速的网络上,而 InnoDB Cluster 则不允许。