最近遇到一个主从同步断开的案例，是由于在执行GRANT语句时，授权对象给错了，也就可以理解为无效的GRANT语句，我们收到slave库同步断开的报警信息，然后去找问题，发现binlog有报错，报错提示谷歌一下，才知道原来这是一个bug，下面我们进行问题还原，看看发生了什么。

 

当时用的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的博客

您的支持是对博主最大的鼓励，感谢您的认真阅读。本文版权归作者所有，欢迎转载，但请保留该声明。

 

作者：陆炫志

出处：xuanzhi的博客

您的支持是对博主最大的鼓励，感谢您的认真阅读。本文版权归作者所有，欢迎转载，但请保留该声明。