环境说明
数据库 | 版本 | 数据量 | 备注 |
Database A | 5.7 | 1TB | 需迁移数据200GB |
Database B | 5.6 | 7TB | 需迁移数据600GB |
Database C | 5.7 | -- | 数据迁入800GB |
迁移需求
新建DatabaseC,将DatabaseA和DatabaseB的数据迁移到DatabaseC,其中DatabaseA/B仅部分表需保留数据,其余表保留结构即可
业务停机时间
业务允许停机时间最长为2小时
本次迁移为了搭建测试环境供业务测试使用,对数据准确性无要求,受硬件条件以及时间需求限制,无法采用物理备份/复制等手段,采用mysqldump进行拆分导出导入
导出数据
mysqldump -uxxx -pxxxx -S xxxx--set-gtid-purged=OFF --single-transaction db `cat tab_list.txt` >table.sql
恢复数据
Set names utf8mb4;
Sourcetable.sql
尽管通过人为拆分为并行导出导入,但导入时会创建大量索引,索引创建过程无法并行,总体耗时约40h,无法满足业务需求.
b.第二次迁移测试
本次迁移测试采用传输表空间,过程大致如下
主要步骤 | 操作 | 耗时 |
备份表结构 | 备份Database A/B的数据结构 | 1min |
传输ibd文件 | 传输备份文件到Server C | 150min |
恢复表结构 | 在serverc 恢复Database A/B的数据结构 | 2min |
替换表空间 | 分离idb文件并导入传输过来的bd文件 | 200min |
备份结构
mysqldump -uxx -pxx -S xx --set-gtid-purged=OFF -d dbname > table_Structure.sql
mysqldump -uxx -pxx -S xx -n -t-d -R --triggers=false --set-gtid-purged=OFF dbname >procedure.sql
恢复表结构
Set names utf8mb4;
Source table_Structure.sql
Sourceprocedure.sql
替换表空间
分离ibd文件
Alter table xxx discard tablespace;
传输idb文件
scp `cat table_list.txt` 10.25.225.243:/mysqldata/mysql/data/material
导入idb文件
Alter table xxx import tablespace;
测试耗时约6h,让仍然无法满足业务要求,分析瓶颈在以下两方面:
传输文件通过千兆网络,耗费大量时间
import tablespace过程中, mysql需要更新ibd文件每个page的lsn,产生大量IO操作,耗时较多;
步骤 | 操作 | 耗时 |
物理备份 | 使用innodbbackupex备份DatabaseA/B | 在线 |
传输备份到 | 传输备份文件到Server C | 在线 |
恢复Database B | 使用备份文件在Server C恢复database B | 在线 |
升级database C | 将database C升级到5.7 | 在线 |
清理数据 | 清理不需要数据的表,仅保留数据结构 | 在线 |
创建database A | 在Database C创建database A相关对象结构信息 | 在线 |
恢复Database A | 使用传输表空间的方式恢复database A到database C | 在线 |
配置多源复制 | 配置Database C从database A/B同步数据 | 在线 |
正式割接 | 断开复制,修改database C参数 | 5min |
物理备份
对A/B数据库进行物理备份
innobackupex --user=xx -pxx --socket=xx --no-timestamp ./full
innobackupex --user=xx -pxx --socket=xx --no-timestamp --incremental ./inc/inc1/--incremental-basedir=./full
innobackupex --user=xx -pxx --socket=xx --no-timestamp --incremental ./inc/inc2/--incremental-basedir=./inc/inc1
恢复备份
使用备份恢复databaseB
innobackupex--defaults-file=/etc/my.cnf --parallel=16 --apply-log --redo-onlyfull/ &
innobackupex--defaults-file=/etc/my.cnf --parallel=16 --apply-log --redo-only--incremental-dir=rec0/ full/ &
innobackupex--defaults-file=/etc/my.cnf --parallel=16 --apply-log --redo-only--incremental-dir=rec1/ full/
升级database c
mysql_upgrade --upgrade-system-tables -uroot -pxxx
恢复database A到database C
恢复过程同第二次迁移测试,此处使用物理备份的ibd文件进行导入.
清理多余的数据
Truncatetable xxx;
配置复制
通过物理备份获取gtid相关信息,并配置两个复制通道,分别为databaseA和databaseB复制数据
reset master;
SET@@GLOBAL.GTID_PURGED=xxxxxx,xxxxxxx;
change master to
master_host=xxx,
MASTER_PORT=xx,
master_user=repl,
master_password=xx,
master_auto_position=1
FOR CHANNEL chnl1;
通过以上方式,业务停机时间仅为应用修改切换连接串时间,仅需几分钟即可,满足业务需求。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/130077.html
摘要:什么是作为的子项目,是一款基于的企业批处理框架。首先,运行的基本单位是一个,一个就做一件批处理的事情。总结为我们提供了非常实用的功能,对批处理场景进行了完善的抽象,它不仅能实现小数据的迁移,也能应对大企业的大数据实践应用。 前言 本文将从0到1讲解一个Spring Batch是如何搭建并运行起来的。本教程将讲解从一个文本文件读取数据,然后写入MySQL。 什么是 Spring Batc...
摘要:引言前段时间搭建了版本运行了有一段时间了,现在日志来量有点大遇到了一个突出的问题清理历史数据十分缓慢。 引言 前段时间搭建了sentry 7.x版本,运行了有一段时间了,现在日志来量有点大 遇到了一个突出的问题:清理历史数据十分缓慢。最近在浏览sentry官方文档 发现都已经更新到8.14.1了, 而且不在支持mysql, 官方给的解释:Due to numerous issues...
阅读 1346·2023-01-11 13:20
阅读 1684·2023-01-11 13:20
阅读 1132·2023-01-11 13:20
阅读 1858·2023-01-11 13:20
阅读 4100·2023-01-11 13:20
阅读 2704·2023-01-11 13:20
阅读 1385·2023-01-11 13:20
阅读 3597·2023-01-11 13:20