MySQL:MGR异常一列（8.0.25 BUG确认）

---

版本：8.0.23，8.0.24
以下为简单分析，不做仔细的代码分析，关于这个问题我已经提交了BUG，并且确认为BUG。
https://bugs.mysql.com/bug.php?id=104118

---

一、报错信息

最后收到一个second节点全部异常退出的case日志如下：

image.png

二、原因

这个问题是由于second节点的applier通道的SQL线程在执行语句的时候由于主库手动修改了user表，并且进行了2次授权操作，当然第1次抛错了因为user字典表的缓存信息没有更新。此时second节点的user表内存信息没有更新（实际上就是只进行了1次授权，发现错误则报错停止group replication），所以所有second节点都down掉了。
但是第1次遇到错误后second节点会更新缓存信息，因此在此启动的时候applier通道的SQL线程再次执行则通过，这样就恢复正常了。（版本8.0.24,8.0.23）

MGR主节点进行如下操作如下则可以重现：

create user testuser identified with mysql_native_password by 'TT123t$';
update mysql.user set host='192.168.1.100' where user=testuser ;
grant select,update,insert,delete on gr_opt.* to testuser @'192.168.1.100';（报错后会更新缓存）
grant select,update,insert,delete on gr_opt.* to testuser @'192.168.1.100';（再来一次则正常）

这里在修改字典表后进行flush privileges则可以规避这个问题。当然最好不要手动修改用户字典表。这个问题应该会影响主从同步，因为实际上和sql线程的应用没有关系。因此最好规范操作不要手动修改字典表信息。

三、简单的断点验证

这里就是简单的断点验证不做细致的研究了。

• 验证用户失败

  
  image.png

这里来自缓存信息

• 失败后更新user表缓存

  
  image.png

• flush privileges;进行缓存更新

image.png

这个操作同样会同步到second节点或者从节点。