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

我們在部署MySQL Replication從庫時(shí)，通常是一開始就做好一個(gè)從庫，然后隨著業(yè)務(wù)的變化，數(shù)據(jù)也逐漸復(fù)制到從服務(wù)器。

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

本文以我近期所做Zabbix數(shù)據(jù)庫部署MySQL Replication從庫為例，向大家呈現(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í)太久，怕對主庫寫入影響太大，因此才有了本文的分享。

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

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

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

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

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

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

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

本案例的步驟并不適用于全部場景，主要適用于：

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

參考文章：

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

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