信也数据库发布系统演进之路

一、前言

互联网本身具有快速迭代、持续交付等特点，加上数据库的发布回退困难、试错成本高，一个稳定可靠的数据库发布系统对于互联网公司显得尤其重要。

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

1）发布期间只有一次表锁，锁定时间极短 

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

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

4）通过控制避开业务高峰，确保发布期间业务基本无影响 

5）支持多环境一键发布 

6）支持混合云的发布 

7）支持分库分表跨数据源一键发布

二、初期

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

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

三、转型期

随着SQL Server转MySQL项目的推动，MySQL数据库越来越多，很多核心业务也转到MySQL。此时原生的DDL发布已经无法满足业务需求，这时引入了业界流行的pt-online-schema-change（pt-osc）。

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

四、gh-ost

为了进一步提升发布稳定性，调研了许多大厂以及大量测试，最终选型gh-ost。

在gh-ost出现之前第三方MySQL DDL工具均采用触发器的方式进行实现，包括前面percona的pt-osc，Facebook的OSC等等。而gh-ost采用的机制和他们完全不同：它通过MySQL binlog来同步数据，gh-ost本身注册为一个fake slave，可以从集群中的master或者slave上拉取binlog，并实时解析，将变更表的所有DML操作都重新apply到影子表上面。因此对于发布期间变更表上发生的DML操作，可以完全避免由于触发器而产生的性能开销，以及锁的争抢。

4.2 动态控制

另一个最重要的特性是动态调控，这是此前其他第三方开源工具所不具备的。

之前通过pt-osc发布时，命令执行后参数就没法修改，除非停止重来。假设发布进行到90%，突然由于其他各种原因导致服务器负载上升，为不影响业务，只能选择将发布停掉，等性能恢复再重来。

通过pt-osc发布的表都是很大的表，耗时较长，所以遇到这类场景很尴尬。因此发布中参数如果可动态调控将变得非常重要。gh-ost另外实现了一个socket server，我们可以在发布过程中，通过socket和发布进程进行实时交互，它可以支持实时的暂停，恢复，以及很多参数的动态调整，来适应外界变化。

五、如何做到安全发布？

5.1 运行前 

首先，前端采用类似于DMS的图形化设计，降低研发出错的概率以及写SQL的成本

其次，任务发布时，审核引擎会进行前置规则校验 

5.2 运行时 

1）服务器性能监听：当服务器负载过高，将会自动触发throttle，等性能恢复再重新解除throttle

2）副本延迟监听：避免发布导致延迟加剧，影响实时ETL或读写分离

5.3 运行后 

1）DML还会记录变更之前的镜像，用于快速"误操作"恢复

六、碰到了哪些问题，如何解决？

案例1、MDL锁

当原表数据全部拷贝完成后，gh-ost会进入到表交换阶段，虽然rename是一瞬间的事，但如果此时流量较大，则很容易阻塞，连接数打满，造成故障。

要解决这个问题，我们采取了多种手段：

1、利用gh-ost可暂停的特性：21点开始执行数据库拷贝，待进度为95%自动暂停任务，23点自动唤醒，让rename操作在更低峰执行

2、信也大部分数据库均升级到了8.0，利用8.0秒级增加字段特性，增加字段则调度到23点采用ONLINE DDL，对分库分表或大表的效率以及成功率是质的提升

案例2、大事务

信也科技数据库1/3已经采用的MGR+8.0架构，对大事务有些使用上限制，发布系统会根据主键或唯一键进行拆分，提高发布成功率

总结

以上是信也数据库发布系统的整个演进过程，希望对读者有所参考和帮助，功能上已经较为完善，适应了业务快速迭代的要求，尽可能的降低了发布可能造成的业务故障。

未来，我们还会和框架团队，在数据库熔断、过载保护上做一些探究。

作者简介

招聘信息