标签：mysql从库 executed_gtid_set retrieved_gtid_set
今天从库crash重启后出现很有趣的现象：
可以发现：
Retrieved_Gtid_Set值显示从库没有接收到部分事务，丢失了部分事务。但是从Executed_Gtid_Set显示从库没有丢失事务。
错误日志：
2017-03-08 10:41:12 118393 [ERROR] /usr/local/mysql/bin/mysqld: Sort aborted: Query execution was interrupted
170308 10:55:38 mysqld_safe Number of processes running now: 0
170308 10:55:38 mysqld_safe mysqld restarted
2017-03-08 10:55:39 0 [Note] /usr/local/mysql/bin/mysqld (mysqld 5.6.29-log) starting as process 131069 ...
从中可以看到，mysql crash后由mysqld_safe重新拉起来，应该是IO彪增导致数据库crash重启。CPU和剩余内存并无瓶颈现象。
为了确认从库是否真的因为少接收到事务而漏了部分数据，特意去解析了从库的binlog日志。
可以发现，其实从库后续有接收到事务号：77d12988-29c1-11e6-a323-fa163ea5bbe1:334314693的事务，只是事务号次序被打乱，没有依次递增的情况。
这是主库的binlog日志记录：
注意：由于mysql的主从数据一致是以从库必须严格同主库按照相同sql执行次序为前提的，这种情况虽然从库也接收所有的事务并执行完成，但是主从库的执行次序并不一致。谨慎来说，从库仍然存在数据不一致的风险。需要使用pt工具包对主从库的数据做数据校验为好！
本文出自 “厚积薄发” 博客，请务必保留此出处http://1057212.blog.51cto.com/1047212/1904320
mysql从库Retrieved_Gtid_Set事务数比Executed_Gtid_Set事务数少的异常情况
标签：mysql从库 executed_gtid_set retrieved_gtid_set
原文地址：http://1057212.blog.51cto.com/1047212/1904320
