我們在部署MySQL Replication從庫時，通常是一開始就做好一個從庫，然后隨著業務的變化，數據也逐漸復制到從服務器。 但是，如果我們想對一個已經上線較久，有這大數據量的數據庫部署復制從庫時，應該怎么處理比較合適呢？ 本文以我近期所做Zabbix數據庫部署MySQL Replication從庫為例，向大家呈現一種新的復制部署方式。由于Zabbix歷史數據非常多，[在轉TokuDB之前的InnoDB引擎時](http://imysql.com/2014/06/24/migrate-zabbix-db-to-tokudb.shtml "遷移Zabbix數據庫到TokuDB")，已經接近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、逐一導出備份剩下的幾個大表。在備份大表時，還可以分批次并發導出，方便并發導入，使用mysqldump的"-w"參數，然后在SLAVE上導入恢復（可以打開后面的參考文章鏈接） 5、全部導入完成后，等待復制沒有延遲了，關閉忽略錯誤選項，重啟，正式對外提供服務 ~~~ 上述幾個步驟完成后，可能還有個別不一致的數據，不過會在后期逐漸被覆蓋掉，或者被當做過期歷史數據刪除掉。 本案例的步驟并不適用于全部場景，主要適用于： 不要求數據高一致性，且數據量相對較大，尤其是單表較大的情況，就像本次的Zabbix數據一樣。 參考文章： [遷移Zabbix數據庫到TokuDB](http://imysql.com/2014/06/24/migrate-zabbix-db-to-tokudb.shtml "遷移Zabbix數據庫到TokuDB") [[MySQL FAQ]系列— mysqldump加-w參數備份](http://imysql.com/2014/06/22/mysql-faq-mysqldump-where-option.shtml "[MySQL FAQ]系列— mysqldump加-w參數備份")