存储总量达20T的MySQL实例,如何完成迁移?

王亮 2016-09-06 10:46:53

作者:王亮腾讯云高级工程师。2010年加入腾讯,曾负责腾讯社交产品CDN图片类、动态加速业务的运维工作。现负责数据库产品的解决方案工作。

 

腾讯云数据库团队继承腾讯数据库团队十多年海量存储的内部数据库运营和运维经验,推出一系列高性能关系型、分布式、文档型和缓存类数据库产品,并提供高可用性、自动化运维和易维护的云数据库综合解决方案。

 

某国内大型游戏开发商有超过130个IDC部署MySQL实例,存储总量达20T。因业务需要,将全部实例迁移到腾讯云CDB for MySQL。为保证业务迁移顺利进行,对迁移流程,工具进行了前期的调查研究,并对过程中发现的4大问题进行及时解决,以下是实际迁移经验分享:

 

一、测试用例/过程

 

目前开发商上云(外部MySQL迁移到CDB)提供多种方案,其中开发商的MySQL实例有外网IP的可以直接使用腾讯云数据库迁移工具完成迁移(其他的迁移方法参见:https://www.qcloud.com/doc/product/236/591)。本次迁移任务中该开发商的所有MySQL实例均有外网代理IP供使用,故直接选用迁移工具完成数据导入。

 

迁移工具的基本原理:通过待迁移实例提供的高权限帐号获取源实例基本的MySQL实例配置,并同步到目标CDB实例;通过mysqldump直接将源实例导出传输到CDB实例后导入;源数据库实例和目标CDB建立主从关系同步新数据。其中CDB实例与源IDC之间通过NAT方式以一台带外网的服务器为中转发起通信。

 

 

1迁移工具基本功能

 

在页面http://console.qcloud.com/migrate/migrate/cdb根据引导建立迁移任务;在后台管理页面观察迁移任务后台日志等CDB后台运维。

 

任务开始运行后检测代理机器流量变化,CDB的写入等数据展示:

                                              

 

 

 

 

知识点:如何为测试数据库产生较大的数据量。这里推荐一个工具mysql_gen_data,https://github.com/chunhei2008/mysql_gen_data。产生测试数据并导入到MySQL的过程如下:

 

 

 

后台与腾讯云管理台查看本次测试任务,迁移成功完成。

 

 

2主从以及从机和CDB建立主从的同步

 

由于本次迁移的开发商将使用他们自建IDC的从机向CDB迁移数据,简单关系如下图,之前没有使用迁移工具进行过类似操作,故进行本次测试。

 

 

知识点:如何配置MySQL的主从关系。测试的MySQL主从的配置如下:(主MySQL)

 

server_id = 98

log_bin = binlog

binlog_format = ROW

innodb_stats_on_metadata = off

 

 

后台与腾讯云管理台查看本次测试任务,迁移成功完成。

 

 

3多实例+较大binlog并发同步

 

开发商在经过相关测试后,一期计划15个实例并发迁移到CDB,每天总共产生约100G的binlog。由于之前迁移工具没有大并发使用,且单日有较大数据更新,故提前测试用户场景。测试的基本架构如下图:在一个服务器上开启15个MySQL实例映射到不同端口,15个MySQL实例同时和15个CDB实例建立主从,并发起迁移任务。

 

 

知识点:如何在一台服务器上创建多个MySQL实例?这里使用的MySQL自带的mysqld_multi工具,其实这只是一个perl脚本,开启多实例配置如下(/etc/my.conf)可以视内存大小,开多个mysqld的配置项:

 

 

然后使用mysqld_multi start 1-4启动配置项里面的对应数量实例即可。启动多个MySQL实例如图:

 

 

通过定时update对应数据库实例的数据,产生较大量的binlog,单次update产生700Mbinlog,每2小时执行一次,每天产生700*12*15=126G.简单代码如下:

 

使用数据库迁移工具(http://console.qcloud.com/migrate/migrate/cdb)建立15个迁移任务,控制台和后台检查均迁移成功:

 

 

同时为了检验大量binlog情况下数据完整性,写了简单脚本定时检查数据是否有更新,脚本如下:(这里经过测试发现可以通过广州跳板机直接连接CDB实例的masterIP,故直接在广州跳板机脚本拉取IDC更新数据,同时对比CDB实例数据,写入日志)

 

 

通过校验日志可以看到,数据更新均成功完成。

 

 

 

二、 开发商迁移测试数据记录

 

以上我方内部测试完成后,开发商自行进行了3次迁移,相关数据如下:

 

 

 

某次迁移的带宽表现。

 

由于开发商出口带宽只有约500Mbps,经过测试发现迁移瓶颈主要出现在带宽限制上。实际并发时带宽大小待二期迁移时确认。

 

三、遇到的问题

 

 

1首次创建主从无法连接源数据库

 

现象:每次建任务后总提示源数据库无法连接

 

Error:Can't connect to MySQL server on 10.*.*.*

 

分析解决:由于迁移工具本质是CDB代理经过NAT通过外网和IDCMySQL实例相连,CDB的代理系统时间和NAT外网机器有差异,同时IDC开启连接重用,导致建立连接时前后时间不一致,系统认为为异常包,丢弃,连接失败。直接修改IDC服务器的内核参数,即net.ipv4.tcp_timestamps = 0和net.ipv4.tcp_tw_recycle = 0即可

 

 

2跨版本迁移的存储过程迁移失败

 

现象:开发商在迁移过程中出现proc表无法迁移的现象

 

ERROR:Can't load from mysql.proc. The table is probably corrupted

 

解决:经CDB开发同事确认跨版本迁移的proc表因字段定义不同存在异常,发布版本跳过proc表解决。

 

 

3迁移测试中创建新数据库导致binlog导入失败

 

现象:迁移任务出现错误,无法迁移存储过程,binlog追加失败。

 

errno:1049:Error 'Unknown database 'xxxx'on query.

 

解决:原因为本次迁移选定了只迁移某个数据库,迁移过程中新建了一个数据库,并开启binlog,导致CDB拉到的binlog有新数据库信息,和迁移数据库不匹配。解决方法为迁移过程不要出现DDL操作。

 

 

四、总结

 

有道是:凡事预则立,不预则废。正是因为客户在迁移前我们做好了多项功能测试,性能测试和边界条件测试的预备,才使得在正式数据迁移时未出现数据不一致、现网运营切换故障等任何异常情况,为现网大规模的数据库实例迁移积累了经验。截止目前,客户逾130个MySQL实例都已顺利迁移并开启现网运营。

 

相关专题:

 

 
 
精选专题(点击蓝色标题可阅读全文)

◆  近期热文  ◆  

 

 

MySQL5.7中InnoDB不可不知的新特性

微信支付商户系统的架构揭秘

RTO零切换!山东移动双活容灾最佳研究和实践(上)

引以为戒:记一次心惊肉跳的服务器误删文件的恢复过程

高可用系统设计精要: 定个能达到的小目标,比如先读完本文

 

◆  近期活动  ◆  

Gdevops全球敏捷运维峰会广州站


峰会官网:www.gdevops.com

活动预告