20180608MySQL5.7新增表mysql.gtid_executed

Posted 2020-11-14

mysql5.7新增表mysql.gtid_executed

MySQL5.6主从，从库获取gtid_executed

在MySQL5.6的时候，主从复制开启了GTID，在slave执行show slave status G的时候可以获取得到当前执行的GTID的集合信息。在MySQL5.6的时候这个值并不是持久化到文件或者数据库表中的，而是每次在slave重启的时候从最后一个binlog文件的末尾读取写入内存中去的。那么这个样子就会造成一个问题，在从库没有开启log_slave_updates这个参数的时候或者说维护人员不小心将binlog文件给删除了之后，那么slave重启之后就会获取不到gtid_executed的值，那么主从环境就会挂掉。

并且还需要注意的一点就是，就算我们开启了log_slave_updates这个参数，将所有来自于master的事务在本地回放的时候写入slave本地的binlog中去的话，那么不可避免会造成磁盘IO和磁盘空间资源的浪费。

MySQL5.7新增的mysql.gtid_executed

在MySQL5.7的时候则将gtid_executed的信息持久化到了表中，这个表就是mysql.gtid_executed表:

[email protected] 11:03:  [(none)]> show create table mysql.gtid_executed G
*************************** 1. row ***************************
       Table: gtid_executed
Create Table: CREATE TABLE `gtid_executed` (
  `source_uuid` char(36) NOT NULL COMMENT ‘uuid of the source where the transaction was originally executed.‘,
  `interval_start` bigint(20) NOT NULL COMMENT ‘First number of interval.‘,
  `interval_end` bigint(20) NOT NULL COMMENT ‘Last number of interval.‘,
  PRIMARY KEY (`source_uuid`,`interval_start`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 STATS_PERSISTENT=0

执行SQL可以看到这个表的一些具体信息:

[email protected] 11:04:  [(none)]> select * from mysql.gtid_executed ;
+--------------------------------------+----------------+--------------+
| source_uuid                          | interval_start | interval_end |
+--------------------------------------+----------------+--------------+
| 4725234c-1acc-11e8-9ff9-000c29a80f41 |              1 |          781 |
| 4725234c-1acc-11e8-9ff9-000c29a80f41 |            989 |         1011 |
| 4cf4a087-1ba3-11e8-92f6-000c2920ceb4 |              1 |         2239 |
+--------------------------------------+----------------+--------------+
3 rows in set (0.00 sec)

新增mysql.gtid_executed表之后，slave重启之后可以直接从这个表中获取信息。需要注意的是mysql.gtid_executed是在主从服务器上面都会进行更新的，而表slave_relay_log_info仅仅只是在从服务器进行更新的。

可以看到上述的表mysql.gtid_executed并没有记录每个事务的GTID的值，而是记录了GTID的起始值和末尾值，这个是因为为了避免这个表的记录疯狂的增长，所以MySQL5.7引入了一个新的进程进行专门的压缩，并且有专门的参数来设置这个压缩比。

[email protected] 11:58:  [(none)]> select thread_id,thread_os_id,name,processlist_command,processlist_state from performance_schema.threads where name like ‘%compress%‘;
+-----------+--------------+--------------------------------+---------------------+-------------------+
| thread_id | thread_os_id | name                           | processlist_command | processlist_state |
+-----------+--------------+--------------------------------+---------------------+-------------------+
|        27 |        23839 | thread/sql/compress_gtid_table | Daemon              | Suspending        |
+-----------+--------------+--------------------------------+---------------------+-------------------+
1 row in set (0.00 sec)

[email protected] 11:59:  [(none)]> show global variables like ‘gtid_executed_compression_period‘;
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| gtid_executed_compression_period | 1000  |
+----------------------------------+-------+
1 row in set (0.01 sec)

[email protected] 11:59:  [(none)]>

还有一点需要我们注意的:mysql.gtid_executed的记录方式是和从库是否开启记录二进制日志是有很大的关系的。若是slave开启了二进制日志，则该表只会在二进制日志切割的时候或者MySQL正常关闭进行更新，否则的话就会进行实时的更新。还有需要注意的一点就是，在MySQL异常关闭的时候GTID的信息是不会记录到这个表中的，在MySQL恢复的时候会从binlog中记录写入这个表中的。

当binlog开启的时候，并且exectued_gtids_compression_period值未使用的时候，MySQL的binlog轮换也会引起mysql.gtid_executed表的自动压缩。