前言

MySQL 5.6引入了GTID，每个事务都会产生一个GTID，我们可以通过验证主从GTID来验证主从数据的一致性。

为了叙述简便，定义一个量ALL_GTID: 表示某个数据库实例上 所有存在过的 或 将要存在的事务 的GTID（包括已经被purge掉的事务）。

在讨论数据库可用性的场景中, 当发生主备切换时, 需要进行数据补偿。通过比较主备的ALL_GTID，可以确定需要补偿多少数据:

1. 在实例存活的情况，可以在实例状态中查询ALL_GTID。
2. 在实例崩溃的情况，无法在实例状态中查询ALL_GTID。可以通过查询BINLOG中的Previous-GTIDs计算来获得ALL_GTID。

下面列举与ALL_GTID相关的变量。

与ALL_GTID相关的变量 Previous-GTIDs

Previous-GTIDs格式如下（环境为MySQL5.7，日志手动flush binary …

背景

在保障MySQL高可用时, 数据零丢失是某些场景比较关心的指标, 一种常用的方案是用半同步插件并将超时时间调整的比较大. 这种用法可以保障一定场景内的数据零丢失, 不过会丧失一定运维性(需要实时监控半同步插件的状况, 不能简单地通过show slave status获取), 也会丧失一定的架构健壮性(需要考虑备机故障时将高可用性降级, 维持业务连续性).

除了上面的特性丧失, 还有一个比较稀有的场景需要考虑, 就是网络的健壮性.

测试背景是MySQL 5.7.12.

半同步流程简述

MySQL组提交分为三个阶段:
1. Flush (将待提交事务的日志写入cache)
2. Sync (将待提交事务的日志cache刷盘)
3. Commit (将待提交事务提交, 更新存储引擎/更新GTID等)

每个阶段由一个leader线程负责, …