记录一次300G，10E条数据的数据库迁移工作

最新推荐文章于 2023-11-24 20:14:52 发布

keep丶

最新推荐文章于 2023-11-24 20:14:52 发布

阅读量4.1k

点赞数 7

分类专栏： mysql 文章标签： mysql 数据库

本文链接：https://blog.csdn.net/qq_38688267/article/details/109090926

版权

mysql 专栏收录该内容

14 篇文章 5 订阅

订阅专栏

版权说明： 本文由博主keep丶原创，转载请注明出处。
原文地址： https://blog.csdn.net/qq_38688267/article/details/109090926

背景介绍

我接手的平台是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。
简单来说，--single-transaction --master-data=2的意思就是导出的是当前时刻的数据，不受导出过程中表数据变化影响。
–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、需要配置新环境的各个服务参数，保持与原服务器一致或设置更合适的值。

     希望本文对大家有所帮助或启发。码字不易，觉得写的不错的可以点赞支持一下哦~