很多人通過 binlog-do-db, binlog-ignore-db, replicate-do-db 和 replicate-ignore-db 來過濾復制(某些數據庫), 盡管有些使用, 但是,在我看來,他們是危險的,並且他們被濫用了. 對於很多的實例,有更安全的替換方案
為什么危險很簡單: 他們並不像你想的那樣工作. 想象如下的場景: 你設置了 binlog-ignore-db = garbage, 所以 garbage數據庫(在slave上不存在這個數據庫) 中的數據不會被復制
mysql> delete from garbage.junk;
mysql> use garbage;
mysql> update production.users set disabled = 1 where user = "root";
復 制會broke2次, 第一次，因為 slave嘗試着去之西你給第一條語句，但是slave上並沒有這樣的表"garbage.junk" , 第二次, 隱含的, 因為 對 production.users不會被 復制,因為 root帳號並沒有在slave上被禁用掉.
為 什么? 因為 binlog-ignore-db 並不像你想的那樣執行, 我之前說的, "在garbage數據庫中的數據不會被復制" 是錯的, 實際上(數據庫)並沒有這么做.事實上, 他是通過默認的數據庫為“garbage" 的連接, 過濾二進制的(SQL)語句日志的. 換句話說, 過濾不是基於 查詢的字符串的, 而實際於你used的數據庫.
其他我提到的配置選項也都類似. binlog-do-db 和 binlog-ignore-db 語句是特別危險的，因為他們將語句寫入了二進制日志. 意味着你不能使用二進制日志從備份恢復指定時間的數據.
安 全的替換方案是 在 slave上配置過濾, 使用基於查詢中真正涉及到的表的選項, 這些是: replicate-wild-* 選項, 例如, 避免復制 garbage數據庫中的數據的安全的方案是 配置: replicate-wild-ignore-table=garbage.%. 這樣做仍然有一些特殊的情況, 不能正常工作,但可以在更多的情況下正常工作,並且會遇到更少的意外 (gotchas).