作者丨tomkrouper旧主人已删除）；
其他内部检查。
这些测试确认故障转移是成功的，不仅是MySQL-wisee，而且是在我们更大的基础架构范围内。人们已经假设了一个VIP;具体的服务已经开始;信息到达了应该去的地方。
该脚本进一步恢复了失败的服务器：
从备份中恢复它，从而隐式地测试我们的备份/恢复过程
验证服务器配置如预期的那样(服务器不再相信它是主服务器)
将其返回到复制集群，期望找到在主服务器上写入的数据
考虑以下预定的可视化故障转移测试:从一个运行良好的集群,看到问题在一些副本,诊断主()死了,选择一个服务器来促进(a79d),重构拓扑低于服务器,为促进它(故障转移成功),恢复死去的主人,将它们转化为集群。
测试失败看起来像什么呢
测试脚本使用了一种stop-the-world的方法。故障转移组件中不管哪个环节出现问题，在管理员解决问题之前，整个过程都是失败的，而且后面的自动化测试也是无法执行的。当然我们会收到提醒，然后检查状态和日志。
测试脚本在以下环节中可能会失败：出现了意外的检测；故障转移期间;在备份/恢复问题上;太多服务器出现宕机;在故障转移后的意外配置上等等。
我们需要确保orchestrator正确地连接到服务器。这就是之前说的写入负载会起作用的地方:如果设置不正确，复制很容易被破坏。我们会得到DUPLICATEKEY或其他错误，以表示出了问题。
这一点尤其重要，所以我们对orchestrator进行了改进,引入了新的行为，并允许我们在一个安全的环境中测试这些更改。
混沌测试即将到来
上面演示的测试过程能够捕获(并已捕获)基础架构的许多问题。但这就够了吗?
在生产环境中总会有各种各样的问题。关于这些特定的测试方法，它不适用于我们的生产集群。它们不共享相同的流量和流量操作，也没有相同的服务器集。失败的类型可能会有所不同。
正在为生产集群设计混沌测试。混沌测试将会在我们的生产中，但是按照预期的时间表和充分控制的方式来破坏碎片。混沌测试引入了对恢复机制的更高级别的信任，并影响(因此测试)更大的基础架构和应用程序。
这是一项微妙的工作:尽管我们承认需要进行混沌测试，但我们也希望避免对服务造成不必要的影响。不同的测试在风险级别和影响方面会有所不同，我们将努力确保服务的可用性。
Schema迁移
我们使用gh-ost从而将生产的schema进行迁移。gh-ost非常稳定，但是现在正在增加或者计划增加一些新的主要的功能，因此现在也处于开发当中。
gh-ost通过将数据复制到ghost表中，将二进制日志所拦截的正在进行的更改应用到ghost表上，即使原始表被写入到这个表中，也可以将表移到表上。然后，它将ghost表替换为原来的表。在迁移完成时，GitHub将继续使用由gh-ost生成并填充的表。
这一次，几乎所有的GitHubMySQL数据都是由gh-ost重新创建的，而且大部分都是重复的。我们必须高度信任gh-ost，让它一次又一次地篡改我们的数据，即使是在开发过程中。下面是我们如何获得信任的方法。
gh-ost提供了一个测试生产能力。它支持在副本上运行一个迁移，就像它在主服务器上运行的方式一样:gh-ost将连接到副本，并将其视为主服务器。它将以与实际主迁移相同的方式解析它的二进制日志。但是，它将复制行并将binlog事件应用到副本中，并避免将写入写入到主服务器上。
我们在生产中运行了专门的专用副本。这些副本不服务于生产流量。每个这样的副本都检索当前的生产表列表，并以随机的顺序迭代它们。一个接一个地选择一个表，并在该表上执行一个复制迁移。迁移实际上并没有修改表结构，而是运行一个简单的引擎=InnoDB。即使在生产中使用表时，测试也会运行迁移，从而复制实际的生产数据，并在二进制日志中应用真正的生产流量。
这些迁移可以被审核。下面是我们如何从聊天中检查运行测试的状态：
当一个测试迁移完成了对表数据的复制时，它停止复制并执行剪切操作，替换原来的表，用ghost表替换原来的表，然后交换回来。我们对实际替换数据不感兴趣。取而代之的是原始表和ghost表，两者都应该是相同的。我们通过检查这两个表的整个表数据来验证这一点。
一个测试可以完成：
成功：一切都很顺利，校验和也一样。我们希望看到这一点。
失败：执行的问题。由于迁移过程被杀死、复制问题等等，这种情况有时会发生，而且通常与ghost本身无关。
校验和失败:表数据不一致。对于经过测试的分支，这需要修复。对于正在进行的主分支测试，这将意味着立即停止生产迁移。我们没有得到后者。
测试结果被审计，发送到机器人聊天室，作为事件发送给我们的度量系统。下面的图中的每一条垂直线代表一个成功的迁移测试:
连续运行这些测试。如果出现故障，我们会收到警报通知。当然，我们也可以去机器人聊天室看看发生了什么。
新版本测试
我们一直在改善gh-ost，我们的开发流程都是基于git的分支，最后再通过pull请求进行合并。
提交的gh-ostpull请求通过持续集成(CI)进行基本的编译和单元测试。从技术上讲，该公司在技术上有资格合并，但更有趣的是，它有资格通过天堂进行部署。作为我们基础架构中的敏感组件，我们需要在合并成主之前，将gh-ost分支部署到密集的测试中。
有些PRs是小的，不影响数据本身。对状态消息、交互命令等的更改对ghost应用程序的影响较小，其他一些则对迁移逻辑和操作造成了显著的变化。我们将严格地测试这些数据，在我们的生产表舰队中运行，直到满足这些更改不会造成数据损坏威胁。
结论
通过测试，我们就更想新机器的运作额。通过在生产中做这些自动化测试，我们可以不断的得到一切都如预期的那样运行的确认信息。随着基础架构的继续开发，我们也会通过调整测试从而满足最新的调整。
在没有测试的情况下，生产总是令人惊讶的。我们对生产环境的测试越多，我们对应用程序的期望和基础设施的能力就会得到更多的投入。