关于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的值是一致的。
  1. 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.
  2. gtid_mode 的值每一次在线修改都会照成binlog的切割,如果发生binlog删除也能够依托 Previous gtid Event快速准确的找到gtid_purged(Gtid_state.lost_gtids)
  3. show slave status 中的数据是从内存中读取的。relay_log_info_repository 为TABLE的时候show slave status和table的数据的可能不一致。主要是因为非事务引擎还是会遵守Sync_relay_log_info写到TABLE中的频率。
  4. 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为主。
  1. 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错误。