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

关于MySQL GTID的一些信息

1. GTID持久化介质有俩个，一个是TABLE mysql.gtid_executed 表，另一个是binlog日志。
2. TABLE mysql.gtid_executed表内的gtid信息并非实时更新的，只有在binlog二进制日志进行切割的时候才会记录到表mysql.gtid_executed中。
3. binlog二进制日志中的gtid信息是在commit以后生成的，而且这个时候还会生成last commit和seqeue number（这俩个值和MySQL的group commit以及并行复制有关系）
4. binlog_gtid_simple_recovery 在没有开启这个参数的时候，MySQL重启或者恢复都会扫描所有的binlog获取gtid_executed信息，这样作耗时会很长。开启这个参数以后MySQL只会扫描第一个binlog和最后一个binlog文件。还有一个须要注意的是在中途开启GTID的时候，也会扫描前面全部的binlog直到获取获得
5. sql_log_bin 支持session级别的动态修改，关闭这个参数以后，那么在当前session并不会产生GTID。
6. 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的值是一致的。
7. 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.
8. gtid_mode 的值每一次在线修改都会照成binlog的切割,若是发生binlog删除也可以依托 Previous gtid Event快速准确的找到gtid_purged(Gtid_state.lost_gtids)
9. show slave status 中的数据是从内存中读取的。relay_log_info_repository 为TABLE的时候show slave status和table的数据的可能不一致。主要是由于非事务引擎仍是会遵照Sync_relay_log_info写到TABLE中的频率。
10. mysql.gtid_executed表示5.7.5才开始的一个优化，在没有这个表以前gtid持久化介质就只有binlog，可是针对于复制中的slave有时候并不须要设置级联主从，因此没有必要开启log_slave_update参数，没有开启的这个参数的话就会减小了磁盘和IO。减轻了负担，提升了性能。

问题：

1. 重启或者恢复gtid_executed和gtid_purged的值是从TABLE mysql.gtid_executed中获取获得仍是从binlog二进制中获取获得的。
   • 数据库重启会分别去读取binlog和mysql.gtid_executed中信息，可是主要仍是以binlog为主。
2. mysqldump备份没有设置--set-gtid-purged=OFF会备份的时候set @SESSION.SQL_LOG_\BIN=0，这个时候后续的全部操做都不会记录在binlog当中去，而且也不会生成GTID；并且还会设置SET @@GLOBAL.GTID_PURGED的值。
   • 在这里还须要注意的一点就是进行全量的备份的时候也会备份mysql.executed表的信息。这里须要注意的有一点：在进行备份的时候并不会对binlog进行切割，可是因为mysql.gtid_executed记录的GTID信息并非实时的，因此致使备份恢复的时候恢复mysql.gtid_executed表内的值比实际上gtid_executed和gtid_purged值小于或者等于，这个时候有由于恢复的时候不会生成binlog，致使TABLE mysql.gtid_executed的值和实际上gtid_executed和gtid_purged的值不相同。
   • 这个时候能重启从库，从库就会报错1236错误。