作者丨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应用程序的影响较小，其他一些则对迁移逻辑和操作造成了显著的变化。我们将严格地测试这些数据，在我们的生产表舰队中运行，直到满足这些更改不会造成数据损坏威胁。结论通过测试，我们就更想新机器的运作额。通过在生产中做这些自动化测试，我们可以不断的得到一切都如预期的那样运行的确认信息。随着基础架构的继续开发，我们也会通过调整测试从而满足最新的调整。在没有测试的情况下，生产总是令人惊讶的。我们对生产环境的测试越多，我们对应用程序的期望和基础设施的能力就会得到更多的投入。
转载请注明：http://www.aierlanlan.com/rzfs/7925.html
