数据库环境：Mariadb 10.1.12
主从架构：一主三从
问题描述：今日接到某项目组故障技术支持请求，称他们的系统的三个从库在同一时间全部因“sql thread”关闭而丢失主从关系。
分析过程：首先通过命令show slave status \G;
发现slave_sql_running线程的状态为“NO”
last_error这行显示：could not execute update_rows_xxx event on table user.t1;can't find record in 't1',error_code 1032..... the event's log mysql-bin.004417。
因为没有太多线索可以直接引用，所以只能根据数据库提示的binlog名称和具体gtid值去查询二进制文件中是否有一些有价值的信息。
通过使用 mysqlbinlog --no-defaults -v --base64-output=decode-rows mysql-bin.004417 > /tmp/binlog.txt,
通过gtid值查找binlog.txt文件发现相对应的位置上只是一条简单的update语句，语句简化如下：update t1 set a=xyz where b=x。此时，思路又陷入僵局中，这个sql语句并没有过多的提示，最后经过和项目组运维人员讨论，决定先比对主从之间到底相差多少条数据入手，经过使用select count(*) from t1 where取一个合适的值统计后发现主库（1040条）比从库（1032）多了8条数据。
这8条不同的数据又如何找到呢？方法应该是很多：UE、EXCEL、DIFF命令，这里我使用excel的单独排序每条数据的id列，i找到了这8条数据，其中，7条数据显示今天主库的插入记录，这7条可以忽略不计，根据id值，找到了剩下那1条数据的插入显示时间为半个月前的一个晚上，这就奇怪了，主库居然有一条从库没有的数据，大家都知道从库是根据binlog日志同步主库数据的，现在主库居然瞒着备库发生了这条数据DML操作！！
到目前为止，可以得到的初步结论是：主库比从库多一条半个月前的数据，今天主库更新了这条记录，从库发现并没有相应的数据，继而导致从库sql线程停止；第二个初步结论是：binlog居然不记录DML操作！！！
这时，查半个月前的binlog日志文件已经不在操作系统上了。
往往这时，官方文档会有很好的发挥余地。以下摘自mariadb关于复制的解读：
Replication is based upon the binary log. However, cascading deletes or updates based on foreign key relations are an internal mechanism, and are not written to the binary log.
Because of this, an identical statement run on the master and the slave may result in different outcomes if the foreign key relations are not identical on both master and slave This could be the case if the storage engine on one supports cascading deletes (e.g. InnoDB) and the storage engine on the other does not (e.g. MyISAM), or the one has specified a foreign key relation, and the other hasn't.
大意是：基于外键级联删除和更新的操作属于内部机制，是不记录binlog日志的。
如果主和从服务器的外键关系不相同，则在主从服务器上运行相同的sql语句会导致不同的结果；或者主服务器上支持级联删除的存储引擎（innodb），从上面不支持（myisam），或者主上面支持外键，从上面不支持。
以上结论都可以导致问题的发生。
参考地址如下：https://mariadb.com/kb/en/library/replication-and-foreign-keys/
问题分析到最后，结果是这个属性导致的。同时，在从库上的错误日志中可以发现这么一条语句：
internal mariadb error code:1032 呵呵，数据库早就告诉DBA这是一条内部错误。
问题分析到这，明天去项目组验证这个由外键引起的一个问题。