解密网易MySQL实例迁移高效完成背后的黑科技(2)

为了能够避免持锁时间过长导致业务的写操作被阻塞,使用蜂巢RDS进行实例迁移时,用户可以选择允许持有读锁的最长时间,如下图所示,如果超过该阈值时间,会无条件解锁并让迁移操作失败,用户可以选择在业务低峰期进行重试.

在顺利加锁建立一致性快照并解锁后,就进入到各种Schema和表数据的导出环节,用户应根据源实例的线上业务负载和实例的服务器IO能力来合理选择导出数据的并发线程数,如上图所示.

业务负载并不总是可以预测的,但业务总是最重要的,那么当短暂的业务高峰上来时,我们希望将服务器有限的IO能力还给业务,而不是用在迁移上.蜂巢RDS提供了负载监控阈值选项,在业务负载超过该阈值时,会暂停迁移操作,直到负载重新低于阈值.如果用户选择了多线程导出,则能够根据业务负载动态调整线程个数,确保在业务优先的前提尽可能快速的完成数据导出操作.下图为基于业务负载自适应调整导出线程的例子.

在逻辑导出过程中,还会根据用户提供的迁移账号权限,选择性调整InnoDB BP参数来最大限度减小迁移连接的查询操作对BP热点数据的污染.尽可能将因迁移而进入BP的数据保留在BP的LRU List冷数据一侧,并尽快被替换出BP,详见参考文献4.当然设置BP的参数需要账号有Super权限,对于公有云上的源实例,无法进行该项优化.

使用与mydumper配套的多线程恢复工具myloader来将备份的数据导入到目标RDS实例上,myloader执行流程如下图所示.由于此时目标实例没有负载,所以可以尽可能调大导入并发线程数,将目标实例的IO能力吃满.此外,在数据导入时,我们通过关闭slow log和binary log,将innodb_flush_log_at_trx_commit设置为0来最大限度提高导入性能,在完成数据导入后再将对应的参数调整为原值.这是我们解决第三个问题的方法.

在完成数据导入后,对于全量迁移的场景,迁移就结束了.若选择增量迁移,还需将数据导出和导入时在源实例上产生的增量数据(Update/Delete)也迁移到目标实例,我们采用MySQL复制的方式来同步这些数据.

由于MySQL 5.5、5.6和5.7版本的复制存在较大差别,我们根据源实例的版本选择对应的目标实例版本.对于MySQL 5.5及更低版本的源实例,选择网易开源MySQL版本InnoSQL 5.5.30作为目标RDS实例版本,对于MySQL 5.6和5.7,选择InnoSQL 5.7.12为目标实例版本.进行上述版本配对的原因在于：

一是希望用户尽可能采用MySQL最新的稳定版本5.7,因为MySQL 5.7是有史以来最好的版本,带来了众多优秀的特性,包括基于GTID的复制、sys表等,同时相比之前的版本解决或优化了大量缺陷或不足.

二是能够更加方便地配置复制.MySQL 5.7版本提供了基于GTID和基于BinLog两套复制机制,针对源实例的不同的复制配置,能无缝适配.用户在迁移源实例时,可选择迁移实例上全部数据库,也可选择仅迁移部分数据库,MySQL 5.7版本可使用新增的“CHANGE REPLICATION FILTER”语法在线进行过滤复制设置而无需重启mysqld.由于MySQL 5.5及更低版本无法满足MySQL 5.7版本与之建立复制所需的实例UUID,所以目标实例使用InnoSQL 5.5.30版本.当然,相比社区版MySQL 5.5.30,InnoSQL 5.5.30实现了在线过滤复制功能.

我们采用并行复制技术来提高增量数据同步的效率,快速缩短主从复制延迟.由于MySQL 5.6版本GTID特性并不完善,在将其迁移到MySQL 5.7版本时,采用基于DATABASE的并行复制方式,避免LOGICAL_CLOCK并行复制时由于GTID EVENT未记录并行信息导致复制出错的bug.这样,第四个问题也得到了解决.