MySQL 大數(shù)據(jù)量時(shí)如何部署MySQL Replication從庫(kù)

我們?cè)诓渴餗ySQL Replication從庫(kù)時(shí)，通常是一開(kāi)始就做好一個(gè)從庫(kù)，然后隨著業(yè)務(wù)的變化，數(shù)據(jù)也逐漸復(fù)制到從服務(wù)器。

但是，如果我們想對(duì)一個(gè)已經(jīng)上線較久，有這大數(shù)據(jù)量的數(shù)據(jù)庫(kù)部署復(fù)制從庫(kù)時(shí)，應(yīng)該怎么處理比較合適呢？

本文以我近期所做Zabbix數(shù)據(jù)庫(kù)部署MySQL Replication從庫(kù)為例，向大家呈現(xiàn)一種新的復(fù)制部署方式。由于Zabbix歷史數(shù)據(jù)非常多，在轉(zhuǎn)TokuDB之前的InnoDB引擎時(shí)，已經(jīng)接近700G，轉(zhuǎn)成TokuDB后，還有300多G，而且主要集中在trends_uint、history_uint等幾個(gè)大表上。做一次全量備份后再恢復(fù)耗時(shí)太久，怕對(duì)主庫(kù)寫(xiě)入影響太大，因此才有了本文的分享。

我大概分為幾個(gè)步驟來(lái)做Zabbix數(shù)據(jù)遷移的：

1、初始化一個(gè)空的Zabbix庫(kù)

2、啟動(dòng)復(fù)制，但設(shè)置忽略幾個(gè)常見(jiàn)錯(cuò)誤（這幾個(gè)錯(cuò)誤代碼對(duì)應(yīng)具體含義請(qǐng)自行查詢手冊(cè)）
#忽略不重要的錯(cuò)誤，極端情況下，甚至可以直接忽略全部錯(cuò)誤，例如
#slave-skip-errors=all
slave-skip-errors=1032,1053,1062

3、將大多數(shù)小表正常備份導(dǎo)出，在SLAVE服務(wù)器上導(dǎo)入恢復(fù)。在這里，正常導(dǎo)出即可，無(wú)需特別指定 --master-data 選項(xiàng)

4、逐一導(dǎo)出備份剩下的幾個(gè)大表。在備份大表時(shí)，還可以分批次并發(fā)導(dǎo)出，方便并發(fā)導(dǎo)入，使用mysqldump的"-w"參數(shù)，然后在SLAVE上導(dǎo)入恢復(fù)（可以打開(kāi)后面的參考文章鏈接）

5、全部導(dǎo)入完成后，等待復(fù)制沒(méi)有延遲了，關(guān)閉忽略錯(cuò)誤選項(xiàng)，重啟，正式對(duì)外提供服務(wù)

上述幾個(gè)步驟完成后，可能還有個(gè)別不一致的數(shù)據(jù)，不過(guò)會(huì)在后期逐漸被覆蓋掉，或者被當(dāng)做過(guò)期歷史數(shù)據(jù)刪除掉。

本案例的步驟并不適用于全部場(chǎng)景，主要適用于：

不要求數(shù)據(jù)高一致性，且數(shù)據(jù)量相對(duì)較大，尤其是單表較大的情況，就像本次的Zabbix數(shù)據(jù)一樣。

參考文章：

遷移Zabbix數(shù)據(jù)庫(kù)到TokuDB

[MySQL FAQ]系列— mysqldump加-w參數(shù)備份