本文的主要目的是记下跟gtid相关的backtrace，用于以后的问题排查。另外也会讨论目前在MySQL5.6.11版本中存在的bug。

前言：什么是GTID

什么是GTID呢， 简而言之，就是全局事务ID(global transaction identifier )，最初由google实现，官方MySQL在5.6才加入该功能，本文的起因在于5.6引入一大堆的gtid相关变量，深感困惑。

去年年中的时候，也写过一片简短的博客，大致介绍了下gtid是什么， http://mysqllover.com/?p=87  。本文也不打算太多文字的介绍，因为网络上已经有大量的类似文章。

GTID的格式类似于：

这是在我的一台服务器上生成的gtid记录，它在binlog中表现的事件类型就是：

GTID_LOG_EVENT:用于表示随后的事务的GTID

另外还有两种类型的GTID事件：

ANONYMOUS_GTID_LOG_EVENT ：匿名GTID事件类型（暂且不论）

PREVIOUS_GTIDS_LOG_EVENT： 用于表示当前binlog文件之前已经执行过的GTID集合，记录在Binlog文件头，例如：

这个字符串，用“：”分开，前面表示这个服务器的server_uuid，这是一个128位的随机字符串，在第一次启动时生成（函数generate_server_uuid），对应的variables是只读变量server_uuid。 它能以极高的概率保证全局唯一性，并存到文件DATA/auto.cnf中。因此要注意保护这个文件不要被删除或修改，不然就麻烦了。

第二部分是一个自增的事务ID号，事务id号+server_uuid来唯一标示一个事务。

除了单独的GTID外，还有一个GTID SET的概念。一个GTID SET的表示类似于：

GTID_EXECUTED和GTID_PURGED是典型的GTID SET类型变量；在一个复制拓扑中，GTID_EXECUTED 可能包含好几组数据，例如：

本文讨论的内容包括：

一.主库上的gtid产生及记录

二.备库如何使用GTID复制

三.主备运维的变化

四.MySQL5.6.11存在的bug

一、主库上的Gtid

a.相关变量
主库上每个事务的Gtid包括变化的部分和不变的部分。在讨论之前，要弄清楚GTID维护的四个变量：

GTID_PURGED ：已经被删除的binlog的事务，它是GTID_EXECUTED的子集，从MySQL5.6.9开始，该变量无法被设置。

GTID_OWNED :  表示正在执行的事务的gtid以及对应的线程ID。

例如如下：

GTID_EXECUTED  表示已经在该实例上执行过的事务； 执行RESET MASTER 会将该变量置空; 我们还可以通过设置GTID_NEXT执行一个空事务，来影响GTID_EXECUTED

GTID_NEXT 是SESSION级别变量，表示下一个将被使用的GTID

在内存中也维护了与GTID_PURGED， GTID_OWNED, GTID_EXECUTED相对应的全局对象gtid_state。

gtid_state中维护了三个集合，其中logged_gtids对应GTID_EXECUTED， lost_gtids对应GTID_PURGED，owned_gtids对应GTID_OWNED

b.如何分配和使用GTID

在主库执行一个事务的过程中，关于Gtid主要涉及到以下几个部分：

事务开始，执行第一条SQL时 ，在写入第一个“BEGIN” 的QUERY EVENT 之前， 为binlog cache 的Group_cache中分配一个group(Group_cache::add_logged_group)，并写入一个Gtid_log_event，此时并未为其分配事务id,backtrace 如下：

暂时还不清楚什么时候一个事务里会有多个gtid的group_cache.

在binlog group commit的flush阶段 ：

第一步，调用Group_cache::generate_automatic_gno来为当前线程生成一个gtid，分配给thd->owned_gtid，并加入到owned_gtids中，backtrace如下：

也就是说，直到事务完成，准备把binlog刷到binlog cache时，才会去为其分配gtid.

当gtid_next的类型为AUTOMATIC时，调用generate_automatic_gno生成事务id(gno)，分配流程大概如下：

1.gtid_state->lock_sidno(automatic_gtid.sidno) , 为当前sidno加锁，分配过程互斥

2.gtid_state->get_automatic_gno(automatic_gtid.sidno); 获取事务ID

        |–>初始化候选(candidate)gno为1

        |–>从logged_gtids[$sidno]中扫描，获取每个gno区间(iv)：

               |–>当candidate < iv->start（或者MAX_GNO，如果iv为NULL）时，判断candidate是否有被占用，如果没有的话，则使用该candidate，从函数返回，否则candidate++，继续本步骤

        |–>将candidate设置为iv->end，iv指向下一个区间，继续第二步

        从该过程可以看出，这里兼顾了区间存在碎片的场景，有可能分配的gno并不是全局最大的gno. 不过在主库不手动设置gtid_next的情况下，我们可以认为主库上的gno总是递增的。

3.gtid_state->acquire_ownership(thd, automatic_gtid);

         |–>加入到owned_gtids集合中(owned_gtids.add_gtid_owner)，并赋值给thd->owned_gtid= gtid

4.gtid_state->unlock_sidno(automatic_gtid.sidno);  解锁

第二步， 调用Gtid_state::update_on_flush将当前事务的grid加入到logged_gtids中,backtrace如下：

在bin log group commit的commit阶段

调用Gtid_state::update_owned_gtids_impl 从owned_gtids中将当前事务的gtid移除,backtrace 如下：

上述步骤涉及到的是对logged_gtids和owned_gtids的修改。而lost_gtids除了启动时维护外，就是在执行Purge操作时维护。

例如，当我们执行purge binary logs to ‘mysql-bin.000205′ 时， mysql-bin.index先被更新掉，然后再根据index文件找到第一个binlog文件的PREVIOUS_GTIDS_LOG_EVENT事件，更新lost_gtids集合，backtrace如下：

关于binlog group commit，参见之前写的博客： http://mysqllover.com/?p=581  

c.如何持久化GTID
当重启MySQL后，我们看到GTID_EXECUTED和GTID_PURGED和重启前是一致的。

持久化GTID，是通过全局对象gtid_state来管理的。gtid_state在系统启动时调用函数gtid_server_init分配内存；如果打开了binlog，则会做进一步的初始化工作：

gtid_state 包含3个gtid集合：logged_gtids， lost_gtids， owned_gtids，前两个都是gtid_set类型, owned_gtids类型为Owned_gtids

MYSQL_BIN_LOG::init_gtid_sets 主要用于初始化logged_gtids和lost_gtids,该函数的逻辑简单描述下：

1.扫描mysql-index文件，搜集binlog文件名，并加入到filename_list中

2.从最后一个文件开始往前读，依次调用函数read_gtids_from_binlog：

      |–>打开binlog文件，如果读取到PREVIOUS_GTIDS_LOG_EVENT事件

          (1)无论如何，将其加入到logged_gtids（prev_gtids_ev->add_to_set(all_gtids)）

          (2)如果该文件是第一个binlog文件，将其加入到lost_gtids（prev_gtids_ev->add_to_set(prev_gtids)）中.

     

      |–>获取GTID_LOG_EVENT事件

          (1) 读取该事件对应的sidno，sidno= gtid_ev->get_sidno(false);

               这是一个32位的整型，用sidno来代表一个server_uuid，从1开始计算，这主要处于节省内存的考虑。维护在全局对象global_sid_map中。

               当sidno还没加入到map时，调用global_sid_map->add_sid(sid)，sidno从1开始递增。

          (2) all_gtids->ensure_sidno(sidno)

               all_gtids是gtid_set类型，可以理解为一个集合，ensure_sidno就是要确保这个集合至少可以容纳sidno个元素

          (3) all_gtids->_add_gtid(sidno, gtid_ev->get_gno()  

               将该事件中记录的gtid加到all_gtids[sidno]中(最终调用Gtid_set::add_gno_interval，这里实际上是把(gno, gno+1)这样一个区间加入到其中，这里

               面涉及到区间合并，交集等操作    )

当第一个文件中既没有PREVIOUS_GTIDS_LOG_EVENT， 也没有GTID_LOG_EVENT时，就继续读上一个文件

如果只存在PREVIOUS_GTIDS_LOG_EVENT事件，函数read_gtids_from_binlog返回GOT_PREVIOUS_GTIDS

如果还存在GTID_LOG_EVENT事件，返回GOT_GTIDS

这里很显然存在一个问题，即如果在重启前，我们并没有使用gtid_mode，并且产生了大量的binlog，在这次重启后，我们就可能需要扫描大量的binlog文件。这是一个非常明显的Bug， 后面再集中讨论。

3.如果第二部扫描，没有到达第一个文件，那么就从第一个文件开始扫描，和第2步流程类似，读取到第一个PREVIOUS_GTIDS_LOG_EVENT事件，并加入到lost_gtids中。

简单的讲，如果我们一直打开的gtid_mode，那么只需要读取第一个binlog文件和最后一个binlog文件，就可以确定logged_gtids和lost_gtids这两个GTID SET了。

二、备库上的GTID
a.如何保持主备GTID一致
由于在binlog中记录了每个事务的GTID，因此备库的复制线程可以通过设置线程级别GTID_NEXT来保证主库和备库的GTID一致。

默认情况下，主库上的thd->variables.gtid_next.type为AUTOMATIC_GROUP，而备库为GTID_GROUP

备库SQL线程gtid_next输出：

这些变量在执行Gtid_log_event时被赋值：Gtid_log_event::do_apply_event，大体流程为：

1.rpl_sidno sidno= get_sidno(true);  获取sidno

2.thd->variables.gtid_next.set(sidno, spec.gtid.gno);  设置gtid_next

3.gtid_acquire_ownership_single(thd); 

     |–>检查该gtid是否在logged_gtids集合中，如果在的话，则返回（gtid_pre_statement_checks会忽略该事务）

     |–>如果该gtid已经被其他线程拥有，则等待(gtid_state->wait_for_gtid(thd, gtid_next))，否则将当前线程设置为owner(gtid_state->acquire_ownership(thd, gtid_next))

在上面提到，有可能当前事务的GTID已经在logged_gtids中，因此在执行Rows_log_event::do_apply_event或者mysql_execute_command函数中，都会去调用函数gtid_pre_statement_checks

该函数也会在每个SQL执行前，检查gtid是否合法，主要流程包括：

1.当打开选项enforce_gtid_consistency时，检查DDL是否被允许执行（thd->is_ddl_gtid_compatible()），若不允许，返回GTID_STATEMENT_CANCEL

2.检查当前SQL是否会产生隐式提交并且gtid_next被设置（gtid_next->type != AUTOMATIC_GROUP），如果是的话，则会抛出错误ER_CANT_DO_IMPLICIT_COMMIT_IN_TRX_WHEN_GTID_NEXT_IS_SET 并返回GTID_STATEMENT_CANCEL，注意这里会导致bug#69045

3.对于BEGIN/COMMIT/ROLLBACK/(SET OPTION 或者 SELECT )且没有使用存储过程/ 这几种类型的SQL，总是允许执行，返回GTID_STATEMENT_EXECUTE

4.gtid_next->type为UNDEFINED_GROUP，抛出错误ER_GTID_NEXT_TYPE_UNDEFINED_GROUP，返回GTID_STATEMENT_CANCEL

5.gtid_next->type == GTID_GROUP且thd->owned_gtid.sidno == 0时， 返回GTID_STATEMENT_SKIP

其中第五步中处理了函数gtid_acquire_ownership_single的特殊情况

b.备库如何发起DUMP请求
引入GTID，最大的好处当然是我们可以随心所欲的切换主备拓扑结构了。在一个正常运行的复制结构中，我们可以在备库简单的执行如下SQL：

打开GTID后，我们就无需指定binlog文件或者位置，MySQL会自动为我们做这些事情。这里的关键就是MASTER_AUTO_POSITION。IO线程连接主库，可以大概分为以下几步：

1.IO线程在和主库建立TCP链接后，会去获取主库的uuid（get_master_uuid），然后在主库上设置一个用户变量@slave_uuid(io_thread_init_commands)

2.之后，在主库上注册SLAVE（register_slave_on_master）

在主库上调用register_slave来注册备库，将备库的host,user,password,port,server_id等信息记录到slave_list哈希中。

3.调用request_dump，开始向主库请求数据，这里分两种情况：

MASTER_AUTO_POSITION=0时，向主库发送命令的类型为COM_BINLOG_DUMP，这是传统的请求BINLOG的模式

MASTER_AUTO_POSITION=1时，命令类型为COM_BINLOG_DUMP_GTID，这是新的方式。

这里我们只讨论第二种。第二种情况下，会先去读取备库已经执行的gtid集合

构建完成发送包后，发送给主库。

在主库上接受到命令后，调用入口函数com_binlog_dump_gtid，流程如下：

1.slave_gtid_executed.add_gtid_encoding(packet_position, data_size) ;读取备库传来的GTID SET 

2.读取备库的uuid(get_slave_uuid)，被根据uuid来kill僵尸线程(kill_zombie_dump_threads)

这也是之前SLAVE IO线程执行SET @SLAVE_UUID的用处。

3.进入mysql_binlog_send函数：

         |–>调用MYSQL_BIN_LOG::find_first_log_not_in_gtid_set，从最后一个Binlog开始扫描，获取文件头部的PREVIOUS_GTIDS_LOG_EVENT，如果它是slave_gtid_executed的子集，保存当前binlog文件名，否则继续向前扫描。

         这一步的目的就是为了找出备库执行到的最后一个Binlog文件。

         

         |–>从这个文件头部开始扫描，遇到GTID_EVENT时，会去判断该GTID是否包含在slave_gtid_executed中：

         主库通过GTID决定是否可以忽略事务，从而决定执行开始的位置 

注意，在使用MASTER_LOG_POSITION后，就不要指定binlog的位置，否则会报错。

三、运维操作

a.如何忽略复制错误

当备库复制出错时，传统的跳过错误的方法是设置sql_slave_skip_counter,然后再START SLAVE。

但如果打开了GTID，就会设置失败：

提示的错误信息告诉我们，可以通过生成一个空事务来跳过错误的事务。

我们手动产生一个备库复制错误：

查看binlog中，该DDL对应的GTID为7a07cd08-ac1b-11e2-9fcf-0010184e9e08:1131

在备库上执行：

再查看show slave status，就会发现错误事务已经被跳过了。这种方法的原理很简单，空事务产生的GTID加入到GTID_EXECUTED中，这相当于告诉备库，这个GTID对应的事务已经执行了。

b.重指主库
使用change master to …. , MASTER_AUTO_POSITION=1；

注意在整个复制拓扑中，都需要打开gtid_mode

c.新的until条件
5.6提供了新的util condition，可以根据GTID来决定备库复制执行到的位置

SQL_BEFORE_GTIDS：在指定的GTID之前停止复制

SQL_AFTER_GTIDS ：在指定的GTID之后停止复制

判断函数为Relay_log_info::is_until_satisfied

详细文档见： http://dev.mysql.com/doc/refman/5.6/en/start-slave.html  

d.适当减小binlog文件的大小
如果开启GTID，理论上最好调小每个binlog文件的最大值，以缩小扫描文件的时间。

四、存在的bug

当在重启前没有使用gtid_mode，重启后可能会去扫描所有的binlog文件，如果Binlog文件很多的话，这显然是不可接受的。

TODO:GTID_NEXT_LIST的逻辑上面均未提到，有空再看。

判断报错的backtrace：

解决办法：将备库的复制模式设置为’ROW’ ，保持主备一致

该bug和GTID无关

也是一个很低级的bug，在MySQL5.6.11版本中，如果有可能导致隐式提交的事务， 则gtid_next必须等于AUTOMATIC，对备库复制线程而言，很容易就中断了，判断逻辑在函数gtid_pre_statement_checks中

--转自