解密网易MySQL实例迁移高效完成背后的黑科技
|
业务负载并不总是可以预测的,但业务总是最重要的,那么当短暂的业务高峰上来时,我们希望将服务器有限的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.这样,第四个问题也得到了解决. 4如何高效完成迁移相信大家都认同,实例迁移是个重型操作,谁都不会闲得无事对线上库来一把实例迁移.既然决定要进行实例迁移,那么就希望能够一次性完成迁移,避免来回折腾.如何确保高效地迁移就显得尤为重要,用户需先进行迁移评估并完成准备工作,蜂巢RDS通过迁移预检查、提供出错重试等措施来提高迁移成功率. 迁移评估和准备用户首先需在迁移前做好评估工作,包括选择业务低峰期进行迁移,这样既最小化对业务的影响同时也能够提高迁移速度；确认业务连接数据库的配置能够进行一次性切换,缩短切换所需时间,同时避免部分业务逻辑连接源库,另一部分连接目标库导致数据不一致；其次,根据所迁移的数据量,合理选择目标实例的存储空间,避免因为目标实例空间不足导致失败；最后,还需要创建满足迁移要求的数据库账号. 预检查我们希望在开始迁移前就发现所有可能引起迁移失败的因素并纠正.迁移预检查是重要手段,主要包括用户在源实例创建的迁移MySQL账号权限检查、MySQL参数设置检查. （编辑：温州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
