MySQL 5.6 全局事务 ID(GTID)实现原理(二)

原文连接:http://qing.blog.sina.com.cn/1757661907/68c3cad333002qsk.html

原文作者:淘长源

转载注明以上信息


 

前文 MySQL 5.6 全局事务 ID(GTID)实现原理(一)? 介绍了 MySQL 5.6 全局事务 ID 的定义和相关的数据结构 Gtid_set 与 Sid_map。接下来,这一篇的主要目标是深入了解文章最后提到的全局事务状态 Gtid_state。并且,如果可能 —— 顺便介绍下这些 Gtid_state 在主备复制中的功能:

 
全局事务状态 Gtid_state
 
Gtid_state 是 MySQL 5.6 内的一个全局对象,它的数据结构如下: 
(mysql-5.6.9-rc\sql\rpl_gtid.h,line 2043)
 
Gtid_state := (logged_gtids, lost_gtids, owned_gtids)
 
创建 Gtid_state 的代码可以在 mysqld.cc 的 gtid_server_init 方法里找到。
(代码路径:mysql-5.6.9-rc\sql\mysqld.cc, 1719 line)
 
Gtid_state 的重要性是,它维护三个与全局事务 ID 有关的 MySQL global variables:
 
logged_gtids / `gtid_executed`
 
存储已经执行过,并且记录到 binlog 的全局事务 ID 集合。它对应的 MySQL variable 是 gtid_executed,可以用命令:
 
SHOW GLOBAL VARIABLES LIKE ‘gtid_executed‘
 
查看数据库上已经执行的全局事务 ID。
 
MySQL 5.6 在开启 --gtid_mode?=ON 后,每当执行完一个事务,就会调用 Gtid_state 的 update_on_flush() 方法,把事务对应的 GTID 写入 logged_gtids。
 
详细一点的过程是这样的:
 
为了防止写入 binlog 的是一组不完整的事务,MySQL 会缓存整个事务的 binlog 内容在 binlog_cache_data 中。如果事务提交,MySQL 会执行一个叫 ordered_commit() 的三阶段提交操作:
(源代码:mysql-5.6.9-rc\sql\binlog.cc,line 6245)
 
第一步:调用 process_flush_stage_queue() 和 flush_io_cache() 将缓存在 binlog_cache_data 中的内容刷出到 binlog 文件。此时,Gtid_state 的 update_on_flush() 调用到,事务对应的 GTID 写入 logged_gtids。
 
第二步:调用 sync_binlog_file() 在 binlog 文件上执行 fsync() 保证内容更新到磁盘。 
 
第三步:调用 process_commit_stage_queue() 执行所有事务提交,在存储引擎上调用 ha_commit_low()。
 
结束后,MySQL 调用 Gtid_state 的 update_on_commit(),从 owned_gtids 里删除完成  commit 的全局事务 ID。
 
与名字相同,logged_gtids 用来判断 MySQL 有没有执行某个事务。例如,在 Master 发送 binlog 时,MySQL 5.6 能够根据 Slave 提供的 logged_gtids 记录,自动过滤 binlog 中不需要执行的事务(请参考新增 COM_BINLOG_DUMP_GTID 协议)。 
 
另外,MySQL 5.6 支持在 START SLAVE 时指定 UNTIL_SQL_BEFORE_GTIDS / UNTIL_SQL_AFTER_GTIDS 条件,让 Slave 执行完所需要的事务后就自动停止复制。这个功能也依赖于 Slave 的 logged_gtids 记录来检查作为条件的 GTIDs 是否满足。
 
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 是如何作用于新的主备复制流程的。

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。