干货 | 携程数据库发布系统演进之路

作者简介

 

天浩，携程数据库专家，专注数据库自动化运维研发工作。

晓军，携程数据库专家，主要负责运维及分布式数据库研究。

一、前言

互联网软件本身具有快速迭代、持续交付等特点，加上数据库的表结构（DDL）发布无法做到灰度发布，且回退困难、试错成本高，一个稳定可靠的数据库发布系统对于互联网公司显得尤其重要。本文将介绍携程MySQL数据库发布系统从无到有，版本不断迭代的演进之路，希望对读者有所参考和帮助。

 

我们先后设计了三个版本，最新的版本具有以下功能和特点：

• 发布期间只有一次表锁，锁定时间极短，锁定时间不受表容量影响；

• Master-Slave复制延迟可控，这点对有读写分离架构且数据实时性要求高的业务尤其重要；

• 自动避开业务高峰，自动识别热表，确保发布期间业务基本无影响；

• 将数据库规范加入发布前校验，对不符合规范的发布进行拦截；

 

介绍整个系统之前，首先对携程数据库环境和发布流程做一个简单的介绍。系统的数据库环境主要分成Dev、测试环境（含三个子环境，功能性测试（FAT）/压力测试（LPT）/UAT 三个环境）、Product：

1）数据库表设计在Dev环境完成，期间包含数据库规范检测

2）然后发布到其它测试环境（FAT→LPT→UAT）

3）测试环境都验证通过后，最后发布到生产环境

 

 表发布流程图

二、初期（1.0时代）

携程成立以来一直使用SQL Server 数据库，2014年左右开始使用MySQL数据库，为后面转型MySQL做准备。这时期接入MySQL的业务量很小，数据量不大，都是非核心业务，所以整个发布过程可以概括为“简单粗暴”：

1）开发人员通过直连DEV环境数据库，直接对数据库表进行修改

2）DBA通过自动化工具捕捉到表的变化，将变更同步到测试环境

3）开发测试完后，将变化同步到生产环境

      

这个阶段只是简单把表的变更传递到其他环境，对发布期间业务和性能方面的影响没有考虑太多。

1.0 版本发布流程

 

三、转型期（2.0时代）

随着业务接入MySQL不断增加，MySQL数据库越来越多，到2016年下半年为止，MySQL 数据库数量已经有800+，很多核心业务也转到MySQL，包含很多读写分离架构。此时原生的DDL发布已经无法满足业务需求，这时引入了业界流行的pt-online-schema-change（pt-osc）。

 

2.0版本发布流程

 

pt-osc是percona开发的一款比较成熟的产品，业界使用也较多。其采用触发器的方式将所有的增量DML应用到了影子表，这种实现方式会加大对语句的开销，并发过高时甚至会影响数据库正常提供服务，因此往往会出现发布一半最后还是不得不终止发布的现象，线上遇到核心的表或者大表往往需要晚上留守来进行发布，这极大的提高了DBA的运维负担。

四、引入gh-ost（3.0时代）

      

为了进一步提升发布稳定性，我们在2017年调研了当时刚开源不久的gh-ost，由于产品非常新，因此做了大量的调研和测试工作，也发现提交了多个高优先级Bug（包括GBK字符集支持、bad connection以及column case-sensitive issue导致数据丢失等），都已得到作者的修复。

 

那么gh-ost对比pt-osc具体有哪些优势呢？下面先简单介绍下它的两个最核心的特性。

 

4.1 Triggerle