迁移 TB 级 MySQL 实战

前期准备

公司打算把放在 AWS RDS 上的数据迁移到 GCP 的 CloudSQL 上去。目前我们再 AWS RDS 上的数据有超过 4TB 的数据,用常规的方法还是比较吃力的。

之前调研了一下 google 提供的迁移工具 DMS,但是这个工具像个玩具一言难尽,我觉得从性能和好用来说远远比不上之前我是用过的 aliyun 的 DTS. 在正常的情况下只能保证 3MiB/s 左右的速度,对于我们的数据量来说简直是小水管。光导一次数据就需要一周的时间。由于 AWS 上的 binlog 最多只提供 7 天的存储,所以大于 7 天的方案我们是无法使用的。 

之后我也尝试了一下 pxb,和 mysqldump。pxb 是因为不支持 AWS RDS 而放弃,而 mysqldump 是因为它的性能不行遂放弃。

最终我把目光放到了和 pxb 一样同属 percona 的另外一款工具上 mydumper。

所以最终我敲定了如下流程:

迁移 TB 级 MySQL 实战

 

流程中

1. 首先将 mysqldumper 下载和部署到处理这个任务的 gcp 机器上。

Ubuntu 

sudo apt-get install cmake g++ git
sudo apt-get install libglib2.0-dev zlib1g-dev libpcre3-dev libssl-dev
sudo apt-get install libmysqlclient-dev
sudo apt-get install libatomic1

sudo wget https://github.com/maxbube/mydumper/releases/download/v0.10.7-2/mydumper_0.10.7-2.focal_amd64.deb
sudo dpkg -i mydumper_0.10.7-2.focal_amd64.deb

弄完之后我们就已经可以在机器上使用 mysqldumper 和 mysqlloader 了。

 

2. 接下来我们将 AWS RDS 里面的数据拷贝到现在 gcp 机器的某个目录下面(需要确保磁盘足够大,也要确保 iops 性能网络带宽等 这会严重决定你的迁移速度)

mydumper -h <hostname> -p <password> -u <uusername> -o <target-path>  --lock-all-tables --chunk-filesize 2048 --events --routines --triggers

这里有个参数特别值得说一下就是 chunk-filesize,chunk-filesize 这个参数会决定当单个文件到多大之后来对文件进行切割,单位是 M. 切割文件会影响什么呢,最后会影响到 myloader 执行的速度。因为最后再 myloader 的步骤

的时候是可以使用多线程执行的,到时候可能会面临一个 u 对应一个文件的情况。如果你都是大文件,到时候再 loader 的时候就无法使用多线程来加快导入的速度,你可能会非常的痛苦。因为我们的情况我选择了 2048M 这个大小,当然你可以根据你的实际情况来设置这个参数。另外不得不 highlight 一下,这个参数如果设置得太小则会严重影响 dump 的效率,这是一个经验值,所以建议大家多试几个参数,找到一个合适的参数再开始跑会让你事半功倍。因为实际测试 中,我之前开 512 开得比较小速度只能跑到 512Mbit/s 差不多但是当我调整到 2048 之后我能跑到 3GBit/s。所以建议大家多试几个参数,再让他跑起来,因为迁移数据大所以这个速度非常重要。

接下来就是漫长的等待了和监控流程了。

 

3. 等了很久数据终于被导到了目标机器,现在需要执行 myloader 将数据导进目标数据库。

myloader --host=<hostname> --user=<username> --password=<password> --directory=<dir> --queries-per-transaction=50000 --threads=16 --compress-protocol --verbose=3 -e 

然后就又是漫长的等待。

 

4. 数据终于导入进去之后,我们去之前那台被停下来的 AWS RDS replica 查看当前 binlog 位置 

show master status

并将位置作为CloudSQL 的源头。然后将 AWS RDS replica 重新拉起来去跟上 master。

同样的 CloudSQL 也将 RDS replica 作为 master 开始追赶 binlog 位置即可。

 

总结

总的来说,一切的瓶颈还是在机器性能和网络带宽上。面对大数据量的迁移,网络带宽对于时间的 影响基本上起了决定性的作用。我们只能通过并发工具,还有其他调优来尽量减少这个时间。

以上。

 

 

Reference:

https://github.com/maxbube/mydumper/tree/v0.10.7-2  mysqldumper

https://medium.com/tensult/mydumper-myloader-and-my-experience-of-migrating-to-aws-rds-ff74fc9c1add  MyDumper, MyLoader and My Experience of migrating to AWS RDS

https://severalnines.com/database-blog/mysql-cloud-online-migration-amazon-rds-your-own-server-part2  MySQL in the Cloud - Online Migration from Amazon RDS to Your own Server: Part2

https://cloud.google.com/sql/docs/mysql/replication/configure-external-replica  配置外部副本

https://www.youtube.com/watch?v=77JMe-EHIU8  Best Practices for Migrating to Cloud SQL for MySQL (Cloud Next '18)

https://cloud.google.com/blog/products/databases/how-broadcom-migrated-to-google-cloud-sql  Continuous migration to Cloud SQL for terabyte-scale databases with minimal downtime

上一篇:阿里数据库SRE


下一篇:阿里云系类(二) ECS RDS