mysql binlog gtid_【20180306】MySQL关于GTID的一些随笔

GTID持久化介质有俩个，一个是TABLE mysql.gtid_executed 表，另外一个是binlog日志。

TABLE mysql.gtid_executed表内的gtid信息并不是实时更新的，只有在binlog二进制日志进行切割的时候才会记录到表mysql.gtid_executed中。

binlog二进制日志中的gtid信息是在commit之后生成的，并且这个时候还会生成last commit和seqeue number(这俩个值和MySQL的group commit以及并行复制有关系)

binlog_gtid_simple_recovery 在没有开启这个参数的时候，MySQL重启或者恢复都会扫描全部的binlog获取gtid_executed信息，这样做耗时会很长。开启这个参数之后MySQL只会扫描第一个binlog和最后一个binlog文件。还有一个需要注意的是在中途开启GTID的时候，也会扫描前面所有的binlog直到获取得到

sql_log_bin 支持session级别的动态修改，关闭这个参数之后，那么在当前session并不会产生GTID。

GTID主从复制。

在主库关闭binlog之后不会产生gtid；在从库关闭binlog，那么gtid_executed和gtid_purged和TABLE mysql.gtid_executed是实时更新的。

reset master 会清楚所有的binlog日志，也会清楚所有的gtid_executed和gtid_purged信息。在set global gtid_purged信息的时候需要注意gtid_executed必须为空，并且设置的时候完成之后gtid_purged和gtid_exectued的值是一致的。

Previous gtid Event是包含在每一个binlog的开头用于描述所有以前binlog所包含的全部Gtid的一个集合(包括已经删除的binlog)。在5.6中如果不开启Gtid，那么binlog是不会包含这个Previous gtid Event的，但是在5.7中不开启Gtid也会包含这个Previous gtid Event，实际这一点的改变其意义也是非常巨大，简单的说他为快速扫描binlog(binlog_gtid_simple_recovery=ture)获得正确Gtid集合提供了基础，否则将会扫描大量的binlog，从而浪费I/O性能，这是5.6中一个非常严重的问题。还有一个需要注意的问题就是，在没有开启GTID的时候，Previous gtid Event的值显示的empty，这个时候中途开启GTID的话，MySQL重启读取binlog获取gtid_executed信息的话还是会重新读取旧的binlog直到Previous gtid Event和获取GTID event.

gtid_mode 的值每一次在线修改都会照成binlog的切割,如果发生binlog删除也能够依托 Previous gtid Event快速准确的找到gtid_purged(Gtid_state.lost_gtids)

show slave status 中的数据是从内存中读取的。relay_log_info_repository 为TABLE的时候show slave status和table的数据的可能不一致。主要是因为非事务引擎还是会遵守Sync_relay_log_info写到TABLE中的频率。

mysql.gtid_executed表示5.7.5才开始的一个优化，在没有这个表之前gtid持久化介质就只有binlog，但是针对于复制中的slave有时候并不需要设置级联主从，所以没有必要开启log_slave_update参数，没有开启的这个参数的话就会减少了磁盘和IO。减轻了负担，提高了性能。