[MySQL FAQ]系列 — 大資料量時如何部署MySQL Replication從庫

我們在部署MySQL Replication從庫時，通常是一開始就做好一個從庫，然後随着業務的變化，資料也逐漸複制到從伺服器。

但是，如果我們想對一個已經上線較久，有這大資料量的資料庫部署複制從庫時，應該怎麼處理比較合适呢？

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

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

1、初始化一個空的Zabbix庫

2、啟動複制，但設定忽略幾個常見錯誤（這幾個錯誤代碼對應具體含義請自行查詢手冊）

#忽略不重要的錯誤，極端情況下，甚至可以直接忽略全部錯誤，例如

#slave-skip-errors=all

slave-skip-errors=1032,1053,1062

3、将大多數小表正常備份導出，在SLAVE伺服器上導入恢複。在這裡，正常導出即可，無需特别指定 --master-data 選項

4、逐一導出備份剩下的幾個大表。在備份大表時，還可以分批次并發導出，友善并發導入，使用mysqldump的"-w"參數，然後在SLAVE上導入恢複（可以打開後面的參考文章連結）

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

上述幾個步驟完成後，可能還有個别不一緻的資料，不過會在後期逐漸被覆寫掉，或者被當做過期曆史資料删除掉。

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

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