下面講講關(guān)于MySQL5.6如何實(shí)現(xiàn)數(shù)據(jù)庫之間的相互遷移，文字的奧妙在于貼近主題相關(guān)。所以，閑話就不談了，我們直接看下文吧，相信看完MySQL5.6如何實(shí)現(xiàn)數(shù)據(jù)庫之間的相互遷移這篇文章你一定會(huì)有所受益。

創(chuàng)新互聯(lián)長期為千余家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為維西企業(yè)提供專業(yè)的成都網(wǎng)站建設(shè)、成都做網(wǎng)站，維西網(wǎng)站改版等技術(shù)服務(wù)。擁有10多年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。

###業(yè)務(wù)描述

1. 公司內(nèi)部一個(gè)MySQL的master-slave架構(gòu)上面跑有公司倆個(gè)項(xiàng)目的庫
2. 倆個(gè)項(xiàng)目的有存在共用的table的情況
3. 倆個(gè)項(xiàng)目都可以對共用的table進(jìn)行讀寫操作
4. 項(xiàng)目A的一個(gè)子業(yè)務(wù)在每天固定的時(shí)間段內(nèi)都會(huì)有高并發(fā)的寫操作,造成的后果就是在這個(gè)子業(yè)務(wù)工作的時(shí)間段內(nèi),倆個(gè)項(xiàng)目的讀寫操作會(huì)變得非常的慢,并且對外表現(xiàn)就是應(yīng)用會(huì)很卡
5. 項(xiàng)目A的子業(yè)務(wù)使用的庫a是獨(dú)立的,和另外一個(gè)項(xiàng)目已經(jīng)項(xiàng)目A下面的子業(yè)務(wù)并不存在關(guān)聯(lián)關(guān)系,是這個(gè)子業(yè)務(wù)獨(dú)立使用的

###需求:

1. 將庫a獨(dú)立剝離出來
2. 將業(yè)務(wù)A的關(guān)聯(lián)的數(shù)據(jù)庫剝離出來
3. 倆個(gè)共用的業(yè)務(wù)的table暫時(shí)還沒有方案

###方案:

1. 新建一套master-slave的主從環(huán)境使用5.6的最新版本
2. 搭建級聯(lián)環(huán)境
   • old master -> old slave -> new master -> old master
3. xtrabackup物理備份
4. pt-table-checksum 數(shù)據(jù)一致性校驗(yàn)
5. 項(xiàng)目A的子業(yè)務(wù)可以停掉一段時(shí)間,因?yàn)槭请A段性的應(yīng)用
6. 應(yīng)用停掉的一段時(shí)間內(nèi),等待獨(dú)立的database沒有寫入.針對庫級別上面的表不做鎖操作
7. 應(yīng)用停掉一段時(shí)間之后直接修改子業(yè)務(wù)的MySQL的配置信息,將新的數(shù)據(jù)寫入new master
8. 級聯(lián)組織的架構(gòu)不做任何的修改,只是在業(yè)務(wù)層次做寫入的改動(dòng),這樣子造成的后果就是老的master-slave和新的master-slave針對這個(gè)獨(dú)立的database的數(shù)據(jù)是不一致的。
9. 在這里需要考慮的問題是舊的master-slave上面會(huì)不會(huì)因?yàn)椴糠謽I(yè)務(wù)忘記修改或者其他的原因,未完全將業(yè)務(wù)的讀寫遷移到新的master-slave架構(gòu)上面,這樣會(huì)造成數(shù)據(jù)的不一致,并且在databases中萬一存在自增的建的話,可能會(huì)有建值沖突的情況。
10. 在完成業(yè)務(wù)MySQL的配置更改之后,四層的級聯(lián)架構(gòu)保持原樣的目的是為了后續(xù)還需要繼續(xù)做業(yè)務(wù)剝離。

###環(huán)境:

1. os system CentOS 6.9
2. MySQL 5.6.38 最新版本

###步驟：

1. 備份：

   • 使用xtrabackup 2.4.4版本在old slave 上面進(jìn)行物理備份,不在old master上面?zhèn)浞莸闹饕蛟谟跒榱吮苊鈧浞莸臅r(shí)候消耗系統(tǒng)資源和數(shù)據(jù)庫資源影響線上業(yè)務(wù)的正常使用,因?yàn)槲覀兙€上的業(yè)務(wù)所有的讀寫都是在主庫上面,并沒有做讀寫分離.所以針對于old slave的操作對于業(yè)務(wù)的影響幾乎可以忽略.
   • 在備份的時(shí)候需要考慮一個(gè)因素就是你的備份所放置云服務(wù)器的磁盤空間是否足夠,我第一次備份的時(shí)候并沒有使用流備份,就直接備份到本地,在備份傳輸?shù)臅r(shí)候網(wǎng)絡(luò)IO和磁盤IO這塊需要花費(fèi)更多的時(shí)間。

   • 沒有使用流備份:備份77G,花費(fèi)9分鐘
     innobackupex --host=127.0.0.1 --user=root --password=xxxxx --port=3306  /path/BACKUP_DIR/

   • 使用流備份進(jìn)行壓縮備份:備份12G,花費(fèi)40分鐘
     innobackupex --host=127.0.0.1 --port=3306 --user=root --password=xxxxx --stream=tar /tmpdir  | gzip > /path/BACKUP_DIR/back_file.tar.gz

   • 因?yàn)槭亲?層的級聯(lián)復(fù)制,所以只需要備份old slave上面的binlog的file_name和file_position這倆個(gè)信息,根據(jù)這倆個(gè)信息change master創(chuàng)建主從復(fù)制.不過其中需要注意的文件有:
     • xtrabackup_binlog_info：這個(gè)文件里面記錄是在xtrabackup備份完非innodb數(shù)據(jù)之后,執(zhí)行show master status獲取得到的信息,做主傳統(tǒng)主從復(fù)制的信息來自與這里.
     • xtrabackup_info：這個(gè)文件里面記錄了備份完全,釋放MySQL資源之后記錄一些具體的詳細(xì)信息,在這里也存在備份的binlog的信息,這個(gè)信息的主要來源是從redo log里面獲取得到的,當(dāng)這個(gè)信息和上面那個(gè)文件信息不一致的時(shí)候,主要是以這個(gè)文件為主,主要原因在與redo log里面記錄的binlog信息打上commit標(biāo)簽之后就表明事務(wù)是已經(jīng)完成了的。
   • 需要注意的參數(shù)有:
     • --slave-info：在從庫上面執(zhí)行備份,獲取主庫上面的二進(jìn)制日志信息,并且會(huì)生成xtrabackup_slave_info文件記錄這些信息
     • --safe-slave-backup：和slave-info結(jié)合使用,主要是在發(fā)起備份的時(shí)候會(huì)暫停slave的sql_thread進(jìn)程確保備份的時(shí)候沒有臨時(shí)表打開,保證數(shù)據(jù)的一致性
     • --safe-slave-backup-timeout=SECONDS：指定safe-slave-backup應(yīng)該等待多長時(shí)間

2. 恢復(fù)：在新的master-slave上面?zhèn)浞輸?shù)據(jù)達(dá)到一致的狀態(tài),其目的是為了應(yīng)用redo log:

   innobackupex --defaults-file=/etc/my.cnf --apply-log /path/BACKUP_DIR

   將數(shù)據(jù)恢復(fù)到datadir目錄下面:

   innobackupex --defaults-file=/etc/my.cnf --copy-back /path/BACKUP_DIR

   修改datadir的數(shù)據(jù)權(quán)限

   chown mysql.mysql /datadir -R

3. 搭建new master-slave：在搭建old slave -> new master架構(gòu)之前先搭建new master-slave 架構(gòu)
   • 需要注意的是,在搭建之前需要注意事項(xiàng)有:
     • GTID是否開啟,因?yàn)?old master-slave 是基于傳統(tǒng)復(fù)制,所以new的master-slave不能開啟GTID復(fù)制
     • server-id不能一致
     • binlog的日志格式,四個(gè)必須保持一致
     • 在配置文件my.cnf 添加參數(shù) “replicate-ingore-db=mysql.* ” 的目的是為了不復(fù)制系統(tǒng)庫mysql的信息,目的是因?yàn)楹罄m(xù)的用戶權(quán)限管理;并且5.6并不支持在線修改這些復(fù)制過濾,只能在配置文件里面修改之后重啟數(shù)據(jù)庫。
   • 在new master-slave備份恢復(fù)之后,直接可以在new master上面show master status獲取binlog信息,根據(jù)這些信息做主從同步.
4. old slave -> new master 搭建主從：從第一步備份獲取得到slave的info信息搭建主從
5. 監(jiān)測主從是否搭建成功,在old slave -> new master -> new slave 執(zhí)行show slave status信息觀察

6. pt-table-checksum檢測數(shù)據(jù)的一致性

   • 命令：
     pt-table-checksum --replicate=percona.checksumss --nocheck-replication-filters --no-check-binlog-format h=x.x.x.x,u=rpl,p='xxxxx',P=3306 --databases-regex=database.* --recursion-method dsn=h=x.x.x.x,u=root,p='xxxxx',P=3306,D=zst_teach,t=dsns

   • 注意：
     • 命令第一個(gè)鏈接的主機(jī)是需要監(jiān)測的master-slave中master實(shí)例信息
     • 命令中的dsn后續(xù)的鏈接信息是dsn存在信息的MySQL實(shí)例,這個(gè)dsn信息可以存放在master,也可以存放到第三方實(shí)例,這個(gè)時(shí)候pt-table-checksum執(zhí)行所在的云服務(wù)器需要有root用戶訪問zst_teach.dsns表信息的權(quán)限,即select的權(quán)限
     • 命令在執(zhí)行的時(shí)候會(huì)在master上面產(chǎn)生percona.checksumss信息,其中percona庫是不會(huì)手動(dòng)生成的,需要自己手動(dòng)生成,但是checksums會(huì)自動(dòng)生成,但是其中需要注意的是,由于是在master上面生成percona.checksumss信息表,所以rpl@command_host用戶需要有percona.checksums的select,insert,update,delete,super,process,lock tables,craete的權(quán)限,而且還必須有針對所有表的select,lock tables,super,process權(quán)限。
     • 并且為了在slave進(jìn)行檢測,檢測的用戶也必須要有所以表的select,super,lock tables,process的權(quán)限
     • master:
       grant update,delete,insert,super,process,lock tables,create on *.* 'user'@'command_host'
   • slave:
     grant select,process,lock tabes,super on *.* to 'user'@'master_host';

7.pt-table-sync數(shù)據(jù)同步(在master和slave都可以執(zhí)行)

• pt-table-sync --print  --sync-to-master h=slave_host,P=3306,u=repl,p='xxxxx' --database=DB_name --tables=table_name1,table_name2

  --print 打印出在slave執(zhí)行的SQL
  --sync-to-master 指定slave的IP地址,從show slave status獲取master的信息

• 對于以上MySQL5.6如何實(shí)現(xiàn)數(shù)據(jù)庫之間的相互遷移相關(guān)內(nèi)容，大家還有什么不明白的地方嗎？或者想要了解更多相關(guān)，可以繼續(xù)關(guān)注我們的行業(yè)資訊板塊。