mysql 不停库 高可用,【MySQL】高可用架构MySQL主备库间同步失败处理

测试环境：MySQL版本为5.7，performance_schema已经开启(MySQL官方定义的此参数默认开启，但UDB默认关闭，猜测可能是为了启动的时候使用更少的内存，如果希望开启，在自定义配置文件中把performance_schema值设置为1，并且重启UDB生效)

无意间在控制台MySQL监控项页面发现，新创建的UDB的高可用状态异常了，即监控值为1了，虽然只是测试环境，但也好奇究竟是怎么了，登录上去看看吧。

登录控制台上显示的高可用的ip，然后show slave status\G看下，结果发现，双yes非常安逸，那为什么会提示高可用状态异常呢？

从上面一步，我们得到了高可用的备库的ip， 登录到备库上去看看，果然还是有异常的。所以，不要一遇到MySQL高可用状态异常，就引导登录用show slave status\G查看，如果是像这样，备库做为从的时候有异常，就真不一定能看的出来。正确的做法是引导修改表引擎，重做就完事了。>_

从这个上面，只看的出来Last_Errno为1146，Last_Error信息里，也只看的出来是在mysql-bin.,end_log_post:400这里失败了，到底是做什么操作失败，完全看不出来，那就根据error提示信息，解析下binlog里的内容吧。

以上为用mysqlbinlog工具解析的mysql-bin.内容，有兴趣的可以自行在网上查找相关用法(其实我也就会用这一点点而已。。。)，可以看到之前在备库上用show slave status\G看到的error信息里提示的binlog位置里，end_log pos，其实是在做update操作，但这个为什么会报错，还是看不出来。

See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.

那就再根据上面报错提示，来看看performance_schema.replication_applier_status_by_worker的信息吧

这个提示就很明显了，是因为执行update操作的时候，jk.b这张表不存在了，下面来验证一下

对比发现，不同步的备库确实里面没有jk.b这张表了，并且所有的库都没了，难怪会报错了，不过幸好开了performance_schema，不然仅从show slave status\G真看不出来为什么会报错了。 为什么备库会没数据，这个暂时没想明白，下面先来想想如何恢复吧。既然备库没数据， 那是不是让它们重新同步下就可以了，来试试吧。(本意是想着备库没数据，先让主库把所有库表的数据同步过来，结果脑子抽了忘记了主从报错里的信息，是提示表不存在，其实已经在执行update了，以下change master步骤其实是多余的，记录共勉)

重新搭建主从关系后，看起来没什么问题，那再来看看主从同步状态如何。

居然还是报错了，不过这次不是Slave_SQL_Running为No了，而是Slave_IO_Running为No了，报错码为1236，是不是很眼熟了，主库binlog清除了，没法在从库进行重放了。突然想起来，这个实例是新建的，之前的操作就是导入MySQL5.6的备份文件，然后执行了upgrade操作，而备份文件中，默认SQL_LOG_BIN=0，表示执行的所有语句不记录到binlog中，这样就能解释为什么会报错提示1236了，因为主库本来就没有之前建库表的binlog。下面来看看之前导入的MySQL5.6的备份文件验证下

这样的话那重新导入一下数据，sql_log_bin已经为0了，不会记录binlog了，stop slave，然后重新在备库上导下数据

导入完毕，再start slave 看下

结果发现报错了，这个报错看不明白什么意思，网上搜索了一下，根据广大网友的意见，是因为低版本备份文件导入了高版本导致，简单说就是需要upgrade一下，检查所有库的所有表是否与当前的新版本兼容，并更新系统库。低版本备份文件导入高版本db是必须要做的一步操作，这个备份文件确实是低版本5.6的，导入到了现在5.7版本的实例中了。操作upgrade需要在db所在的宿主机上操作，而UDB是不开放宿主机登录权限的，所以赶紧联系DBA大佬帮忙操作一波

等操作完后，再次start slave看下，结果发现还是报！错！了！并且根据提示在errorlog中并未找到任何有价值的信息，这时候想到了万能的重启大法，也许重启后就(骗)好(自)了(己)。

重启后start slave，结果报错信息变了，这里真没想明白是什么情况。不过看这个提示，是slave初始化relay_log的时候有问题，那reset slave清理重置下。

发现果然好了，看起来status为双yes了。以下继续进行实际验证

不管是主从同步失败的时候的update操作，还是现在主从同步没问题的update操作，看起来都是正常的了，从控制台监控页面看同步也正常了。期间遇到了好几个主从同步失败的信息，基本能明白意思，但是重启后报错信息变了，这个原因就真不明白了，如果有了解的大佬欢迎指教~