英文原文：Making MySQL Better at GitHub

　　GitHub，作为广泛使用的开源代码库以及版本控制系统，其数据库 MySQL 性能的优劣对整个网站平台有着举足轻重的影响。接下来我们一起跟随 GitHub 基础架构团队的步伐，来重温去年 8 月做的一次重大 MySQL 更新，看是如何使得 GitHub 运行得更畅顺的。

　　任务简述

　　自去年开始，我们陆续地把 GitHub 主体架构迁移到新的数据中心，与之配套的是世界级的硬件和网络环境。我们十分希望这次升迁对后端系统基石 MySQL 的性能也有所提高。不过在一个新环境重新建立一个新的服务器集群和硬件平台，并不是件轻易的事情，我们必须做好计划与测试，确保迁移工作顺利完成。

　　准备工作

　　每当要进行类似的重大升级工作，对每个测量和指标量度步骤都会提出严格的要求。为新机器安装好操作系统后，接下来需要根据不同的配置来进行测试。为了得到真实的负载测试数据，我们使用了 tcpdump 对从旧集群系统到新系统执行的 SELECT 查询进行抓包分析。

　　MySQL 性能调整可谓是细节决定成败，例如众所周知的 innodb_buffer_pool_size 的设置，对整体有着举足轻重的影响。为了尽更全面地管控升级过程，我们把 innodb_thread_concurrency、innodb_io_capacity、innodb_buffer_pool_instances 等参数也一并进行分析和研究。

　　每次测试时我们都只改变某一个参数，然后让系统连续运行至少 12 小时。在这过程中不断观察 SHOW ENGINE INNODB STATUS 带来的统计信息，其中 SEMAPHORES 栏目，能很好地反映工作负荷竞争情况。当相关设置测试通过后，接下来我们将尝试把其中一个最大的数据表迁移到一个单独的集群上。作为前期测试的一部分，这样的迁移工作能为日后更大更核心的变更带来指引。

　　除了对基础硬件部分进行了升级，我们还对流程和拓扑进行了优化。例如：延后复制，更快速和高频的备份，提高备带读取能力。一切就绪后，将进入最后的升级阶段。

　　制定升级项目清单，进行二次检查

　　作为每天服务上百万用户的平台，任何差错都将是毁灭性的。我们在进行真实切换前，列出了一个任务清单，确保各项工作有序执行：

• 确保缓冲池在新集群中成功预热
• 在推特等社交平台公告维护开始
• 把网站转为维护等待模式
• 等候所有与旧 MySQL 服务器相关的通信终止
• 把旧服务器设为只读模式
• 从旧集群中移除主要和复制的 VIPs 数据
• 确认所有写入操作已经终止
• 终止 cluster1 的复制
• 获取 cluster1 复制的位置，并告知当前线程
• 重置 cluster1 的复制
• 关闭 cluster1 的只读模式
• 把旧集群连接到新的 cluster1 集群
• 按照 cluster1 连接配置进行应用程式部署
• 确保新连接能通过新集群
• 检查后台工具 resque 的任务(workers)
• 进行阶段检查并确保一切正常
• 把网站转为正常模式
• 在推特等社交平台公告维护结束
• 把 https://github.com/github/xxxx/pull/xxx 整合到主页面

　　迁移当天

　　在周六的上午 5 点太平洋时间)，团队成员就位后，迁移工作正式开始。当用户在这段时间访问网站时，会收到如下的提示：

　　13 分钟后，新集群即将开始正常运作。我们终止了网站的维护模式，并告知大众网站将回复正常。

　　效果评估

　　在接下来的几个星期，我们密切关注了整体性能和响应时间方面的变化。结果是令人欣喜的，页面载入时间减少了将近三分之二：

　　经验总结：

　　1. 功能划分

　　在本次操作中，我们把较大的历史数据记录表放入单独的集群，事后证明这是明智的做法—很好地释放了存储空间和缓冲池空间。同时，能够把更多资源放在活跃数据处理上，连接逻辑的划分也使得程序可以在多个集群间进行查询。以后我们还将采取该方法进行升级。

　　2. 不断测试

　　罗马非一天建成，整个过程需要不断进行验收和回归测试，避免意外的发生。

　　3. 团队的力量

　　如此重大的架构升级需要很多小伙伴协力工作，我们主要使用 GitHub 上的拉请求功能来进行互动交流。部署团队来自世界各地：

　　当开启一个拉请求后，我们将进行实时交流，例如：错误处理，回归处理等信息的交流。每个交流环节都生成一个 URL，方便进行历史查询和反馈。

　　一年后……

　　路遥知马力，一年后，实践证明这是一次成功的操作。MySQL 持续表现符合预期，系统可靠性进一步提高。还有个附加好处是：新系统的扩展性得到提升，将来可进行更大规模的升级和改造。