數據庫作為數字化用戶的核心資產,其遷移是一項復雜且重要的任務,特別是在VMware平臺替換及IT基礎設施更新換代之時,尤其需要保障數據庫遷移過程的平穩、流暢。

深信服推出的數據庫管理平臺(DMP)是為關系型數據庫量身打造的運維管理解決方案,它整合了數據庫日常運維所需的各項功能,包括但不限于數據庫的創建、實時監控、數據備份以及災難恢復等。此外,DMP 還配備了先進的數據庫遷移工具DTS,使企業能夠將數據庫從VMware平臺或物理服務器無縫遷移至深信服的云計算環境中,確保了遷移過程的高效率、安全性和可靠性。

深信服為滿足用戶不同場景下的遷移需求,提供豐富的MySQL數據庫遷移方案:

SCMT 信服云遷移工具 能夠實現針對常見單機數據庫的遷移,支持點對點模式、熱備模式等多種遷移方式,操作簡單,對業務影響小。

DTS 數據庫遷移工具 是深信服數據庫管理平臺DMP針對遷移場景開發的專用工具,支持主從同步遷移,通過配置MySQL的主從復制,將數據從主庫同步到從庫,然后進行角色切換。通常情況下采用全量+增量的遷移方式,但是當5.6 -> 8.0跨版本遷移時,由于會存在遷移后sql語法不兼容的情況,因此需要采用全量遷移的方式。

物理備份 / 邏輯備份遷移 ,面對DMP平臺無法滿足特定的遷移條件或要求時,深信服將協調專業的數據庫專家DBA來制定和執行定制化的物理備份/邏輯備份遷移方案。

本文重點介紹使用 DMP 的 DTS 工具對 MySQL 數據庫進行全量加增量的數據遷移方式,也是目前較為推薦的MySQL遷移方式。它利用mydumper/myloader邏輯備份恢復技術與MySQL主從復制原理,通過與數據庫內部組件的緊密協作,實現數據的高效遷移。

遷移支持版本:

MySQL 5.6 → MySQL 8.0 ? ? ? 全量遷移

MySQL 5.6-5.7 → MySQL 5.7 ? 全量+增量遷移

MySQL 5.7、8.0 → MySQL 8.0 ?全量+增量遷移

遷移架構支持:

MySQL 單機 → MySQL 單機

MySQL 主從 → MySQL 主從

MySQL 單機 → MySQL 主從

MySQL 主從 → MySQL 單機

一、 DTS? 遷移技術原理

本文重點介紹使用DMP的DTS工具對MySQL數據庫進行全量加增量的數據遷移方式,也是目前較為推薦的MySQL遷移方式,支持跨版本(5.6-5.7)、支持跨平臺遷移。

DMP的DTS支持mydumper + 主從復制方式遷移,mydumper是一個用于MySQL的開源熱備份工具,它可以在不鎖定表的情況下進行數據備份。使用mydumper和主從復制方式進行數據遷移的基本原理如下:

源、目標數據庫初始化數據并建立主從關系;

從庫會生成兩個線程,一個I/O線程,一個SQL線程;

I/O線程會去請求主庫的binlog,并將得到的binlog寫到本地的relay-log(中繼日志)文件中;

主庫會生成一個log dump線程,用來給從庫I/O線程傳輸binlog;

SQL線程,會讀取relay-log文件中的日志,并解析成sql語句逐一執行。

深信服DTS數據遷移工具,通過自動化和標準化的數據遷移策略,大幅度降低操作難度并提升遷移效率。該工具通過直觀的可視化界面,為用戶提供了一站式服務,包括目標數據庫的構建、遷移前的詳盡檢查、實時監控遷移過程以及高效切換控制。這種集成化的方法不僅簡化了數據庫的創建和性能優化,還確保了用戶能夠精確地掌握并優化整個遷移流程,以適應企業對數據庫遷移的復雜和多變需求。

二、 DTS? 遷移注意事項

增量遷移階段采用GTID模式的主從同步方式,在遷移前源端需開啟BINLOG,格式為ROW,且打開GTID,否則只能進行全量遷移,不能做“全量+增量”模式遷移。

由于mydumper工具不支持遷移觸發器trigger,如源端數據庫有觸發器且需要遷移到目標端數據庫,需在遷移完成后手動遷移觸發器trigger。

“全量遷移”類型任務,在全量備份階段,源端會出現元數據鎖,阻塞DDL語句,因此在此階段源庫無法執行DDL語句;同樣的,“全量+增量遷移”類型任務,在源庫導出階段期間,源庫也無法執行DDL語句。

MySQL 5.7到MySQL 8.0跨版本“全量+增量遷移”類型任務時,不支持源庫執行語句:grant all privileges on *.* to user@'%' identified by 'password';。

“全量+增量遷移”類型任務遷移過程中,無法同步源庫的創建用戶、修改用戶權限操作,所以在遷移過程中應避免增刪改用戶權限。

源端存在的空庫(database下無任何數據庫對象)不會被遷移。

三、 遷移過程及注意事項

( 一 ) 遷移時間評估

根據遷移的數據量和遷移過程中的操作,整個遷移過程時間分布如下:

主從復制遷移步驟概覽

( 二 ) 源庫信息收集

在遷移前需要了解源環境和目標環境的硬件差異,可以評估遷移的可行性和風險,包括CPU、內存、磁盤基礎設施的配置和利用率,基于硬件信息的收集,可以合理規劃遷移策略。

硬件信息收集示意

數據庫信息收集是確保遷移過程中數據一致性的關鍵。通過收集數據庫的版本、數據量和配置等信息,可以制定詳細的數據遷移計劃和驗證方案。在遷移過程中,可以通過比較源數據庫和目標數據庫的數據差異來及時發現并解決問題,確保數據的完整性和一致性。基于數據庫信息的收集,可以制定詳細的遷移計劃,包括遷移的時間窗口、備份和恢復策略、遷移驗證和回滾計劃等,減少遷移過程中的不確定性和風險,確保遷移的順利進行。

數據庫信息收集示意

( 三 ) 目標數據庫配置規劃

核心業務系統數據庫在遷移至深信服云計算平臺時,可能存在CPU和內存配置緊張,或資源過剩的情況,需要對原服務器進行配置變更評估。評估原則如下:

深信服平臺物理主頻建議要高于原服務器或者保持持平且不低于2.0GHhz,禁止云平臺的性能低于原操作系統的主頻。

合理的CPU和內存平均利用率在30%-70%之間,業務高峰時也應保持在80%以內,當原VMware平臺使用率超過70%時,考慮在深信服主機增加配置。

單實例數據庫服務器配置建議16C-32C,如果32C還不能滿足業務需求,建議優化數據庫,排查慢SQL語句;或更改數據庫架構為集群架構,不建議再通過增加服務器配置來承載業務。

集群數據庫服務器建議配置16C-32C,如果32C還不能滿足業務需求,建議優化數據庫,排查慢SQL語句;或為集群增加新的節點,以承載更多的業務訪問,不建議再通過增加服務器配置來承載業務。

數據庫內存在遷移上云時建議增加,不建議降低,隨意降低數據庫服務器內存可能會導致數據庫無法啟動。配置建議在16G-64G的區間,具體配置需要通過專業的DBA進行計算,遷移時不可隨意更改數據庫服務器內存配置。

源端數據庫的磁盤使用率不高于70%的情況下,遷移過來后可保持原狀。如果源端磁盤使用率高于70%,在擴容時需考慮到未來3-5年的業務增量進行測算。

單實例數據庫創建完成后只能修改數據盤/日志盤的大小,不能擴容數量。例如源數據庫配置了4塊1T磁盤,后面擴盤時只能擴大小,例如擴容到4塊2T磁盤。

集群數據庫服務,只能增加數據盤/日志盤的數量,不建議擴容大小。例如源數據庫配置了4塊1T磁盤,后面擴盤只能擴數量,例如擴容到8塊1T。

如果是P2V遷移的系統,磁盤大小配置和原物理的保持一致,數據文件和日志文件所在的磁盤為提高IO的吞吐,建議將磁盤進行預分配。

( 四 ) 切換與回退設計

在正式執行數據遷移之前,建議將源庫克隆出測試庫進行一次遷移測試。這一步驟至關重要,因為不同的物理環境可能會導致遷移所需的時間出現差異。通過測試遷移,不僅可以評估遷移過程中可能遇到的時間問題,而且可以驗證遷移方案的可行性和有效性。此外,遷移測試還有助于識別潛在的問題和風險,從而在正式遷移之前采取相應的預防措施。

數據庫切換前必須確認業務系統已完全停止對數據庫的訪問和寫入。在進行切換時,DMP允許用戶選擇是否在切換過程中自動關閉源數據庫。通常情況下,為了確保業務順利上線,我們會在業務系統上線前連接源數據庫進行數據驗證,此時無需自動關閉源數據庫。然而,如果無法確保源數據庫的數據寫入操作已完全停止,或者在切換過程中擔心源數據有變化,那么在進行切換時選擇自動關閉源數據庫將是一個更為穩妥的措施。

數據庫遷移完成后,應更新業務系統連接地址,以確保通過目標數據庫的服務IP進行訪問。在網絡環境中,如果存在訪問控制策略,應在遷移前調整策略,以避免影響業務訪問。如果是白名單模式,應允許最底層的全禁止策略;如果是黑名單模式,則應在最上層添加允許所有策略。待業務系統完全遷移后,再重新啟用相應的訪問控制策略。

在數據庫成功遷移并經過業務驗證之后,建議立即進行全面備份。這樣,在目標數據庫遇到無法迅速解決的問題時,可以迅速恢復到遷移后的狀態。同時,建議保留源數據庫的運行狀態(但不要關閉服務器),以便在新平臺出現問題時,能夠迅速切換回源數據庫繼續提供服務。

在數據庫遷移和切換過程中,必須確保源數據庫環境的完整性不受破壞。如果在切換過程中遇到異常,或者在業務驗證階段發現問題,應立即聯系深信服產品線專家和數據庫管理員(DBA)尋求支持。在允許的時間范圍內,應優先診斷問題,調整遷移參數或系統配置,以迅速恢復遷移流程。

在數據庫遷移過程中,如果遇到無法在停機窗口期內迅速解決的異常問題,應立即回退到源數據庫環境。在回退之前,需要分析失敗的原因,并根據分析結果重新制定遷移計劃。在決定回退時,要確保在遷移過程中沒有新的業務數據寫入到新數據庫,以避免在回退過程中丟失最新的業務數據。

如切換后發現業務有問題,不得不回切至源數據庫,可以利用割接后的增量日志,生成SQL文件,與用戶相關人員溝通后,可以在源端執行增量還原。

四、 遷移過程說明

( 一 ) 創建遷移任務

此處以全量+增量遷移任務,整庫遷移的方式為例,以下是具體的操作步驟:

使用DTS遷移工具新建遷移任務,遷移前請確保源庫已開啟binlog,并開啟GTID,GTID(Global Transaction ID,全局事務ID),用來強化數據庫的主備一致性、故障恢復,以及容錯能力。用于取代過去傳統的主從復制(即:基于binlog和position的復制)。若遷移任務為全量遷移情況,則無須開啟此參數。

( 二 ) 數據遷移過程

在確認源數據庫和目標數據庫的配置之后,接下來需要為數據庫遷移設置實例參數、遷移服務(DTS-VM,用于執行遷移任務的工具,包括數據導出與導入、日志抽取與重放等;不會占用遷移配額,遷移完成后將自動刪除該云主機并釋放對應的資源)配置。當啟動DTS工具執行遷移任務時,它將自動進行一系列預檢查,包括驗證源和目標數據庫之間的連通性、用戶權限、數據庫架構、數據庫版本兼容性、字符集、存儲引擎、系統信息、遷移數據量等。預檢查中發現的“不通過項”將直接影響遷移任務的執行,必須在遷移前解決;而“告警項”則通常不會妨礙遷移過程,可以在人工審核后選擇忽略,繼續執行遷移任務。

首先進行全量遷移過程,DTS會完成以下動作:源端數據庫全量導出、目標端數據庫全量恢復。全量遷移過程中對源庫業務不會產生影響,建議在業務低峰期執行,或者減少并發數并時刻觀察對生產業務產生的影響。所有DTS操作過程都會添加時間戳顯示在前端,運維人員可實時監控整個遷移過程。

在首次全量備份成功完成后,DTS系統將進入持續性的增量同步階段。增量同步的核心任務是實時進行主從同步。增量遷移過程中,DTS會完成以下動作:設置源&目標端主從關系,重置主庫、設置GTID、主從同步、檢查主從同步狀態。在此過程中,目標端會持續獲取源端binlog日志文件信息,并利用SQL Thread進行回放,從而實現增量同步。這種增量同步操作不會對源數據庫的業務運行造成任何影響。

根據深信服在用戶端的遷移實踐經驗,使用千兆遷移網絡時,全量數據遷移的理想速率為30MB/s,這使得每小時大約能夠遷移100GB的數據。然而,遷移速率受多種因素影響,包括源數據庫的數據結構、物理網絡條件以及帶寬限制。因此,實際遷移速度需要根據具體情況進行評估和調整。

( 三 ) 停庫切換過程

數據庫遷移切換過程需要停庫中斷業務,在確定了停機時間后,應向各業務部門發布維護通知,停止業務和應用對源數據庫的訪問,避免產生數據丟失等意外情況產生。同時需協調業務人員、運維人員、應用廠商、深信服廠商等多方工作人員協助保障遷移切換和業務驗證工作。

全量遷移任務待任務執行完成后,即數據庫遷移完畢,完成切換,業務可訪問新實例進行業務驗證;全量+增量遷移任務,需手動執行割接,割接完成后,業務訪問新實例進行業務驗證。

在數據庫切換流程完全執行完畢后,所有源端數據將被成功遷移至目標端數據庫。此時,可以對源端和目標端數據庫進行連接,以進行數據的檢查和校驗,確保數據庫狀態的一致性。完成數據校驗后,應協調業務團隊成員進行業務訪問測試。這一測試過程至關重要,它確保了從業務角度來看,系統能夠正常工作,滿足業務需求。

五、 附錄

( 一 ) 準備遷移用戶

建議使用數據庫全權限用戶如root@'%'(和root@'localhost'不是同一個用戶)進行遷移。如果源端不能使用全權限數據庫用戶執行遷移,需在源端創建遷移用戶。創建用戶及賦權語句如下:

注意: 遷移用戶的密碼中特殊字符僅支持:()`~!@#$^&*_-+=|{}[]:<>.?/。

MySQL5.6、5.7、8.0 全量遷移用戶權限

mysql> create user dtsuser@'%' identified with mysql_native_password by 'dtspassword';

mysql> grant select,event,show view,lock tables,reload on *.* to dtsuser@'%';

MySQL5.6、5.7、8.0 全量+增量遷移用戶權限

mysql> create user dtsuser@'%' identified with mysql_native_password by 'dtspassword';

mysql> grant select,event,show view,lock tables,replication slave,replication client,reload on *.* to dtsuser@'%';

( 二 ) 在線開 啟 GTID

GTID(Global Transaction ID,全局事務ID),用來強化數據庫的主備一致性、故障恢復,以及容錯能力。用于取代過去傳統的主從復制(即:基于binlog和position的復制)。

若遷移任務為全量+增量遷移情況,則必須開啟此參數。

以下操作主從均需要執行:

1. 開啟 GTID 預檢查

mysql> set @@global.enforce_gtid_consistency=WARN;

開啟此參數后,需觀察MySQL錯誤日志,若有違反GTID規則的事務會有告警,應及時調整。

設置告警后,部分操作會被告警,請注意調整業務或關閉GTID,例如:

( 1 ) ?執行 CREATE TABLE ... SELECT 語句:

(MySQL8.0.21以后對于支持原子DDL的存儲引擎,例如InnoDB引擎,支持該操作)

例如:

create table t1 select * from sbtest3;

查看錯誤日志:

2023-06-19T11:44:05.956128+08:00 82810 [Warning] Statement violates GTID consistency: CREATE TABLE ... SELECT.

修改:

create table t1 like sbtest3;

insert into t1 select * from sbtest3;

( 2 ) ?在事務中執行 CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE 語句:

例如:

begin;

select * from sbtest3 for update;

create temporary table t2(id int);

查看錯誤日志:

2023-06-19T11:52:42.254719+08:00 82810 [Warning] Statement violates GTID consistency: CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can only be executed outside transactional context. ?These statements are also not allowed in a function or trigger because functions and triggers are also considered to be multi-statement transactions.

修改:

避免在事務中執行創建或刪除臨時表。

2. 開啟 GTID 校驗

mysql> set @@global.enforce_gtid_consistency=ON;

這一步一旦執行,違反GTID的操作都會被拒絕,比如 create table as select,所以上一步WARN階段確保無違反GTID規則的事務。

3. 開啟 GTID_MODE

mysql> set @@global.gtid_mode=OFF_PERMISSIVE;

觀察ongoing_anonymous_transaction_count值:

mysql> show global status like '%ongoing_anonymous_transaction_count%';

確認已經沒有匿名的事物,建議多觀察一段時間,如果不為0,強行修改可能會導致數據丟失。

4.GTID_MODE 設置為 ON_PERMISSIVE

mysql> set @@global.gtid_mode=ON_PERMISSIVE;

5.GTID_MODE 設置為 ON

mysql> set @@global.gtid_mode=ON;

6. 從庫執行(若源端為單機,忽略此步驟)

mysql> stop slave;

mysql> change master to master_auto_position=1;

mysql> start slave;

mysql> show slave status\G

這一步,所有老的relay log都清理掉了,新relay log包含的全是GTID操作Event。

7. 修改配置文件(永久生效)

若未添加至配置文件,則數據庫重啟后參數失效,GTID關閉。

主從均執行

# vim /etc/my.cnf

在mysqld下添加以下內容

[mysqld]

gtid_mode=ON

enforce_gtid_consistency=ON

( 三 ) 修改 BINLOG_FORMAT

BINLOG_FORMAT 是 MySQL 中的一個參數,用于指定二進制日志文件的格式 。MySQL的復制方式與binlog(二進制日志文件)格式一一對應。

mysql 復制主要有三種方式 :

基于SQL語句的復制(statement-based replication, SBR);

基于行的復制(row-based replication, RBR);

混合模式復制(mixed-based replication, MBR)。

對應的,binlog的格式也有三種:STATEMENT,ROW,MIXED。

修改BINLOG_FORMAT的步驟如下:

1. 先在從庫執行、再去主庫執行

mysql> set global binlog_format=ROW;

2. 修改配置文件(主從都修改)

# vim /etc/my.cnf

在mysqld下添加以下內容

[mysqld]

binlog_format=ROW

( 四 ) 手動遷移觸發器 trigger

1. 檢查詢命令默認業務觸發器沒有創建在系統數據庫中,所以排除系統數據庫 sys、mysql、information_schema、performance_schema。

mysql> select TRIGGER_SCHEMA,count(*) as tiggers_cnt from information_schema.`TRIGGERS` where TRIGGER_SCHEMA not in ('sys','mysql','information_schema','performance_schema') group by TRIGGER_SCHEMA;

如上命令執行后有結果,如圖所示,源端業務數據庫sakila、test分別有6、1個觸發器,則需要遷移。

如上命令執行后查不到數據,則表示業務數據庫中無觸發器需要遷移。

2. 方法一:(推薦)

1.在目標端數據庫后臺執行如下命令導出源端觸發器。注意:在-B參數后面添加需要導出的業務數據庫(即上一章節查詢出來的TRIGGER_SCHEMA)的名字,如有多個使用空格分隔。

-h:源端數據庫ip地址,如“10.5.54.66”。

-P:源端數據庫端口號,如“3306”。

-u:源端數據庫遷移賬號,如“root”

-p:源端數據庫遷移賬號密碼,如“Admin-123”。

# mysqldump -h10.5.54.66 -P3306 -uroot -pAdmin-123 --single-transaction --set-gtid-purged=OFF --default-character-set=utf8mb4 --add-drop-trigger --no-create-db=true --no-create-info=true --no-data=true -B sakila test > ./tri.sql

注意: 導出源端觸發器用戶需要有“trigger”權限。

(2)導入到目標端數據庫。

# mysql -uroot -pQwer@123 -S/run/sock/mysql.sock < ./tri.sql

(3)檢查觸發器是否遷移成功

在目標端執行命令查詢,參考“Part.5 附錄中第4節 手動遷移觸發器trigger的檢查源端是否存在觸發器”。

3. 方法二

1.在目標端用root用戶登錄RDS主節點,訪問源端數據庫導出業務數據庫觸發器DDL語句。

# cd

# rm -rf trigdump.sql

# touch trigdump.sql

# mysql -h10.5.54.66 -P3306 -uroot -pAdmin-123 <<'EOF'

tee trigdump.sql

SELECT

CONCAT("DROP TRIGGER IF EXISTS `",

TRIGGER_SCHEMA,

"`.`",

TRIGGER_NAME,

"`;\nDELIMITER ;;\nCREATE TRIGGER `",

TRIGGER_SCHEMA,

"`.`",

TRIGGER_NAME,

"` ",

ACTION_TIMING,

" ",

EVENT_MANIPULATION,

" ON `",

EVENT_OBJECT_SCHEMA,

"`.`",

EVENT_OBJECT_TABLE,

"` FOR EACH ROW\n",

ACTION_STATEMENT,

";;\nDELIMITER ;") AS TRIG

FROM

information_schema.TRIGGERS

WHERE

TRIGGER_SCHEMA IN ('sakila','test')\G

notee

exit

EOF

# sed -i '/^*/d' trigdump.sql

# sed -i 's/TRIG: //' trigdump.sql

# echo "COMMIT;" >> trigdump.sql

(2)導入觸發器至目標端主節點

# mysql -uroot -p -S/run/sock/mysql.sock < trigdump.sql

(3)檢查觸發器是否遷移成功

在目標端執行命令查詢,參考“Part.5 附錄中第4節 手動遷移觸發器trigger的檢查源端是否存在觸發器”。