今天，所有MySQL從伺服器上的主從複製都被異常中斷了，登陸到其中一臺上執行show slave status\G，發現如下錯誤：--Last_Error: Error 'Operation DROP USER failed for 'guest'@'localhost'' on query. De ...
今天，所有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之後再執行命令。
這類故障的恢復方案很簡單，就是跳過這一條SQL。
--
stop slave;
set global sql_slave_skip_counter=1;
start slave;
show slave status\G
--
參考資料：
http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/
