测试环境: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操作,看起来都是正常的了,从控制台监控页面看同步也正常了。期间遇到了好几个主从同步失败的信息,基本能明白意思,但是重启后报错信息变了,这个原因就真不明白了,如果有了解的大佬欢迎指教~