數(shù)據(jù)庫作為數(shù)字化用戶的核心資產(chǎn),其遷移是一項復(fù)雜且重要的任務(wù),特別是在VMware平臺替換及IT基礎(chǔ)設(shè)施更新?lián)Q代之時,尤其需要保障數(shù)據(jù)庫遷移過程的平穩(wěn)、流暢。

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

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

SCMT 信服云遷移工具 能夠?qū)崿F(xiàn)針對常見單機數(shù)據(jù)庫的遷移,支持點對點模式、熱備模式等多種遷移方式,操作簡單,對業(yè)務(wù)影響小。

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

物理備份 / 邏輯備份遷移 ,面對DMP平臺無法滿足特定的遷移條件或要求時,深信服將協(xié)調(diào)專業(yè)的數(shù)據(jù)庫專家DBA來制定和執(zhí)行定制化的物理備份/邏輯備份遷移方案。

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

遷移支持版本:

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

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

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

遷移架構(gòu)支持:

MySQL 單機 → MySQL 單機

MySQL 主從 → MySQL 主從

MySQL 單機 → MySQL 主從

MySQL 主從 → MySQL 單機

一、 DTS? 遷移技術(shù)原理

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

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

源、目標(biāo)數(shù)據(jù)庫初始化數(shù)據(jù)并建立主從關(guān)系;

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

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

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

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

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

二、 DTS? 遷移注意事項

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

由于mydumper工具不支持遷移觸發(fā)器trigger,如源端數(shù)據(jù)庫有觸發(fā)器且需要遷移到目標(biāo)端數(shù)據(jù)庫,需在遷移完成后手動遷移觸發(fā)器trigger。

“全量遷移”類型任務(wù),在全量備份階段,源端會出現(xiàn)元數(shù)據(jù)鎖,阻塞DDL語句,因此在此階段源庫無法執(zhí)行DDL語句;同樣的,“全量+增量遷移”類型任務(wù),在源庫導(dǎo)出階段期間,源庫也無法執(zhí)行DDL語句。

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

“全量+增量遷移”類型任務(wù)遷移過程中,無法同步源庫的創(chuàng)建用戶、修改用戶權(quán)限操作,所以在遷移過程中應(yīng)避免增刪改用戶權(quán)限。

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

三、 遷移過程及注意事項

( 一 ) 遷移時間評估

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

主從復(fù)制遷移步驟概覽

( 二 ) 源庫信息收集

在遷移前需要了解源環(huán)境和目標(biāo)環(huán)境的硬件差異,可以評估遷移的可行性和風(fēng)險,包括CPU、內(nèi)存、磁盤基礎(chǔ)設(shè)施的配置和利用率,基于硬件信息的收集,可以合理規(guī)劃遷移策略。

硬件信息收集示意

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

數(shù)據(jù)庫信息收集示意

( 三 ) 目標(biāo)數(shù)據(jù)庫配置規(guī)劃

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

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

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

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

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

數(shù)據(jù)庫內(nèi)存在遷移上云時建議增加,不建議降低,隨意降低數(shù)據(jù)庫服務(wù)器內(nèi)存可能會導(dǎo)致數(shù)據(jù)庫無法啟動。配置建議在16G-64G的區(qū)間,具體配置需要通過專業(yè)的DBA進(jìn)行計算,遷移時不可隨意更改數(shù)據(jù)庫服務(wù)器內(nèi)存配置。

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

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

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

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

( 四 ) 切換與回退設(shè)計

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

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

數(shù)據(jù)庫遷移完成后,應(yīng)更新業(yè)務(wù)系統(tǒng)連接地址,以確保通過目標(biāo)數(shù)據(jù)庫的服務(wù)IP進(jìn)行訪問。在網(wǎng)絡(luò)環(huán)境中,如果存在訪問控制策略,應(yīng)在遷移前調(diào)整策略,以避免影響業(yè)務(wù)訪問。如果是白名單模式,應(yīng)允許最底層的全禁止策略;如果是黑名單模式,則應(yīng)在最上層添加允許所有策略。待業(yè)務(wù)系統(tǒng)完全遷移后,再重新啟用相應(yīng)的訪問控制策略。

在數(shù)據(jù)庫成功遷移并經(jīng)過業(yè)務(wù)驗證之后,建議立即進(jìn)行全面?zhèn)浞荨＿@樣,在目標(biāo)數(shù)據(jù)庫遇到無法迅速解決的問題時,可以迅速恢復(fù)到遷移后的狀態(tài)。同時,建議保留源數(shù)據(jù)庫的運行狀態(tài)(但不要關(guān)閉服務(wù)器),以便在新平臺出現(xiàn)問題時,能夠迅速切換回源數(shù)據(jù)庫繼續(xù)提供服務(wù)。

在數(shù)據(jù)庫遷移和切換過程中,必須確保源數(shù)據(jù)庫環(huán)境的完整性不受破壞。如果在切換過程中遇到異常,或者在業(yè)務(wù)驗證階段發(fā)現(xiàn)問題,應(yīng)立即聯(lián)系深信服產(chǎn)品線專家和數(shù)據(jù)庫管理員(DBA)尋求支持。在允許的時間范圍內(nèi),應(yīng)優(yōu)先診斷問題,調(diào)整遷移參數(shù)或系統(tǒng)配置,以迅速恢復(fù)遷移流程。

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

如切換后發(fā)現(xiàn)業(yè)務(wù)有問題,不得不回切至源數(shù)據(jù)庫,可以利用割接后的增量日志,生成SQL文件,與用戶相關(guān)人員溝通后,可以在源端執(zhí)行增量還原。

四、 遷移過程說明

( 一 ) 創(chuàng)建遷移任務(wù)

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

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

( 二 ) 數(shù)據(jù)遷移過程

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

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

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

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

( 三 ) 停庫切換過程

數(shù)據(jù)庫遷移切換過程需要停庫中斷業(yè)務(wù),在確定了停機時間后,應(yīng)向各業(yè)務(wù)部門發(fā)布維護(hù)通知,停止業(yè)務(wù)和應(yīng)用對源數(shù)據(jù)庫的訪問,避免產(chǎn)生數(shù)據(jù)丟失等意外情況產(chǎn)生。同時需協(xié)調(diào)業(yè)務(wù)人員、運維人員、應(yīng)用廠商、深信服廠商等多方工作人員協(xié)助保障遷移切換和業(yè)務(wù)驗證工作。

全量遷移任務(wù)待任務(wù)執(zhí)行完成后,即數(shù)據(jù)庫遷移完畢,完成切換,業(yè)務(wù)可訪問新實例進(jìn)行業(yè)務(wù)驗證;全量+增量遷移任務(wù),需手動執(zhí)行割接,割接完成后,業(yè)務(wù)訪問新實例進(jìn)行業(yè)務(wù)驗證。

在數(shù)據(jù)庫切換流程完全執(zhí)行完畢后,所有源端數(shù)據(jù)將被成功遷移至目標(biāo)端數(shù)據(jù)庫。此時,可以對源端和目標(biāo)端數(shù)據(jù)庫進(jìn)行連接,以進(jìn)行數(shù)據(jù)的檢查和校驗,確保數(shù)據(jù)庫狀態(tài)的一致性。完成數(shù)據(jù)校驗后,應(yīng)協(xié)調(diào)業(yè)務(wù)團(tuán)隊成員進(jìn)行業(yè)務(wù)訪問測試。這一測試過程至關(guān)重要,它確保了從業(yè)務(wù)角度來看,系統(tǒng)能夠正常工作,滿足業(yè)務(wù)需求。

五、 附錄

( 一 ) 準(zhǔn)備遷移用戶

建議使用數(shù)據(jù)庫全權(quán)限用戶如root@'%'(和root@'localhost'不是同一個用戶)進(jìn)行遷移。如果源端不能使用全權(quán)限數(shù)據(jù)庫用戶執(zhí)行遷移,需在源端創(chuàng)建遷移用戶。創(chuàng)建用戶及賦權(quán)語句如下:

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

MySQL5.6、5.7、8.0 全量遷移用戶權(quán)限

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 全量+增量遷移用戶權(quán)限

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,全局事務(wù)ID),用來強化數(shù)據(jù)庫的主備一致性、故障恢復(fù),以及容錯能力。用于取代過去傳統(tǒng)的主從復(fù)制(即:基于binlog和position的復(fù)制)。

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

以下操作主從均需要執(zhí)行:

1. 開啟 GTID 預(yù)檢查

mysql> set @@global.enforce_gtid_consistency=WARN;

開啟此參數(shù)后,需觀察MySQL錯誤日志,若有違反GTID規(guī)則的事務(wù)會有告警,應(yīng)及時調(diào)整。

設(shè)置告警后,部分操作會被告警,請注意調(diào)整業(yè)務(wù)或關(guān)閉GTID,例如:

( 1 ) ?執(zhí)行 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 ) ?在事務(wù)中執(zhí)行 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.

修改:

避免在事務(wù)中執(zhí)行創(chuàng)建或刪除臨時表。

2. 開啟 GTID 校驗

mysql> set @@global.enforce_gtid_consistency=ON;

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

3. 開啟 GTID_MODE

mysql> set @@global.gtid_mode=OFF_PERMISSIVE;

觀察ongoing_anonymous_transaction_count值:

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

確認(rèn)已經(jīng)沒有匿名的事物,建議多觀察一段時間,如果不為0,強行修改可能會導(dǎo)致數(shù)據(jù)丟失。

4.GTID_MODE 設(shè)置為 ON_PERMISSIVE

mysql> set @@global.gtid_mode=ON_PERMISSIVE;

5.GTID_MODE 設(shè)置為 ON

mysql> set @@global.gtid_mode=ON;

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

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. 修改配置文件(永久生效)

若未添加至配置文件,則數(shù)據(jù)庫重啟后參數(shù)失效,GTID關(guān)閉。

主從均執(zhí)行

# vim /etc/my.cnf

在mysqld下添加以下內(nèi)容

[mysqld]

gtid_mode=ON

enforce_gtid_consistency=ON

( 三 ) 修改 BINLOG_FORMAT

BINLOG_FORMAT 是 MySQL 中的一個參數(shù),用于指定二進(jìn)制日志文件的格式 。MySQL的復(fù)制方式與binlog(二進(jìn)制日志文件)格式一一對應(yīng)。

mysql 復(fù)制主要有三種方式 :

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

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

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

對應(yīng)的,binlog的格式也有三種:STATEMENT,ROW,MIXED。

修改BINLOG_FORMAT的步驟如下:

1. 先在從庫執(zhí)行、再去主庫執(zhí)行

mysql> set global binlog_format=ROW;

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

# vim /etc/my.cnf

在mysqld下添加以下內(nèi)容

[mysqld]

binlog_format=ROW

( 四 ) 手動遷移觸發(fā)器 trigger

1. 檢查詢命令默認(rèn)業(yè)務(wù)觸發(fā)器沒有創(chuàng)建在系統(tǒng)數(shù)據(jù)庫中,所以排除系統(tǒng)數(shù)據(jù)庫 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;

如上命令執(zhí)行后有結(jié)果,如圖所示,源端業(yè)務(wù)數(shù)據(jù)庫sakila、test分別有6、1個觸發(fā)器,則需要遷移。

如上命令執(zhí)行后查不到數(shù)據(jù),則表示業(yè)務(wù)數(shù)據(jù)庫中無觸發(fā)器需要遷移。

2. 方法一:(推薦)

1.在目標(biāo)端數(shù)據(jù)庫后臺執(zhí)行如下命令導(dǎo)出源端觸發(fā)器。注意:在-B參數(shù)后面添加需要導(dǎo)出的業(yè)務(wù)數(shù)據(jù)庫(即上一章節(jié)查詢出來的TRIGGER_SCHEMA)的名字,如有多個使用空格分隔。

-h:源端數(shù)據(jù)庫ip地址,如“10.5.54.66”。

-P:源端數(shù)據(jù)庫端口號,如“3306”。

-u:源端數(shù)據(jù)庫遷移賬號,如“root”

-p:源端數(shù)據(jù)庫遷移賬號密碼,如“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

注意: 導(dǎo)出源端觸發(fā)器用戶需要有“trigger”權(quán)限。

(2)導(dǎo)入到目標(biāo)端數(shù)據(jù)庫。

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

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

在目標(biāo)端執(zhí)行命令查詢,參考“Part.5 附錄中第4節(jié) 手動遷移觸發(fā)器trigger的檢查源端是否存在觸發(fā)器”。

3. 方法二

1.在目標(biāo)端用root用戶登錄RDS主節(jié)點,訪問源端數(shù)據(jù)庫導(dǎo)出業(yè)務(wù)數(shù)據(jù)庫觸發(fā)器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)導(dǎo)入觸發(fā)器至目標(biāo)端主節(jié)點

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

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

在目標(biāo)端執(zhí)行命令查詢,參考“Part.5 附錄中第4節(jié) 手動遷移觸發(fā)器trigger的檢查源端是否存在觸發(fā)器”。