版权说明： 本文由博主原创，转载请注明出处。
原文地址： https://blog.csdn.net/qq_38688267/article/details/109090926
文章目录
- 背景介绍
- 数据库概况
- 迁移方案确定
- 具体步骤
-
- 1、通过mysqldump备份现有数据库数据
- 2、从库读取备份
- 3、建立主从同步
-
-
- 查询`mysqldump.sql`中的bin-log日志节点信息
- 修改从库的MASTER信息
- 检查是否成功
-
背景介绍
我接手的平台是17年开始开发的，当时没有用云服务器，而是用公司自己的机房。
自己维护服务器的问题还是很多的，首先是稳定性没法保证，就我入职这几个月下来，所在大楼停电保养就弄了两次，然后还有一次意外停电，一次网络光纤被挖机挖断了。。。就各种各样的突发情况导致系统无法正常提供服务，严重影响用户体验。
其次是硬件维护成本较高，不论是主机的日常维护，还是硬件问题解决、硬件扩展等都挺麻烦的。因为我司的服务器都是实体机上创建的虚拟机，一旦需要动硬件就会影响到该主机上的所有服务。
所以服务上云工作刻不容缓。而上云工作中的重中之重就在数据库的迁移。
数据库概况
平台数据库用的MySQL5.7，没有做任何优化，读写分离、主从都没有！运行了两年多，200多张表，大概10E条数据，最大的表将近3E数据，data文件夹大概300G左右。大表信息如图：
我以前的项目都是些小项目，数据量最大的也就百万级，我以前的认知中，MySQL处理亿级数据应该挺慢的（不知道这个思想是怎么形成的，可能是看多了各种MySQL优化的文章），没想到哪怕是查询2.7E数据的表，速度也还是非常可观的！当然order_id表肯定是加了索引的。
mysql> select * from insp_order_chklist where order_id = 1316429177167155200
> OK
> 时间: 0.059s
迁移方案确定
其实在数据库迁移的同时，我也决定将MySQL版本升级成MySQL8.0，所以我先用Navicat同步了数据过去后进行了测试，确定升级版本不会影响现有功能。
数据迁移最大的问题不是将这300G数据迁过去，而是需要在服务切换时，确保两边数据库数据一致！
所以显然通过Navicat工具同步是不现实的，300G的数据不是一时半会能一次性同步完的，系统也不可能专门停止一天的服务来实现数据迁移工作。最后跟一群大佬请教后决定用mysqldump工具初始化云服务器数据库数据，再将现有数据库与云服务器数据库搭建主从，实时同步数据。确保在后续任何时间进行上云时，数据都是一致的！
具体步骤
首先需要开启主库的bin-log日志，设置唯一server-id，从库也设置唯一server-id，这个就不多说了。
数据库操作非同小可，请谨慎操作，在不熟悉的情况下，建议先在TEST或本地操作一遍，熟悉流程后再操作生产环境~
1、通过mysqldump备份现有数据库数据
- –single-transaction
表示此次mysqldump过程中处于同一个事务中，即同步过程中的修改不会被同步。 - –master-data
将二进制日志文件的名称和位置写入输出。
如果选项值为2，则该CHANGE MASTER TO语句将写为SQL注释，因此仅供参考；重新加载转储文件时，它无效。如果选项值为1，则该语句不作为注释写入，并在重新加载转储文件时生效。如果未指定选项值，则默认值为1。 - –databases
需要备份的database名，如果多个则空格隔开
mysqldump -uroot -proot --single-transaction --master-data=2 --databases YOUR_DB1 YOUR_DB2 > mysqldump.sql
需要注意的是，该操作会有一个
flush tables的操作，该操作会锁所有表，导致所有其他SQL等待，包括查询SQL。我操作的时候大概锁了8S左右，数据库越大锁的越久，各位谨慎操作！！！
更多mysqldump信息请参阅：MySQL官方文档-mysqldump
2、从库读取备份
## 我的备份文件较大，且需要传出到云服务器上，因此我先压缩一下
# 安装 pigz 工具
yum -y install pigz
# -p 20 使用20个CPU并发进行压缩
pigz -p 20 mysqldump.sql
## 压缩完通过scp命令传输到目标服务器
#root@123.123.123.123是目标服务器登录用户@IP
scp ./mysqldump.sql.gz root@123.123.123.123:/home
# 解压
pigz -d mysqldump.sql.gz
# 恢复备份
mysql -uroot -p
source /home/mysqldump.sql
3、建立主从同步
查询mysqldump.sql中的bin-log日志节点信息
> less /home/mysqldump.sql
修改从库的MASTER信息
## 修改MASTER信息
CHANGE MASTER TO MASTER_HOST='123.123.123.123', MASTER_USER='rep1',MASTER_PORT=3306,MASTER_PASSWORD='slavepass',MASTER_LOG_FILE='mysql-bin.000003',MASTER_LOG_POS=73;
## 查看slave状态
show slave status;
## 开启同步
start slave;
检查是否成功
刚开启同步时，Seconds_Behind_Master的值可能比较大，这是正常情况，因为他需要先将之前先同步过来。
过一阵后，再检查，依旧没有报错且Seconds_Behind_Master的值为0时，可以去找几张表看下数据是否一致，都没问题表示数据迁移成功。
总结：
数据库的迁移工作是服务上云工作中的重要一环，但也只是其中一环。其他需要注意的还有：
1、当前服务器所在网段是否依赖/搭建DNS服务，如果存在，则需要考虑DNS服务器是否会对服务上云造成影响。
2、除了数据库数据，是否还存在其他数据，比如文件系统的数据，图片、视频等数据。如果存在则也需要同步数据。
3、需要配置新环境的各个服务参数，保持与原服务器一致或设置更合适的值。
希望本文对大家有所帮助或启发。码字不易，觉得写的不错的可以点赞支持一下哦~
