在 Meta 构建和部署 MySQL Raft _Meta

文章插图

作者：Anirban Rahut、Abhinav Sharma、Yichen Shen、Ahsanul Haque

我们推出 MySQL Raft 的目的是最终取代我们当前的 MySQL 半同步数据库。
MySQL Raft 最大的好处是简化了操作，让 MySQL 服务器负责促销和会员资格。这为 Raft 提供了可证明的安全性，并减少了显着的操作痛苦。
使 MySQL 服务器成为真正的分布式系统也为下游系统利用它开辟了可能性。其中一些想法开始成形。

在 Meta，我们运行着世界上最大的 MySQL 部署之一。该部署为社交图谱以及许多其他服务提供支持，例如消息、广告和提要。在过去的几年里，我们实现了 MySQL Raft，这是一个 Raft 共识引擎，与 MySQL 集成以构建复制状态机。我们已经将大部分部署迁移到 MySQL Raft ，并计划用它完全替换当前的 MySQL半同步数据库。该项目为 Meta 的 MySQL 部署带来了显着的好处，包括更高的可靠性、可证明的安全性、故障转移时间的显着改进以及操作的简单性——所有这些都具有相同或可比的写入性能。
背景为了实现高可用性、容错和扩展读取，Meta 的 MySQL 数据存储是一个大规模分片、地理复制部署，具有数百万个分片，保存 PB 级数据。部署包括在多个地区和多个大洲的数据中心运行的数千台机器。
以前，我们的复制解决方案使用的是 MySQL半同步（semisync）复制协议。这是一个仅数据路径协议。MySQL 主节点将使用半同步复制到主区域内但在主节点故障域之外的两个仅记录副本 (logtailers) 。这两个 logtailer 将充当半同步 ACKer（ACK 是对事务已在本地写入的主节点的确认）。这将允许数据路径具有非常低的延迟（亚毫秒）提交，并为写入提供高可用性/持久性。常规的 MySQL 主副本异步复制用于更广泛地分布到其他区域。
控制平面操作（例如，升级、故障转移和成员更改）将由一组 Python/ target=_blank class=infotextkey>Python 守护程序（以下称为自动化）负责。自动化将进行必要的编排，以将故障转移位置的新 MySQL 服务器提升为主要服务器。自动化还将指向先前的主副本和剩余的副本，以从新的主副本进行复制。成员更改操作将由另一个称为MySQL 池扫描器(MPS)的自动化来协调。要添加新成员，MPS 会将新副本指向主副本并将其添加到服务发现存储。故障转移将是一个更复杂的操作，其中 logtailer（半同步 ACKer）的尾线程将被关闭以隔离之前死掉的主线程。
为什么需要 MySQL Raft？过去，为了在复杂的升级和故障转移操作期间帮助保证安全并避免数据丢失，一些自动化守护进程和脚本会使用锁定、编排步骤、防护机制和服务发现系统 SMC 。这是一个分布式设置，很难以原子方式完成。随着越来越多的极端情况需要修补，随着时间的推移，自动化变得越来越复杂和难以维护。
我们决定采取完全不同的方法。我们增强了 MySQL 并使其成为真正的分布式系统。意识到升级和成员变更等控制平面操作是大多数问题的触发因素，我们希望控制平面和数据平面操作成为同一复制日志的一部分。为此，我们使用了众所周知的共识协议Raft 。这也意味着成员资格和领导权的真实来源移动到服务器 (mysqld) 内部。这是引入 Raft 的最大贡献，因为它在 MySQL 服务器的促销和成员更改之间实现了可证明的正确性（安全属性）。
Raft 库和 MySQL Raft 插件我们的 Raft for MySQL 实现基于Apache Kudu 。我们根据 MySQL 和部署的需要对其进行了显着增强。我们将此分支作为开源项目kuduraft发布。
我们添加到 kuduraft 的一些关键特性是：

FlexiRaft — 支持两种不同的交叉仲裁：数据仲裁和领导者选举仲裁
代理——使用代理中间节点减少网络带宽的能力
压缩——我们在分发之前压缩一次二进制日志（事务）有效负载
日志抽象——支持不同的物理日志文件实现
Primary ban——阻止某些实体暂时成为主要实体的能力

我们还必须对 MySQL 复制进行相对较大的更改以与 Raft 接口。为此，我们创建了一个名为 MyRaft 的新闭源 MySQL 插件。MySQL 将通过插件 API 与 MyRaft 接口（类似的 API 也已用于半同步），而我们为 MyRaft 创建了一个单独的 API 以与 MySQL 服务器接口（回调）。