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

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

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

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

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

1、初始化一個空的Zabbix庫

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

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

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

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

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

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

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

參考文章：

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

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