在 Meta 构建和部署 MySQL Raft( 四 )


我们必须增强 kuduraft 以使其在可用性方面更加稳健 。这些改进不是核心协议的一部分,但可以被视为它的工程附加组件 。Kuduraft 支持预选,但预选仅在故障转移期间进行 。在优雅的领导权交接过程中,指定的候选人直接进入真正的选举,连任 。这会导致领导者卡住(kuduraft 不会自动降压) 。为了解决这个问题,我们添加了一个模拟选举功能,它类似于预选,但只有在优雅地交接领导权时才会发生 。由于这是一个异步操作,因此不会增加促销停机时间 。模拟选举将排除真正的选举会部分成功并陷入困境的情况 。
Handling byzantine failures:Raft 的成员列表被认为是 Raft 自己加持的 。但是在提供新成员期间,或者由于自动化竞赛,可能会出现两个不同的 Raft 环相交的奇怪情况 。这些僵尸成员节点必须被淘汰,并且不能相互通信 。我们实施了一项功能来阻止从此类僵尸成员到环的 RPC 。在某些方面,这是对拜占庭演员的处理 。在注意到部署中发生的这些罕见事件后,我们增强了 Raft 实施 。
监控 MySQL Raft 部署在启动 MySQL Raft 时,目标之一是降低随叫随到的操作复杂性,以便工程师能够找到根本原因并缓解问题 。我们构建了几个仪表板、CLI 工具和scuba表来监控 Raft 。我们向 MySQL 添加了大量日志记录,尤其是在促销和成员变更方面 。我们为环上的法定人数和投票报告创建了 CLI,这有助于我们快速确定环何时以及为何不可用(破碎的法定人数) 。对工具和自动化基础设施的投资是齐头并进的,可能比服务器变更的投资更大 。这项投资获得了丰厚的回报,减少了运营和入职培训的痛苦 。
法定人数修复者虽然这是不可取的,但仲裁确实时不时地被打破,导致可用性损失 。典型的情况是自动化没有检测到环中不健康的实例/logtailer 并且没有快速替换它们 。发生这种情况的原因可能是检测不力、工作队列过载或缺少备用主机容量 。当法定??人数中的多个实体同时宕机时,相关故障不太常见 。这些不会经常发生,因为部署会尝试通过适当的放置决策来隔离仲裁中关键实体的故障域 。长话短说:尽管有现有的保障措施,但在规模上,意想不到的事情还是会发生 。需要有可用的工具来缓解生产中的这种情况 。我们基于对这一点的预期构建了 Quorum Fixer 。
Quorum Fixer 是一种用 Python 编写的手动修复工具,可以抑制环上的写入 。它进行带外检查以找出最长的日志实体 。它强行改变了 Raft 内部领导者选举的法定人数期望,以便被选中的实体成为领导者 。成功升级后,我们重置法定人数期望值,环通常会变得健康 。
不自动运行这个工具是一个有意识的决定,因为我们想要找到根本原因并确定所有仲裁丢失的情况,并在此过程中修复错误(而不是让它们默默地被自动化修复) 。
推出 MySQL Raft在大规模部署中从半同步过渡到 MySQL Raft 是很困难的 。为此,我们创建了一个名为 enable-raft 的工具(在 Python 中) 。Enable-raft 通过加载插件并在每个实体上设置适当的配置(mysql sys-vars)来协调从半同步到 Raft 的转换 。此过程涉及环的一小段停机时间 。随着时间的推移,该工具变得健壮,可以非常快速地大规模推出 Raft 。我们已经用它来安全地推出 Raft 。
测试和影子工作流程不用说,改变MySQL的核心复制管道是一个非常困难的工程 。由于数据安全受到威胁,因此测试是信心的关键 。我们在项目期间显着利用了影子测试和故障注入 。在每次 RPM 包管理器推出之前,我们会在测试环上注入数千次故障转移和选举 。我们将触发测试资产的替换和成员更改以触发关键代码路径 。
具有数据正确性检查的长期运行测试也很关键 。我们有每晚在分片上运行的自动化,确保主副本和副本的一致性 。我们会收到任何此类不匹配的警报,并对其进行调试 。
表现Raft 写路径延迟的性能相当于半同步 。半同步机制稍微简单一些,因此预计会更精简,但是我们优化了 Raft 以获得与半同步相同的延迟 。我们优化了 kuduraft 以不再向队列中添加任何 CPU,尽管它引入了以前在服务器二进制文件之外的更多职责 。
Raft 对提升和故障转移时间进行了数量级的改进 。优雅的晋升,这是车队领导层变动的主要部分,得到了显着改善,我们通常可以在 300 毫秒内完成一次晋升 。在半同步设置中,由于服务发现存储将成为事实来源,客户端注意到升级完成的时间会长得多,从而导致最终用户在分片上的停机时间增加 。
Raft 通常会在 2 秒内进行故障转移 。这是因为我们每 500 毫秒为 Raft 健康跳一次心跳,并在连续三个心跳失败时开始选举 。在半同步世界中,这一步是编排繁重的,需要 20 到 40 秒 。因此,Raft 将故障转移案例的停机时间缩短了 10 倍 。


推荐阅读