MySQL binlog-do-db選項是危險的[轉]

不少人經過 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).