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

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

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

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

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

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

本文重點(diǎn)介紹使用 DMP 的 DTS 工具對(duì) MySQL 數(shù)據(jù)庫(kù)進(jìn)行全量加增量的數(shù)據(jù)遷移方式,也是目前較為推薦的MySQL遷移方式。它利用mydumper/myloader邏輯備份恢復(fù)技術(shù)與MySQL主從復(fù)制原理,通過(guò)與數(shù)據(jù)庫(kù)內(nèi)部組件的緊密協(xié)作,實(shí)現(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 單機(jī) → MySQL 單機(jī)

MySQL 主從 → MySQL 主從

MySQL 單機(jī) → MySQL 主從

MySQL 主從 → MySQL 單機(jī)

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

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

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

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

從庫(kù)會(huì)生成兩個(gè)線程,一個(gè)I/O線程,一個(gè)SQL線程;

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

主庫(kù)會(huì)生成一個(gè)log dump線程,用來(lái)給從庫(kù)I/O線程傳輸binlog;

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

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

二、DTS 遷移注意事項(xiàng)

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

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

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

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

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

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

三、遷移過(guò)程及注意事項(xiàng)

(一)遷移時(shí)間評(píng)估

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

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

(二)源庫(kù)信息收集

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

硬件信息收集示意

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

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

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

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

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

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

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

集群數(shù)據(jù)庫(kù)服務(wù)器建議配置16C-32C,如果32C還不能滿足業(yè)務(wù)需求,建議優(yōu)化數(shù)據(jù)庫(kù),排查慢SQL語(yǔ)句;或?yàn)榧涸黾有碌墓?jié)點(diǎn),以承載更多的業(yè)務(wù)訪問(wèn),不建議再通過(guò)增加服務(wù)器配置來(lái)承載業(yè)務(wù)。

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

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

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

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

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

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

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

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

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

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

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

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

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

四、遷移過(guò)程說(shuō)明

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

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

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

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

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

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

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

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

(三)停庫(kù)切換過(guò)程

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

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

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

五、附錄

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

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

注意:遷移用戶的密碼中特殊字符僅支持:`~!@ vim /etc/my.cnf

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

[mysqld]

gtid_mode=ON

enforce_gtid_consistency=ON

(三)修改BINLOG_FORMAT

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

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

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

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

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

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

修改BINLOG_FORMAT的步驟如下:

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

mysql> set global binlog_format=ROW;

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

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ù)庫(kù)。

cd

touch trigdump.sql

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

echo "COMMIT;" >> trigdump.sql

(2)導(dǎo)入觸發(fā)器至目標(biāo)端主節(jié)點(diǎn)

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

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

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