• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

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

互联网 diligentman 2周前 (10-18) 11次浏览

版权说明: 本文由博主原创,转载请注明出处。
原文地址: 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左右。大表信息如图:

记录一次300G,10E条数据的数据库迁移工作
 
       我以前的项目都是些小项目,数据量最大的也就百万级,我以前的认知中,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

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

修改从库的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时,可以去找几张表看下数据是否一致,都没问题表示数据迁移成功。

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

总结:
     数据库的迁移工作是服务上云工作中的重要一环,但也只是其中一环。其他需要注意的还有:
        1、当前服务器所在网段是否依赖/搭建DNS服务,如果存在,则需要考虑DNS服务器是否会对服务上云造成影响。
        2、除了数据库数据,是否还存在其他数据,比如文件系统的数据,图片、视频等数据。如果存在则也需要同步数据。
        3、需要配置新环境的各个服务参数,保持与原服务器一致或设置更合适的值。
     
     希望本文对大家有所帮助或启发。码字不易,觉得写的不错的可以点赞支持一下哦~


喜欢 (0)