20.1 组复制背景
本节提供了 MySQL 组复制的背景信息。
创建容错系统的最常见方法是使组件冗余,即使该组件被删除,系统仍然可以正常运行。这会引发一系列挑战,使得这些系统变得更加复杂。特别是,复制数据库需要维护和管理多个服务器,而不是单个服务器。此外,因为服务器之间合作来创建组合,因此还需要解决经典分布式系统问题,如网络分区或脑裂场景。
因此,ultimate challenge 是将数据库逻辑与数据复制逻辑融合到多个协调一致的服务器中。换言之,是让多个服务器在每次系统状态变化时达成一致,并且所有服务器都可以像单个数据库一样进度。这可以总结为服务器达成每个数据库状态转换的协议,以便它们都能像一个分布式状态机一样运行。
MySQL Group Replication 提供了强协调的分布式状态机复制。服务器之间自动协调,当它们是同一组的一部分时。该组可以在单主模式下运行,自动选择主服务器,其中只有一个服务器可以接受更新。或者,对于更高级用户,可以在多主模式下部署,该模式下所有服务器都可以接受更新,即使这些更新是并发的。这项功能需要应用程序绕过由这种部署引入的限制。
有一个内置的组成员身份服务,它保持整个组的视图一致和可用,适用于所有服务器在任何给定的时间点。服务器可以离开或加入组,并且视图将相应地更新。在某些情况下,服务器可能会意外离开组,在这种情况下,故障检测机制会检测到这个变化并通知组该视图已经改变。这一切都是自动的。
为了提交事务,组中的大多数成员都需要同意给定事务在全局事务序列中的顺序。每个服务器独立地决定是否提交或回滚事务,但所有服务器都会做出相同的决定。如果出现网络分区,导致成员无法达成一致,那么系统将不进步直到这个问题被解决。因此,也有一个内置、自动的脑裂保护机制。
所有这些都是由提供的组通信系统(GCS)协议提供的。这些协议提供故障检测机制、组成员身份服务和安全、完全有序的消息传递。这些属性是创建一个确保数据在服务器组中一致复制的系统的关键。在这个技术的核心中,有一个 Paxos 算法的实现,它作为组通信引擎。