當時用的MySQL版本是:5.6.10
下面我們在MySQL 5.6.10版本做測試，查看slave庫信息是處於同步的一個狀態：
在master庫上查看status信息：
在master庫上執行無效grant語句：
mysql> grant file on sakila.* to admin@'192.168.10.129';
相信大家都看到圖了吧，binlog由mysql-bin.000012變成了mysql-bin.000013，那就意味着當執行了無效的grant的時候，可能做了類似flush logs的操作，我們查看mysql-bin.000012發現報這樣的錯：
RELOAD DATABASE; # Shall generate syntax error
現在我們回到slave庫查看一下信息：
看到了，同步已經斷開，報The incident LOST_EVENTS occured on the master. Message: error writing to the binary log錯誤！！！！
以下幾種grant寫法，都觸發刷新了binlog：
測試發現，無論是5.5還是5.6都不能針對庫來授權，5.6針對庫授權file權限，都會觸發刷新了新的binlog，5.5版本則不會，後面會測試MySQL5.5版本。針對所有庫授權file權限是沒問題的，如下：
出現同步斷開的解決方法：
1)使用sql_slave_skip_counter跳過事件，但此方法只適用於基於二進制日誌原理的複製，不適用於基於GTID原理的複製。
2)使用slave_skip_errors跳過錯誤。
3)
在從庫上做change
master操作，重新切換master_log_file和master_log_pos。（由於無效的grant語句執行後會創建新的二進制日誌，所
以可以指定主庫show master status的master_log_file和master_log_pos）
下面我們在MySQL 5.5.40測試：
查看slave庫的信息如下：
在mater查看status並執行無效grant語句：
可以看到，binlog還是原來的binlog，並沒有出現像MySQL5.6的那種情況，我們查看下slave的情況可以看到依然處於同步狀態：
總結：現在越來越多公司用MySQL5.6的版本了，的確MySQL5.6的版本，相對MySQL5.5版本已經改善了不少，所以很多公司已經升級 或者直接用上了MySQL5.6,如果線上用的中5.6版本的MySQL，grant授權的時候就要注意了，無效grant可能會觸發刷新了 binlog，特別對於那種一主多庫的架構，slave提供讀的情況，就更要注意了，這可能是一個bug，在網上找資料的時候，看到5.6.11還有 5.6.13都有出現這樣的情況，有興趣的朋友可以測試下MariaDB，如果有別的見解的朋友，希望能一起請請討論分享下，謝謝。
參考資料：
http://www.psce.com/blog/2013/04/09/granting-privileges-may-break-replication-in-mysql-5-6-10/
https://bugs.mysql.com/bug.php?id=68892（自備***）
作者：xuanzhi
出處：Azhi的博客 http://www.cnblogs.com/xuanzhi201111
您的支持是對博主最大的鼓勵，感謝您的認真閱讀。本文版權歸作者所有，歡迎轉載，但請保留該聲明。