今天，所有MySQL從服務器上的主從複製都被異常中斷了，登陸到其中一臺上執行show slave status\G，發現如下錯誤：
Last_Error: Error 'Operation DROP USER failed for 'guest'@'localhost'' on query. Default database: 'work'. Query: 'drop user 'guest'@'localhost''
也就是說，是 drop user 'guest'@'localhost' 這條命令導致的，而這樣的操作我們通常都只會在Master上進行，並且該操作應該只會影響到“mysql”這個系統數據庫。之前這種操作進行了很多次，可爲什麼唯獨這一次會出問題呢？
經過一番調查之後，最終找到了問題的根源，那就是，
“binlog-do-db, binlog-ignore-db, replicate-do-db, replicate-ignore-db” 這一類參數，並非想象中可靠！
通常，我們會以爲只要設定了以上參數，MySQL的主從複製就會只對我們設定的數據庫生效。但事實上，MySQL不是根據內容來判斷的，而是很傻瓜的根據你執行了“use work”或在初始連接時指定的數據庫來判斷的。
而這次，我們在執行drop user之前，因爲需要從“work”數據庫select一些數據，就use work進入到了work數據庫，而大家都知道在執行drop user的時候是不需要進入“mysql”這個系統數據庫的，所以就直接執行了drop user，但因爲MySQL的判斷我們是在use work之後執行的，所以認爲是針對“work”數據庫的操作就同步了下去，而從庫上是沒有guest@localhost這個用戶的，所以就造成了錯誤，導致主從複製的中斷。
因此，在有主從複製架構的MySQL服務器環境中，我們要儘量避免這樣的跨庫操作，確保是在執行了正確的use dbname之後再執行命令。
解決辦法：
可以在Slave上使用 replicate_wild_do_table 和 replicate_wild_ignore_table 參數來解決跨庫更新的問題：replicate_wild_do_table=test.%
或 replicate_wild_ignore_table=mysql.%
這樣就可以避免出現上述問題了
5.5以上，下面的這些表都建議過濾掉，只複製生產環境數據。
replicate_wild_ignore_table =mysql.%
replicate_wild_ignore_table =test.%
replicate_wild_ignore_table =information_schema.%
replicate_wild_ignore_table =performance_schema.%
參考：
http://blog.chinaunix.net/uid-27038861-id-3515438.html