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栏目,能很好地反映工作负荷竞争情况。当相关设置测试通过后,接下来我们将尝试把其中一个最大的数据表迁移到一个单独的集群上。作为前期测试的一部分,这样的迁移工作能为日后更大更核心的变更带来指引。 除了对基础硬件部分进行了升级,我们还对流程和拓扑进行了优化。例如:延后复制,更快速和高频的备份,提高备带读取能力。一切就绪后,将进入最后的升级阶段。 制定升级项目清单,进行二次检查 作为每天服务上百万用户的平台,任何差错都将是毁灭性的。我们在进行真实切换前,列出了一个任务清单,确保各项工作有序执行:
迁移当天 在周六的上午5点太平洋时间),团队成员就位后,迁移工作正式开始。当用户在这段时间访问网站时,会收到如下的提示: 13分钟后,新集群即将开始正常运作。我们终止了网站的维护模式,并告知大众网站将回复正常。 |