環境說明
數據庫 | 版本 | 數據量 | 備注 |
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;
通過以上方式,業務停機時間僅為應用修改切換連接串時間,僅需幾分鐘即可,滿足業務需求。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/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