MySQL升级Raft，Meta为什么不选择Paxos？

Meta……对，就是去年承认自己进入元宇宙失败，最近也在轰轰烈烈裁员上头条，原名 Facebook 那个，悄悄干了件大事，把 MySQL 的 semi-sync 复制协议换成了 Raft。他们认为，只有这样 MySQL 才算“真正分布式”了（Truely Distributed） 。

---

Meta，作为全世界市值 Top20 的互联网公司，拥有 28 亿+ 的月活用户。它的社交图谱、消息传递、广告和信息流都运行在 MySQL 集群上，这也让 Meta 成为了 MySQL 用户届的无冕之王。

“我们的 MySQL 数据存储是一个大规模分片、地理复制的部署，拥有数百万个分片，存储着 PB 级别的数据。该部署包括数千台机器，分布在多个大陆和区域的数据中心里。”（不愧是世界级的社交元宇宙平台，这数据量和管理难度，小猿姐想想都有点嗨！）

在此之前，Meta 主要使用 semi-sync 来保障 MySQL 的数据可靠性。在 Meta 的使用场景里，主节点通过 semi-sync 将日志发送给故障域外的两个日志节点，只要有一个日志节点确认接收到了日志，主节点就认为写入操作成功。这个经典做法在保障数据可靠性的同时，还能让数据路径具有亚毫秒级的写入延迟。（海外的网络这么给力？！）

然而，为了防止在角色变化和故障转移期间发生数据丢失，semi-sync 方案还依赖脚本自动化守护程序引入的锁定、编排和隔离的机制，以及一个服务发现系统。随着时间推移，自动化变得越来越复杂，角色变化或者故障转移时的问题千奇百怪，修都修不完。（呵，熟悉的味道）

---

为了给 MySQL 插上 Raft 的翅膀，Meta 做出了巨大的努力（耗时数年），其中最关键的部分并不开源，普通 MySQL 用户暂时只能流流口水：

1. 在 Apache Kudu 的基础上研发了 kuduraft（开源） ：引入自研的 FlexiRaft 支持两组相关的 quorum，引入代理节点减少网络带宽，分发前对日志进行压缩，支持多种物理日志文件的实现，暂时阻止某些节点成为主节点。
2. 基于 MySQL Plugin 机制实现了 MyRaft（闭源） ：劫持 MySQL 原生 Binlog 复制，调整节点角色 、清理未完成的事务和 GTID、将 apply-log 改成 binlog、设置节点只读状态。
3. 配套的兜底工具 Quorum Fixer：除了可观测性和 cli 工具外，Meta 还引入了一个工具来修复 Quorum 的异常情况，比如 3 个节点坏了 2 个节点。只要用量大，这种情况几乎是必定出现，没有工具就完蛋。

一些开源爱好者对 Meta 敝帚自珍的行为表示不解，毕竟 Meta 也不靠 MySQL 赚钱，为什么不把关键部分也开源了呢？嗯，也许这个决定是针对小扎的，“老板别裁我”。

---

针对 Meta 对 MySQL 的修改，业界有各种各样的声音。InfoQ 的资深编辑 Renato Losio 收集了几位业界大佬的看法。

• Mark Callaghan，前 Facebook 的 MTS 和 MongoDB 的工程师，认为 MySQL 和 Raft 非常不搭。

  MySQL + Raft 就像花生酱和果冻或披萨、火腿和菠萝一样。

• Databricks 公司的高级主管 Shrikanth Shankar 认为这有点冒险，能做成很了不起。

  人们开玩笑说在飞机飞行时更换飞机发动机，但这就是这个项目的目的。感谢团队实现这一目标！

话说开着飞机换引擎这句话不是之前一个阿里的高管先说的吗，这是传到国外了？还是国外先说的，咱们跟人学的？

• Percona 的创始人 Peter Zaitsev 是个开源倡导者，他反问道：

  为什么 Facebook 构建 MySQL Raft 而不是使用或改进 MySQL Group Replication？

Reddit 上的网友们也没有吝惜自己的观点。
有人说了，别的先不说，我很惊讶为什么 Meta 用 MySQL。当然他被“科普”了。

---

 众所周知，Meta 的好（lao）基（dui）友（shou）Google 在自家的数据存储例如 Spanner、Chubby 中都广泛使用了 Paxos 作为一致性协议，那 “为什么 Facebook 构建 MySQL Raft？而不是用基于 Paxos 的 MySQL Group Replication 呢？”， 小猿姐也请教了咱们的技术大牛们。他们也给出了他们的推测。

主要原因是 Meta 对数据库写入延迟的要求比较高。因为 MySQL 在 Meta 使用太广了，很多现金牛业务，例如广告、消息流业务都用 MySQL。尽管 Meta 的工程师很能打，想开发出高性能的业务也离不开一个低延迟的数据库。

硬币的另一面是，Meta 是一家全球化的大公司，数据要容灾到多个地域。要不然巴西的蝴蝶扇一扇翅膀，把美国得克萨斯州的机房给淹了，墨西哥网友刚发的照片上哪儿看去。

而 Meta 自主研发的 Truely Distributed 真正分布式数据库 MySQL Raft 就是解决这个问题的（画风为何如此熟悉）。Meta 实现了一个 Raft 变种协议 FlexiRaft ，传统的 Raft 协议把所有节点都放在一个组里来管理，事务提交也是在这个组，故障重新选举也是在这个组，因此会互相“纠缠”，支持跨地域容灾了嘛，那事务提交也会因为跨区域就慢，真是难平衡呀。而 FlexiRaft 把一个组拆成了两个组，事务在一个组里提交，故障切换在另一个组里搞选举。这样可以做到事务提交不出地域，保证低延迟；好巧不巧遇到地域故障时，又可以把数据库切换到其他地域。鱼和熊掌可以兼得，全自动化处理，算法有 TLA +理论保证，棒棒哒。

而采用 Paxos 算法的 MySQL Group Replication 就没这么灵活了，并且 MGR 还存在一些设计上的缺点。比如为了减少性能损失，MGR 的 Paxos 层里并不持久化日志，多个节点在内存中达成一致后直接提交，这时候如果掉电就存在丢数据的风险。

针对此事，你怎么看？欢迎关注留言，发表你的看法~

---

Meta 的 MyRaft 闭源，但关 KubeBlocks 有开源的 MySQL Raft 什么事～

打开文档，一键拉起本地试用环境，来亲自感受下有啥不一样～

小猿姐诚邀各位体验 KubeBlocks，欢迎你成为产品的使用者和项目的贡献者。

Build your K8s data infra with us！

官网：KubeBlocks

GitHub: apecloud/kubeblocks

也欢迎各位关注小猿姐的微信公众号💙