mysql5.7 gitd作用_MySQL5.7 GTID 浅析

GTID 简介

GTID (global transaction identifier)在MySQL5.6时引入，GTID是事务的全局唯一标识。GTID结构如下

GTID = source_id:transaction_id

source_id:执行事务的原始实例的sever_uuid, 此事务GTID在备库apply时也不变。transaction_id:事务的执行编号，binlog_order_commits=1时，此编号根据事务的提交顺序严格递增。GTID是在binlog flush时生成的，因此同一个serverid的GTID在binglog中是严格有序的。binlog_order_commits=0时，GTID在binlog中也是序的，但并不一定与提交的顺序一致。

binlog_order_commits=0会影响XtraBackup工具的备份，但不会影响innobackup工具的备份XtraBackup会从innodb事务page获取最后提交事务的binlog位点信息，binlog_order_commits=0时事务提交顺序和binlog顺序不一定一致，这样此位点前可能存在部分prepare状态的事务，这些事务在备份恢复后会丢失。而innobackup的位点信息是在加备份锁前提下从show master status/show slave status中获取的，位点前的事务都是已提交的。

支持GTID后，备库启动时不再需要通过位点信息从主库来拉取binlog，而是根据备库本身已执行和拉取的gtid去主库查找第一个未执行的GTID，从此GTID位置开始拉取binlog。

新增了COM_BINLOG_DUMP_GTID命令

备库备库封装COM_BINLOG_DUMP_GTID命令，包含备库的gtid_executed(已执行的GTID和当前已拉取的GTID的并集)

request_dump():

gtid_executed.add_gtid_set(mi->rli->get_gtid_set())

gtid_executed.add_gtid_set(gtid_state->get_executed_gtids())

主库主库接收COM_BINLOG_DUMP_GTID命令，从最新的binlog开始反向遍历查找的binlog， 依次读取PREVIOUS_GTIDS_LOG_EVENT, 直到PREVIOUS_GTIDS_LOG_EVENT记录的gtid_set是备库发过来的gtid子集为止。

com_binlog_dump_gtid():

Binlog_sender::init

Binlog_sender::check_start_file(

mysql_bin_log.find_first_log_not_in_gtid_set

Binlog_sender::run

mysql5.7 gtid相对5.6主要有以下变化

gtid_mode可以动态设置，支持gtid模式和非gtid模式之间的复制

增加了gtid_executed表

gtid_mode

MySQL5.7(>= 5.7.6) gtid_mode支持动态修改，gtid_mode取值可选择如下

OFF: Both new and replicated transactions must be anonymous.

OFF_PERMISSIVE: New transactions are anonymous. Replicated transactions can be either anonymous or GTID transactions.

ON_PERMISSIVE: New transactions are GTID transactions. Replicated transactions