MySQL基础架构自动化测试分析

　　MySQL对于GitHub的重要性不言而喻，本文作者从MySQL的备份、自动测试能否成功从备份恢复数据、模拟各种 master 可能挂掉的情况、自动测试 failover 是否正常、自动测试 schema 迁移等几个方面说明了为何会相信MySQL自动化。以下为译文。

　　对于GitHub来说，MySQL的基础架构是非常重要的组件。MySQL给GitHub.com、GitHub的API、身份验证等提供服务。每个git请求都或多或少会接触到MySQL。我们的任务是保持数据的可用性和完整性。即使MySQL集群服务出现意外了，也需要能够执行一些任务，比如繁重的清理工作、临时更新、在线模式迁移、集群拓扑重构、池化和负载平衡等等。我们有基础设施来自动化这些操作。在本文将分享一些例子，说明如何通过持续测试来建立我们对基础设施的信任。

　　备份

　　对数据进行备份是非常重要的。如果还没有进行备份，那么这就是一个潜在的问题。Percona Xtrabackup是用来为MySQL数据库提供完整备份的工具。如果有一些已经确定需要保存的数据，也有一个专门备份数据的服务器。

　　除了完整的二进制备份之外，每天还运行几次逻辑备份。这些备份使工程师能够获得最新的数据。有时，他们希望从表中获得一组完整的数据，这样他们就可以在跟生产数据量一样的表上测试索引的更改是否有效，或者从某个时间点查看数据。Hubot允许恢复一张备份的表，当表已经导入好以后，它就会ping给我们。

　　数据被加载到非生产数据库，该数据库可供那些提出恢复数据要求的工程师们访问。

　　最后一种进行数据备份的方法是使用延时复制。与其说是一种备份，倒不如说是对数据的一种保障。对于每个生产集群，有一个延迟4小时复制的主机。假如某个查询没有运行，我们会在chatops（即一种会话驱动型开发的做法）上运行mysql panic。这将导致所有的延迟复制立即停止复制，然后“呼叫”数据库管理员。

　　这样就可以使用延迟复制来验证是否存在问题，然后将二进制日志快速转发到发生错误之前的位置。然后，我们可以将那个点之前的数据恢复到主服务器。

　　虽然说备份这个功能设计的很棒，但是如果一些未知或未捕获的错误导致备份没有成功，它们就会变得毫无价值。使用脚本恢复备份的好处就是它允许我们通过cron（是一个linux下的定时执行工具，可以在无需人工干预的情况下运行作业）自动验证备份文件是否有效。我们为每个集群都设置了一台专用主机，这台主机就是用来恢复最新的备份数据。这样可以确保备份正常运行，并且我们能够从备份中检索数据。

　　根据数据集大小会选择每天进行几次恢复。恢复后的服务器会按照预期加入到复制流中，并能够赶上复制。这种做法不仅仅是在测试备份文件是否可恢复，而且还可以测试需要识别的时间点是否准确。如果恢复过程中出现问题，我们会收到通知。

　　还追踪恢复的时间，所以我们很清楚在紧急情况下建立新的副本或恢复需要多长时间。