本文目录如下：
事故现场环境：测试环境时间：上午10:30反馈人员：测试群，炸锅了，研发同事初步排查后，发现可能是数据库问题。然后就开始找原因吧。因为这套集群环境是我部署的，所以我来排查的话轻车熟路。
系统部署图先说下系统的部署图，方便大家理解。
两个数据库部署在node55和node56节点上，他们互为主从关系，所以叫做双主。
还有两个Keepalived部署在node55和node56上面，分别监控MySQL容器的状态。
报错原因和解决方案①我第一个想法就是，不是有Keepalived来保证高可用么，即使MySQL挂了，也可以通过Keepalived来自动重启才对。即使一台重启不起来，还有另外一台可以用的吧？②那就到服务器上看下MySQL容器的状态吧。到MySQL的两台服务器上，先看下MySQL容器的状态，dockerps命令，发现两台MySQL容器都不在列表中，这代表容器没正常运行。③这不可能，我可是安装了Keepalived高可用组件的，难道Keepalived也挂了？④赶紧检查一波Keepalived，发现两台Keepalived是正常运行的。通过执行命令查看：systemctlstatuskeepalived⑤纳尼，Keepalived也是正常的，Keepalived每隔几秒会重启MySQL，可能我在那一小段空闲时间没看到MySQL容器启动？换个命令执行下，dockerps-a，列出所有容器的状态。可以看到MySQL启动后又退出了，说明MySQL确实是在重启。⑥那说明Keepalived虽然重启了MySQL容器，但是MySQL自身有问题，那Keepalived的高可用也没办法了。⑦那怎么整？只能看下MySQL报什么错了。执行查看容器日志的命令。dockerlogs<容器id>。找到最近发生的日志：⑧提示mysql-bin.index文件不存在，这个文件是配置在主从同步那里的，在my.cnf配置里面。这个配置好后，然后执行主从同步的时候，就会在var/lib/mysql/log目录下生成多个mysql-bin.xxx的文件。还有一个mysql-bin.index索引文件，它会标记现在binlog日志文件记录到哪里了。
mysql-bin.index文件里面的内容如下：
/var/lib/mysql/log/mysql-bin.000001
这个mysql-bin.000001文件还是带序号的，这里还有坑，后面我再说。
⑨报错信息是提示缺少mysql-bin.index，那我们就去检查下呗，确实没有啊！先不管这个文件怎么消失的吧，赶紧把这个log文件夹先创建出来，然后mysql会自动给我们生成这个文件的。
解决方案：执行以下命令创建文件夹和添加权限。
mkdirlogchmod777log-R
⑩两台服务器上都有这个log目录后，Keepalived也帮我们自动重启好了MySQL容器，再来访问下其中一个节点node56的MySQL的状态，咦，居然报错了。
Last_IO_Error:Gotfatalerror1236frommasterwhenreadingdatafrombinarylog:'Couldnotfindfirstlogfilenameinbinarylogindexfile'
可以看到几个关键信息：
Slave_IO_Running:NO，当前同步的I/O线程没有运行，这个I/O线程是从库的，它会去请求主库的binlog，并将得到的binlog写到本地的relay-log(中继日志)文件中。没有运行，则代表从库同步是没有正常运行。Master_Log_File:mysql-bin.000014，说明当前同步的日志文件为000014，之前我们看到节点node56上mysql.index里面写的是000001，这个000014根本就不在index文件里面，所以就会报错了。
这里涉及到主从同步的原理，上一张图：
从库会生成两个线程,一个I/O线程,一个SQL线程;
I/O线程会去请求主库的binlog日志文件,并将得到的binlog日志文件写到本地的relay-log(中继日志)文件中;
主库会生成一个dump线程,用来给从库I/O线程传binlog;
SQL线程，会读取relaylog文件中的日志,并解析成SQL语句逐一执行。
那好办啊，我们重新指定下同步哪个日志文件，以及同步的位置就好了。
解决方案：
看下主库node55上日志文件状态。
记下这两个信息：File=mysql-bin.00001，Position=117748。（这里也有个坑：先要锁表，再看这两个值，从库开始同步后，再解锁表）。
具体执行的命令如下：
FLUSHTABLESWITHREADLOCK;SHOWMASTERSTATUSUNLOCKTABLES
然后在从库node56上重新指定同步的日志文件和位置：
#停止从库同步STOPSLAVE;#设置同步文件和位置CHANGEMASTERTOMASTER_HOST='10.2.1.55',MASTER_PORT=3306,MASTER_USER='vagrant',MASTER_PASSWORD='vagrant',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=117748;#开启同步STARTSLAVE;
再次查看就不报错了，I/O线程也跑起来了，
在这里插入图片描述
然后将node55当做从库，node56当做主库，同样执行上面的几步，状态显示正常了，然后用navicat工具连下数据库，都是正常的，在测试群反馈下结果，搞定收工。
好像忘了一个问题，为啥log文件夹被干掉了？？
为什么会出现问题？然后问了一波当时有没有人删除这个/var/lib/mysql/log目录，也没有人会随便删除这个目录的吧。
但是发现log的上级目录/var/lib/mysql有很多其他文件夹，比如xxcloud,xxcenter等。这不就是我们项目中几个数据库的名字么，只要在这个目录的文件夹，都会显示在navicat上，是一一对应的，如下图所示。其中也显示了log数据库。
那会不会有人从navicat上干掉了log数据库？极有可能啊！
果然，有位同事之前在迁移升级的过程中，发现这个log数据库在老的系统是没有的，所以就清理了，这就相当于把log数据库干掉了，同时也会把log文件夹干掉了。好了，终于水落石出了！这个其实也是我前期没有考虑到log目录的一个问题。没错，这是我的锅~
改进其实操作同步数据库的时候，不应该用这种覆盖同步的方式，可以采取单库同步的方式，也就不会干掉log数据库了。但是，这个log数据库放在这里有点奇怪啊，能不能不要出现在这里呢？
我们只要指定这个log目录不在/var/lib/mysql目录下就好了。
东哥建议：log文件和数据库data文件进行隔离：
datadir=/var/lib/mysql/data
log_bin=/var/lib/mysql/log
另外一个问题，我们的高可用真的高可用了吗？
至少没有做到及时报警，MySQL数据库挂了，我是不知道的，都是通过测试同学反馈的。
能不能及时感知到MySQL异常呢？
这里可以利用Keepalived发送邮件的功能，或者通过日志报警系统。这个是后面需要改进的地方。
来源：https://mp.weixin.qq.com/s/_YgQmI7HeSHFQjFlFyMRoA
