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

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

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

我大概分為幾個步驟來做Zabbix數據遷移的：

1、初始化一個空的Zabbix庫

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

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

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

5、全部導入完成后，等待復制沒有延遲了，關閉忽略錯誤選項，重啟，正式對外提供服務

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

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

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

參考文章：

遷移Zabbix數據庫到TokuDB

[MySQL FAQ]系列— mysqldump加-w參數備份