mysql 5.6 事务_[转]MySQL 5.6 全局事务 ID（GTID）实现原理（二）

lost_gtids / `gtid_purged`

记录从 binlog 删除的全局事务 ID 集合。它对应的 MySQL Global variable 是：gtid_purged​ 。

每当 MySQL 5.6 调用 purge_logs 删除 binlog 时，会顺带更新 lost_gtids 的内容。这是通过读剩下的 binlog 文件实现的，我会在介绍 GTID 在 binlog 的存储方式时描述。

(源代码：mysql-5.6.9-rc\sql\binlog.cc，line 3754)

它的作用是检查 Slave 请求的 Gtids 是否已经被 Master 删除。如果 Master 的 lost_gtids 记录已经不是 Slave 的 logged_gtids 记录的子集，请求的 Slave 会收到代码为 ER_MASTER_HAS_PURGED_REQUIRED_GTIDS 的错误。

owned_gtids / `gtid_owned`

正在由线程执行的全局事务 ID 集合。它对应的 MySQL variable 是：gtid_owned，而对应​的类型是 Owned_gtids，基本上可以看作一个 Gtid 到 owner_thread_id 的 hash_map 映射：

Owned_gtids := array(sidno => hash_map(Node))

Node := (gno, owner_thread_id)

其中 gno 是 Gtid 中的事务 ID。

在 MySQL 5.6 中，owned_gtids 提供了一个正在执行的事务纪录(以及执行它们的线程 ID)。这份记录是怎么维护的？ —— 这与 MySQL 产生 GTID 的过程有关：

每个数据库更新都会产生一条 binlog，当一条 binlog 写入 binlog_cache_data 之前，MySQL Master 会调用 generate_automatic_gno() 产生一个 gno —— 事务 ID，详细过程是这样的：

首先，generate_automatic_gno  会检查 Gtid_state 中的 logged_gtids 和 owned_gtids，找到一个当前最大的而且没有使用的 gno(Gtid_state 的 get_automatic_gno() 方法)，创建出新的 Gtid。

然后，MySQL 调用 Gtid_state 的 acquire_ownership()，把新的 Gtid 写入全局的 owned_gtids，并记录到线程的 owned_gtid 变量(注意：NDB 集群的处理有不同，这里我不一一介绍了)。

当事务结束时，MySQL 会调用 Gtid_state 的 update_on_commit / update_on_rollback 方法，把线程执行的 owned_gtid 从全局 owned_gtids 中删除。

全局 owned_gtids 常常用来反向查找执行事务的线程。有个需要关注的点，在 Gtid_state 的 acquire_ownership() 方法中，如果所给的 Gtid 在全局 owned_gtids 已经被标记成另一个线程执行，那么 MySQL 会尝试等待并检查这个线程是否被 kill。

Gtid_state 回顾

从上面 Gtid_state 的实现逻辑中，大家可以看到，在 MySQL 5.6 里一个全局事务 ID 的生命周期是这样的：

首先，执行数据库操作时，产生一个全局事务 ID，立即记录到全局和当前线程的 gtid_owned (owned_gtids)状态。

接着，提交数据库事务时，新产生的全局事务 ID 被写入 binlog，接着记录到 gtid_executed(logged_gtids)状态，然后从全局与线程区域的 gtid_owned (owned_gtids)状态中清除。

如果 DBA 执行了 purge 操作删除 binlog，被删除的全局事务 ID 会记录到 gtid_lost(lost_gtids)。但是，这些全局事务 ID 仍然包含在 gtid_executed(logged_gtids)全局状态里。

最后。

在上面的介绍中，我刻意没有提到 MySQL 是怎么保持这些全局事务状态的持久化的。因为这些和 5.6 新增的 binlog 事件 Gdit_log_event / Previous_gtid_log_event 有关。下一篇，我会先介绍一下 MySQL 5.6 对 binlog 格式的扩展，然后再介绍全局事务 ID 是如何作用于新的主备复制流程的。