|
作者丨tomkrouper && shlomi-noach 翻译丨Diwei 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下的定时执行工具，可以在无需人工干预的情况下运行作业）自动验证备份文件是否有效。我们为每个集群都设置了一台专用主机，这台主机就是用来恢复最新的备份数据。这样可以确保备份正常运行，并且我们能够从备份中检索数据。 根据数据集大小会选择每天进行几次恢复。恢复后的服务器会按照预期加入到复制流中，并能够赶上复制。这种做法不仅仅是在测试备份文件是否可恢复，而且还可以测试需要识别的时间点是否准确。如果恢复过程中出现问题，我们会收到通知。 还追踪恢复的时间，所以我们很清楚在紧急情况下建立新的副本或恢复需要多长时间。 以下是自动恢复过程中Hubot编写的一些输出信息。 使用备份是为了给现有的MySQL服务器集添加一个新的副本。我们将构建一个新的服务器，一旦被告知它已经准备好，我们就可以开始恢复该特定集群的最新备份。有一个脚本可以运行所有的恢复命令，否则我们将不得不手工操作备份。我们的自动恢复系统实际上使用了相同的脚本。这大大简化了系统的构建过程，并允许我们使用聊天命令行的模式来启动和运行主机。下面显示的是在运行聊天命令行模式的数据恢复方法： 备份失败 使用Orchestrator （使你能够在工作环境中自动创建、监视和部署资源）为使用者执行自动化故障切换。期望Orchestrator可以正确检测master是否出现故障，然后可以指定副本进行升级，在所指定的副本下修复拓扑以后再升级。希望VIPs能够改变，池可以改变，客户端可以重新连接，puppet可以运行必要的组件等等。故障切换是一个复杂的任务，涉及到基础架构的许多方面。 为了建立对故障切换的信任，建立了一个类生产的测试集群，然后让它不断的崩溃以观察故障切换功能。 类生产环境与生产环境在很多方面的设置是完全相同的：硬件类型，操作系统，MySQL版本，网络环境，VIP，puppet配置，haproxy设置等。唯一不同之处在于测试集群不发送/接收生产流量。 在测试集群上模拟写入负载，同时避免复制延迟。写入负载不会超荷，但是有一些查询，这些查询是有意在相同的数据集中写入的。这在正常的时期作用并不明显，但事实证明是有用的，我们将会简要描述。 测试集群有三个数据中心的代表服务器。希望故障转移可以在同一数据中心内的服务器能够在对方时效时自动接替彼此的工作。希望能够在这样的约束下尽可能多地抢救出尽可能多的复制品，这些复制品能够尽可能的适用。orchestrator对拓扑结构没有先前的假设，它只能对出故障时的状态做出反应。 然而，我们有兴趣为故障转移创建复杂而多变的场景。我们的故障转移测试脚本为故障转移准备了理由： 它识别现有的master； 它重构了拓扑结构，使所有三个数据中心的代表成为主控。不同的DC具有不同的网络延迟，并且预期会在不同的时间对主机的崩溃做出反应； 它选择一个解决崩溃方法。 我们选择杀掉master（kill -9）或网络划分它：iptables -j REJECT（nice-ish）或iptables -j DROP（无响应）。 脚本继续通过选择的方法使master崩溃，并等待orchestrator可靠地检测到崩溃并执行故障转移。虽然我们期望检测和升级在30秒内完成，但脚本并不会如你所愿，它在查找故障切换结果之前浪费掉一段指定的时间。比如： 检查一个新的（不同的）主人是否到位； 集群中有大量的副本； master是可改变的； 对master的写入在副本上可见； 更新内部服务发现条目（新主人的身份如预期;旧主人已删除）；
免责声明：本网站内容由网友自行在页面发布，上传者应自行负责所上传内容涉及的法律责任，本网站对内容真实性、版权等概不负责，亦不承担任何法律责任。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，并请自行核实相关内容。本站不承担此类作品侵权行为的直接责任及连带责任。如若本网有任何内容侵犯您的权益，请及时联系我们，本站将会在24小时内处理完毕。
发布者:admin
|
京公网安备11010802031211号