環(huán)境說明
數(shù)據(jù)庫 | 版本 | 數(shù)據(jù)量 | 備注 |
Database A | 5.7 | 1TB | 需遷移數(shù)據(jù)200GB |
Database B | 5.6 | 7TB | 需遷移數(shù)據(jù)600GB |
Database C | 5.7 | -- | 數(shù)據(jù)遷入800GB |
遷移需求
新建DatabaseC,將DatabaseA和DatabaseB的數(shù)據(jù)遷移到DatabaseC,其中DatabaseA/B僅部分表需保留數(shù)據(jù),其余表保留結(jié)構(gòu)即可
業(yè)務(wù)停機(jī)時(shí)間
業(yè)務(wù)允許停機(jī)時(shí)間最長(zhǎng)為2小時(shí)
本次遷移為了搭建測(cè)試環(huán)境供業(yè)務(wù)測(cè)試使用,對(duì)數(shù)據(jù)準(zhǔn)確性無要求,受硬件條件以及時(shí)間需求限制,無法采用物理備份/復(fù)制等手段,采用mysqldump進(jìn)行拆分導(dǎo)出導(dǎo)入
導(dǎo)出數(shù)據(jù)
mysqldump -uxxx -pxxxx -S xxxx--set-gtid-purged=OFF --single-transaction db `cat tab_list.txt` >table.sql
恢復(fù)數(shù)據(jù)
Set names utf8mb4;
Sourcetable.sql
盡管通過人為拆分為并行導(dǎo)出導(dǎo)入,但導(dǎo)入時(shí)會(huì)創(chuàng)建大量索引,索引創(chuàng)建過程無法并行,總體耗時(shí)約40h,無法滿足業(yè)務(wù)需求.
b.第二次遷移測(cè)試
本次遷移測(cè)試采用傳輸表空間,過程大致如下
主要步驟 | 操作 | 耗時(shí) |
備份表結(jié)構(gòu) | 備份Database A/B的數(shù)據(jù)結(jié)構(gòu) | 1min |
傳輸ibd文件 | 傳輸備份文件到Server C | 150min |
恢復(fù)表結(jié)構(gòu) | 在serverc 恢復(fù)Database A/B的數(shù)據(jù)結(jié)構(gòu) | 2min |
替換表空間 | 分離idb文件并導(dǎo)入傳輸過來的bd文件 | 200min |
備份結(jié)構(gòu)
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
恢復(fù)表結(jié)構(gòu)
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
導(dǎo)入idb文件
Alter table xxx import tablespace;
測(cè)試耗時(shí)約6h,讓仍然無法滿足業(yè)務(wù)要求,分析瓶頸在以下兩方面:
傳輸文件通過千兆網(wǎng)絡(luò),耗費(fèi)大量時(shí)間
import tablespace過程中, mysql需要更新ibd文件每個(gè)page的lsn,產(chǎn)生大量IO操作,耗時(shí)較多;
步驟 | 操作 | 耗時(shí) |
物理備份 | 使用innodbbackupex備份DatabaseA/B | 在線 |
傳輸備份到 | 傳輸備份文件到Server C | 在線 |
恢復(fù)Database B | 使用備份文件在Server C恢復(fù)database B | 在線 |
升級(jí)database C | 將database C升級(jí)到5.7 | 在線 |
清理數(shù)據(jù) | 清理不需要數(shù)據(jù)的表,僅保留數(shù)據(jù)結(jié)構(gòu) | 在線 |
創(chuàng)建database A | 在Database C創(chuàng)建database A相關(guān)對(duì)象結(jié)構(gòu)信息 | 在線 |
恢復(fù)Database A | 使用傳輸表空間的方式恢復(fù)database A到database C | 在線 |
配置多源復(fù)制 | 配置Database C從database A/B同步數(shù)據(jù) | 在線 |
正式割接 | 斷開復(fù)制,修改database C參數(shù) | 5min |
物理備份
對(duì)A/B數(shù)據(jù)庫進(jìn)行物理備份
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
恢復(fù)備份
使用備份恢復(fù)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/
升級(jí)database c
mysql_upgrade --upgrade-system-tables -uroot -pxxx
恢復(fù)database A到database C
恢復(fù)過程同第二次遷移測(cè)試,此處使用物理備份的ibd文件進(jìn)行導(dǎo)入.
清理多余的數(shù)據(jù)
Truncatetable xxx;
配置復(fù)制
通過物理備份獲取gtid相關(guān)信息,并配置兩個(gè)復(fù)制通道,分別為databaseA和databaseB復(fù)制數(shù)據(jù)
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;
通過以上方式,業(yè)務(wù)停機(jī)時(shí)間僅為應(yīng)用修改切換連接串時(shí)間,僅需幾分鐘即可,滿足業(yè)務(wù)需求。
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://m.specialneedsforspecialkids.com/yun/130077.html
摘要:什么是作為的子項(xiàng)目,是一款基于的企業(yè)批處理框架。首先,運(yùn)行的基本單位是一個(gè),一個(gè)就做一件批處理的事情。總結(jié)為我們提供了非常實(shí)用的功能,對(duì)批處理場(chǎng)景進(jìn)行了完善的抽象,它不僅能實(shí)現(xiàn)小數(shù)據(jù)的遷移,也能應(yīng)對(duì)大企業(yè)的大數(shù)據(jù)實(shí)踐應(yīng)用。 前言 本文將從0到1講解一個(gè)Spring Batch是如何搭建并運(yùn)行起來的。本教程將講解從一個(gè)文本文件讀取數(shù)據(jù),然后寫入MySQL。 什么是 Spring Batc...
摘要:引言前段時(shí)間搭建了版本運(yùn)行了有一段時(shí)間了,現(xiàn)在日志來量有點(diǎn)大遇到了一個(gè)突出的問題清理歷史數(shù)據(jù)十分緩慢。 引言 前段時(shí)間搭建了sentry 7.x版本,運(yùn)行了有一段時(shí)間了,現(xiàn)在日志來量有點(diǎn)大 遇到了一個(gè)突出的問題:清理歷史數(shù)據(jù)十分緩慢。最近在瀏覽sentry官方文檔 發(fā)現(xiàn)都已經(jīng)更新到8.14.1了, 而且不在支持mysql, 官方給的解釋:Due to numerous issues...
閱讀 1353·2023-01-11 13:20
閱讀 1699·2023-01-11 13:20
閱讀 1211·2023-01-11 13:20
閱讀 1902·2023-01-11 13:20
閱讀 4161·2023-01-11 13:20
閱讀 2751·2023-01-11 13:20
閱讀 1397·2023-01-11 13:20
閱讀 3664·2023-01-11 13:20