复制信息记录表|全方位认识 mysql 系统库

在上一期《时区信息记录表|全方位认识 mysql 系统库》中，我们详细介绍了mysql系统库中的时区信息记录表，本期我们将为大家带来系列第七篇《复制信息记录表|全方位认识 mysql 系统库》，下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧！

1、复制信息表概述

复制信息表用于在从库在复制主库的数据期间，用于保存从主库转发到从库的二进制日志事件、记录有关中继日志当前状态和位置的信息。 一共有三种类型的日志，如下：

• master.info文件或者mysql.slave_master_info表：用于保存从库的IO线程连接主库的连接状态、帐号、IP、端口、密码以及IO线程当前读取主库binlog的file和position等信息（被称为IO线程信息日志。默认情况下，IO线程的连接信息和状态保存在master.info文件中(默认位置在datadir下，可以使用master_info_file选项执行master.info文件路径)，如果需要保存在mysql.slave_master_info表中，需要在server启动之前设置master-info-repository = TABLE）。

• relay-log.info文件或者mysql.slave_relay_log_info表： 从库的IO线程从主库获取到最新的binlog事件信息会先写入到从库本地的relay log中，SQL线程再去读取relay log解析并重放，而relay_log.info文件或者mysql.slave_relay_log_info表就是用于记录最新的relay log的file和position以及SQL线程当前重放的事件对应主库binlog的file和position（relay log即被称为中继日志，SQL线程位置被称为SQL线程信息日志。默认情况下，relay log的位置信息和SQL线程的位置信息保存在relay-log.info文件中(默认位置在datadir下，可以使用relay_log_info_file选项执行relay-log.info文件路径)，如果需要保存在mysql.slave_relay_log_info表中，需要在server启动之前设置relay-log-info-repository = TABLE）。

设置relay_log_info_repository和master_info_repository设置为TABLE可以提高数据库本身或者所在主机意外终止之后crash recovery的能力（这两张表是innodb表，可以保证crash之后表中的位置信息不丢失），且可以保证数据一致性。

从库crash时，SQL线程可能还有一部分relay log重放延迟，另外，IO线程的位置也可能正处于一个事务的中间，并不完整，所以必须在从库上启用参数relay-log-recovery=ON，启用该参数之后，从库crash recovery时会清理掉SQL线程未重放完成的relay log，并以SQL线程的位置为准重置掉IO线程的位置重新从主库请求。

这两张表在数据库实例启动时如果无法被mysqld初始化，则mysqld允许继续启动，但会在错误日志中写入警告信息，这种情况在MySQL从不支持该表的版本升级到支持该表的版本时常常遇见。

PS：

• 不要尝试手动更新slave_master_info或slave_relay_log_info表，否则后果自负。

• 从库中复制线程在持续工作时，不允许任何可能对这两张表加写锁的语句执行，但允许对这两张表做只读的语句执行。

2、复制信息表详解

由于本期所介绍的表中存放的复制信息，在我们日常的数据库维护过程当中尤其重要，所以，下文中会在每张表的介绍过程中适度进行一些扩展。

2.1. slave_master_info

该表提供查询IO线程读取主库的位置信息，以及从库连接主库的IP、账号、端口、密码等信息。

下面是该表中存储的信息内容。

root@localhost : mysql 01:08:29> select * from slave_master_info\G;
*************************** 1. row ***************************
       Number_of_lines: 25
       Master_log_name: mysql-bin.000292
        Master_log_pos: 194
                  Host: 192.168.2.148
             User_name: qfsys
         User_password: letsg0
                  Port: 3306
         Connect_retry: 60
           Enabled_ssl: 0
                Ssl_ca:
            Ssl_capath:
              Ssl_cert:
            Ssl_cipher:
               Ssl_key:
Ssl_verify_server_cert: 0
             Heartbeat: 5
                  Bind:
    Ignored_server_ids: 0
                  Uuid: ec123678-5e26-11e7-9d38-000c295e08a0
           Retry_count: 86400
               Ssl_crl:
           Ssl_crlpath:
 Enabled_auto_position: 0
          Channel_name:
           Tls_version:
1 row in set (0.00 sec)

表字段与show slave status输出字段、master.info文件中的行信息对应关系及其表字段含义如下：

2.2. slave_relay_log_info

该表提供查询SQL线程重放的二进制文件对应的主库位置和relay log当前最新的位置。

下面是该表中存储的信息内容。

root@localhost : mysql 10:39:31> select * from slave_relay_log_info\G
*************************** 1. row ***************************
  Number_of_lines: 7
   Relay_log_name: /home/mysql/data/mysqldata1/relaylog/mysql-relay-bin.000205
    Relay_log_pos: 14097976
  Master_log_name: mysql-bin.000060
   Master_log_pos: 21996812
        Sql_delay: 0
Number_of_workers: 16
               Id: 1
     Channel_name:
1 row in set (0.00 sec)

表字段与show slave statu s输出字段、relay-log.info文件中的行信息对应关系及其表字段含义如下：

什么是中继日志：

• 中继日志(relay log)与二进制日志(binlog，即，binary log)中，保存的event数据是一样的(但中继日志中还保存了更多的信息)，也是由一组包含描述数据库变更的事件数据的文件组成，这些文件名后缀带连续编号，此外，还有一个包含所有正在使用的中继日志文件名称的索引文件。

• 中继日志中的数据存放格式与二进制日志相同，都可以使用mysqlbinlog命令来提取数据，默认情况下，中继日志保存在datadir下，文件名格式为： host_name-relay-bin.nnnnnn，其中host_name是从库服务器主机名，nnnnnn是文件后缀序列号。连续的中继日志文件从000001开始的连续序列号创建。使用索引文件来跟踪当前正在使用的中继日志文件。默认的中继日志索引文件名保存在datadir下，文件名格式为：host_name-relay-bin.index。

  * 中继日志文件和中继日志索引文件名称可分别使用--relay-log和--relay-log-index参数选项指定值覆盖默认值，如果文件名使用默认值，则要注意主机名称不能修改，否则会报无法打开中继日志的错误，建议使用参数选项指定固定的文件名称前缀。如果已经出现了这种情况发生报错了，那么需要修改index文件中的中继日志文件名和datadir下的中继日志文件名前缀为新的主机名，然后重启从库。

在什么情况下会产生新的中继日志文件。

• I/O线程启动时。

• 使用语句： FLUSH LOGS或mysqladmin flush-logs命令时。

• 当前中继日志文件的大小变得“太大”时，日志滚动规则如下：

  * 如果max_relay_log_size系统变量的值大于0，那么中继日志按照此参数指定的大小进行滚动。

  * 如果max_relay_log_size系统变量的值为0，则中继日志按照max_binlog_size系统变量指定的大小进行滚动。

SQL线程在执行完relay log之后，会自行决定何时清理掉这些已经执行完成的relay log文件，但如果使用FLUSH LOGS语句或mysqladmin flush-logs命令强制滚动中继日志时，SQL线程可能会同时清理掉已经执行完成的relay log文件。

2.3. slave_worker_info

该表提供查询多线程复制时的worker线程状态信息，与performance_schema.replication_applier_status_by_worker表的区别是： slave_worker_info表记录worker线程重放的relay log和主库binlog位置信息，而performance_schema.replication_applier_status_by_worker表记录的是worker线程重放的GTID位置信息。

下面是该表中存储的信息内容。

root@localhost : mysql 01:09:39> select * from slave_worker_info limit 1\G;
*************************** 1. row ***************************
                        Id: 1
            Relay_log_name:
             Relay_log_pos: 0
           Master_log_name:
            Master_log_pos: 0
 Checkpoint_relay_log_name:
  Checkpoint_relay_log_pos: 0
Checkpoint_master_log_name:
 Checkpoint_master_log_pos: 0
          Checkpoint_seqno: 0
     Checkpoint_group_size: 64
   Checkpoint_group_bitmap:
              Channel_name:
1 row in set (0.00 sec)

表字段含义。

• Id： 表中数据的ID，也是worker线程的ID，对应着performance_schema.replication_applier_status_by_worker表的WORKER_ID字段（如果复制停止，则该字段值仍然存在，不像performance_schema.replication_applier_status_by_worker表中THREAD_ID字段值会清空）。

• Relay_log_name： 每个worker线程当前最新执行到的relay log文件名。

• Relay_log_pos： 每个worker线程当前最新执行到的relay log文件中的position。

• Master_log_name： 每个worker线程当前最新执行到的主库binary log文件名。

• Master_log_pos： 每个worker线程当前最新执行到的主库binary log文件中的position。

• Checkpoint_relay_log_name： 每个worker线程最新检查点的relay log文件名。

• Checkpoint_relay_log_pos： 每个worker线程最新检查点的relay log文件中的position。

• Checkpoint_master_log_name： 每个worker线程最新检查点对应主库的binary log文件名。

• Checkpoint_master_log_pos： 每个worker线程最新检查点对应主库的binary log文件中的position。

• Checkpoint_seqno： 每个worker线程当前最新执行完成的事务号，这个事务号的大小值是相对于每个worker线程自己的最新检查点而言的，并不是真正的事务号。

• Checkpoint_group_size： 表示每个worker线程的执行队列大于这个字段值时，就会触发当前worker线程执行一次检查点。

• Checkpoint_group_bitmap： 用于从库crash之后recovery的关键值，它是一个位图值，表示每个worker线程在自己的最新检查点中已经执行的事务。

• Channel_name： 复制通道名称，多主复制时，显示指定的复制通道名称，单主复制时该字段为空。

---

该表中记录的内容对从库多线程复制crash recovery至关重要，所以下文对该表中记录的内容如何作用于crash recovery过程进行一些必要的说明。

---

从库多线程复制如何做复制分发。

• 我们知道在MySQL 5.7中加入了基于事务的并行复制(基于行)，主库在binlog的GTID事件中新加入了last_commit和sequence_number标记，用于表示在每个binlog中的每个group中的提交顺序(每个binlog中重置这两个计数标记)，在每个给定的binlog中，每个group中的last_commit总是为上一个group中最大的sequence_number、总是为当前group中最小的sequence_number - 1(在每个binlog中，last_commit总是从0开始计数，sequence_number总是从1开始计数)。

• 从库relay log中记录的主库binlog，不会改变主库的server id、时间戳信息以及last_commit和sequence_number值，这样，从库SQL线程在执行binlog重放时，就可以依据这些信息决定从库是否需要严格按照主库提交顺序进行提交（从库重放的事务只是分发顺序按照主库提交顺序，但是从库自己在提交这些事务时是否按照主库提交顺序进行提交，还需要看从库自己的slave_preserve_commit_order变量设置，设置为1则严格按照relay log中的顺序进行提交，设置为0从库会自行决定提交顺序）。

• SQL线程并行分发原理。

  * SQL协调器线程读取到一个新的事务，取出last_commit和sequence_number值。

  * SQL协调器线程判断取出的新事务的当前last_commit是否大于当前已执行完成的sequence_number中的最小值（Low water mark，简称LWM，也叫低水位线标记）。

  * 如果SQL协调器线程读取到的当前事务的last_commit大于当前已执行完成的sequence_number值，则说明上一个group中的事务还没有全部执行完成，此时SQL协调器线程需要等待所有的worker线程执行完成上一个group中的事务，等待LWM变大，直到当前读取到的事务的last_commit与当前已执行完成的事务的最小sequence_number值相等才可以继续分发新的事务给空闲的worker线程（并行复制是针对每个group内的事务才可以并行复制，所以，group之间是串行的，一个group未执行完成之前，下一个group的事务是需要进行等待的。 只有同一个group内的事务之间才可以并行执行。根据上文中的描述，每个group中的事务的last_commit总是为当前group中最小的sequence_number - 1，即，如果SQL协调器线程读取到的当前事务的last_commit小于当前已执行完成事务的最小的sequence_number 就说明当前所有worker线程正在执行的事务处于同一个group中，那么也就是说SQL协调器线程可以继续往下寻找空闲的worker线程进行分发，否则SQL协调器线程就需要进行等待）。

  * SQL协调器线程通过统计worker线程返回的状态信息，寻找一个空闲的worker线程，如果没有空闲的线程，则SQL协调器线程需要进行等待，知道找到一个空闲的worker线程为止（如果有多个worker线程，则SQL协调器线程随机选择一个空闲的worker线程进行分发）。

  * 将当前读取到的事务的binlog event分发给选定的空闲worker线程，之后worker线程会去应用这个事务，然后SQL协调器线程继续读取新的binlog event（注意，SQL协调器线程分发是按照event为单位的，不是事务单位，所以，如果当一个事务的第一个event分发给了给定worker线程之后，后续读取到的新的event如果同属于一个事务，则进入下一个事务之前的所有event都会分发给同一个worker线程处理。 当一个事务中所有的binlog event组分发完成，读取到下一个新的事务时，SQL协调器线程会重复以上判断流程）。

从库多线程复制的crash recovery。

• 从前面多线程复制分发的原理我们可以知道，处于同一个group中的事务是并行应用的，且事务是随机分配的，在从库正常运行过程当中，如果任意掐一刻下去，那么所有worker线程正在执行的事务中，哪些是已经执行完成的，哪些还未执行完成其实是无法使用单个位置来确定（因为从库并行复制时有可能是乱序提交： 需要看slave_preserve_commit_order变量如何设置），也就是说所有worker线程中正在执行的最大位置和最小位置之间可能有断点。那MySQL是如何解决从库crash recovery的断点续做问题的呢？

• MySQL 为了解决这个问题，对worker线程的执行状态做了很多记录工作，首先，维护了一个队列，这个队列叫做GAQ（Group Assigned Queue），当SQL协调器线程在分配某一个事务时，首先会将这个事务加入到这个队列，然后，才会去按照规则来寻找一个空闲的worker线程来执行，如下图（郑重声明： 该图来自书籍《MySQL 运维内参》）：

  

每一个事务在分发到worker线程之后，都会分配一个编号，这个编号在某一段时间内，都是相对固定的，这个编号一旦被分配，就不会再改变。 在事务被某个worker线程执行完成之后，它的位置信息就会被flush一次，这与5.5版本中的relay_log_info记录的原理是类似的（relay_log_info中存放了从库当前SQL线程重放的位置），但是现在是多线程，每个worker线程的执行位置不能直接存放在relay_log_info中了，relay_log_info中存放的是所有worker线程汇总之后的位置，每个worker线程独立的位置信息存放在了mysql.slave_worker_info表中，在该表中，有多少个并行复制线程，就有多少行记录（如果是多主复制，则每个复制通道都有slave_parallel_workers变量指定的记录数）。

mysql.slave_worker_info表中，Checkpoint开头的字段记录了每个worker线程的检查点相关的信息（这里与innodb存储引擎的检查点不同，但是概念相通），worker线程的检查点的作用是什么呢？

• 前面说了SQL协调器线程在分配事务给worker线程之前会将事务先存放到GAQ队列中，但是这个队列的长度是有限的（是不是很熟悉？ 跟redo log的总大小是有限的概念类似），不可能无限制的增长下去，所以必须要在这个队列中，找到一个位置点，这个位置点就是GAQ的起点位置，这个位置点之前的binlog就表示已经执行完成了。确定这个位置的过程，就叫做检查点。在多线程复制的执行过程中，随着每个worker线程不断第应用事务的binlog，检查点在GAQ中被不断地向前推进，每个worker线程通过Checkpoint_point_bitmap字段记录自己已经执行过的事务和每个已执行事务与之对应的当时的最新检查点的相对位置，这样一来，当复制意外终端之后，重新开始复制时，就可以通过所有的worker线程记录的Checkpoint_point_bitmap字段来计算出哪些事务是已经执行过的，哪些事务是还未执行的，即通过所有worker线程记录的Checkpoint_point_bitmap信息执行一次检查点操作就可以找到一个合适的恢复位置，执行检查点的大概过程如下（注意：这里是执行检查点的过程，与从库crash recovery过程无关）：

  * 在GAQ队列中，从尾部开始扫描，如果是已经执行过的事务，则直接将其从队列中删除。

  * 持续扫描GAQ队列，直到找到一个未执行过的事务为止即停止扫描。

  * 上述步骤中扫描动作停止前扫描到的最后一个事务被确定为检查点的最新位置，并且别标记为LWM（低水位线标记）。

  * 将当前LWM这个事务对应的位置(master_log_pos和relay_log_pos位置)设置为此次检查点对应的位置。

  * 通过所有的worker线程检查自己的检查点，也就是查看每个worker线程自己的Checkpoint_seqno字段值，这个字段值是每个worker线程在执行事务提交时更新的，更新的字段值为每个worker线程在做事务提交时对应的最新检查点的相对位置。

  * 将本次执行检查点的位置记录到mysql.slave_relay_log_info表中，作为全局bin log应用的位置。

• 现在，我们来看从库crash recovery的过程：

  * 首先，读取mysql.slave_master_info、mysql.slave_relay_log_info、mysql.slave_worker_info表中的信息读取出来，从mysql.slave_master_info表中找到连接主库的信息，从mysql.slave_relay_log_info表中找到全局最新的复制位置以及worker线程个数，从mysql.slave_worker_info表中找到每一个worker线程对应的复制信息位置。

  * 然后，根据mysql.slave_relay_log_info表中的位置（这个位置就是全局最新的检查点位置）为准来判断所有worker线程的位置，在这个位置之前的worker线程位置就表示已经执行过的了，直接剔除，在这个位置之后的worker线程位置就表示这些事务是还没有执行过的（根据每个worker线程在mysql.slave_worker_info表中记录的Checkpoint_seqno和Checkpoint_group_bitmap字段计算出自己哪些事务没有执行过，然后通过每个worker线程在mysql.slave_worker_info表中记录的其他checkpoint字段信息转换为对应的全局检查点的位置。 然后根据所有worker线程的转换位置信息汇总为一个共同的bitmap，根据这个共同的bitmap来比对mysql.slave_relay_log_info表中的位置就可以提取出哪些事务还没有执行过），找出了哪些事务还没有执行之后，把这些事务串行地一个一个地去重新应用（应用一个更新一次mysql.slave_relay_log_info表，为什么要串行，这是为了在恢复过程中如果再次跪了，还可以正确地恢复位置），应用完成之后清空mysql.slave_worker_info表。然后启动复制线程，继续从主库拉取最新的binlog进行数据复制。

PS： 如果在主从复制架构中，有2个以上的从库，且从库永远不做提升主库的操作时，可以使用如下方法优化从库延迟（在该场景下，从库无需担心数据丢失问题，因为有另外一个从库兜底+不做主从切换，只需要专心提供快速应用主库binlog与只读业务即可）。

• 关闭log_slave_updates参数，减少从库binlog写入量（如果不做级联复制甚至可以同时关闭binlog）。

• 设置innodb_flush_log_at_trx_commit为0或者2，减少事务提交时redo log的等待频率。

• 设置sync_binlog为默认值或者更大的值，减少事务提交时binlog的等待频率。

• 设置slave_preserve_commit_order参数为OFF（默认为OFF，设置为ON时要求开启binlog和log_slave_updates参数），减少事务严格按照主库顺序提交时的提交等待时间。

2.4. gtid_executed

前面介绍的三张表中，存放的都不包括GTID信息，在数据库运行过程中，GTID相关的信息是保存在performance_schema下的相关表中，详见"全方位认识 performance_schema"系列文章《复制状态与变量记录表 | performance_schema全方位介绍》。 但是performance_schema下的表都是内存表，记录的信息是易失的。gtid_executed表才是GTID信息的持久表，该表提供查询与当前实例中的数据一致的GTID集合（该表用于存储所有事务分配的 GTID集合，GTID集合由UUID集合构成，每个UUID集合的组成为：uuid:interval[:interval]...，例如 ：28b13b49-3dfb-11e8-a76d-5254002a54f2:1-600401, 3ff62ef2-3dfb-11e8-a448-525400c33752:1-110133）

• GTID是在整个复制拓扑中是全局唯一的，GTID中的事务号是一个单调递增的无间隙数字。 正常情况下，客户端的数据修改在执行commit时会分配一个GTID，且会记录到binlog中，这些GTID通过复制组件在其他实例中进行重放时也会保留GTID来源不变。但是如果客户端自行使用sql_log_bin变量关闭了binlog记录或者客户端执行的是一个只读事务，那么server不会分配GTID，在binlog中也不会有GTID记录。

• 当某个从库接受到自己的GTID集合中已经包含的GTID时，会忽略这个已存在的GTID，并且不会报错，事务也不会被执行。

从MySQL 5.7.5开始，GTID存储在mysql数据库的名为gtid_executed的表中。 对于每个GTID集合，默认情况下值记录每个GTID集合的起始和结束的事务号对应的GTID，该表只在数据库初始化或者执行update_grade升级的时候创建，不允许手工创建于修改。当实例本身有客户端访问数据写入或者有从其他主库通过复制插件同步数据的时候，该表中会有新的GTID记录写入，另外，该表中的记录还会在binlog滚动或者实例重启的时候被更新（日志滚动时该表需要把除了最新的binlog之外其他binlog中的所有GTID结合记录到该表中，实例重启时，需要把所有的binlog中的GTID集合记录到该表中）。

由于有mysql.gtid_executed表记录GTID（避免了binlog丢失的时候丢失GTID历史记录），所以，从5.7.5版本开始，在复制拓扑中的从库允许关闭binlog，也允许在binlog开启的情况下关闭log_slave_updates变量。

由于GTID必须要再gtid_mode为ON或者为ON_PERMISSIVE时才会生成，所以自然该表中的记录也需要依赖于gtid_mode变量为ON或ON_PERMISSIVE时才会进行记录，另外，该表中是否实时存储GTID，取决于binlog日志是否开启，或者binlog启用时是否启用log_slave_updates变量，如下：

• 当禁用二进制日志记录（log_bin为OFF），或者启用binlog但禁用log_slave_updates，则Server会在每个事物提交时把属于该事物的GTID同时更新到该表中。 此时，该表的GTID周期性自动压缩功能激活，每达到gtid_executed_compression_period系统变量指定的事物数量压缩一次该表中的GTID集合(也就是把每个UUID对应的事务号的记录取一个最大值，取一个最小值，删除中间值)，要注意：周期性自动压缩功能仅针对从库，对主库无效，因为主库必须启用binlog，且log_slave_updates参数不影响主库。

• 如果启用二进制日志记录（log_bin为ON）且log_slave_updates参数也启用，则周期性自动压缩功能失效，该表中的记录只会在binlog日志滚动或者服务器关闭时才会进行压缩，且会把除了最后一个binlog之外，其他所有binlog中包含的GTID集合写入该表中。

• 注意：

  * 如果启用二进制日志记录（log_bin为ON）且log_slave_updates参数也启用，那么该表不会实时记录GTID，也就是说，完整的GTID集合，有一部分记录在该表中，有一部分是记录在binlog中的，如果一旦server发生crash，那么在crash recovery时会读取binlog中最新的GTID集合并合并到该表中。

  * 该表中的记录在执行reset master语句时会被清空。

该表中的记录周期性执行压缩示例。

# 假设表中有如下实时记录的GTID记录
mysql> SELECT * FROM mysql.gtid_executed;
+ -------------------------------------- + ---------- ------ + -------------- +
| source_uuid | interval_start | interval_end |
| -------------------------------------- + ---------- ------ + -------------- |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 37 | 37 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 38 | 38 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 39 | 39 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 40 | 40 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 41 | 41 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 42 | 42 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 43 | 43 |
...
# 那么，每达到gtid_executed_compression_period变量定义的事务个数时，激活压缩功能，GTID被压缩为一行记录，如下
+ -------------------------------------- + ---------- ------ + -------------- +
| source_uuid | interval_start | interval_end |
| -------------------------------------- + ---------- ------ + -------------- |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 37 | 43 |
...
# 注意：当gtid_executed_compression_period系统变量设置为0时，周期性自动压缩功能失效，你需要预防该表被撑爆的风险

表字段含义。

• source_uuid： 代表数据来源的GTID集合。

• interval_start： 每个UUID集合的最小事务号。

• interval_end： 每个UUID集合的最大事务号。

对该表的压缩功能由名为 thread/sql/compress_gtid_table 的专用前台线程执行。 该线程使用SHOW PROCESSLIST无法查看，但它可以在performance_schema.threads表中查看到(线程 thread/sql/compress_gtid_table 大多数时候都处于休眠状态，直到每满gtid_executed_compression_period个事务之后，该线程被唤醒以执行前面所述的对mysql.gtid_executed表的压缩。然后继续进入睡眠状态，直到下一次满gtid_executed_compression_period个事务，然后被唤醒再次执行压缩，以此类推，无限重复此循环。但如果当关闭binlog或者启用binlog但关闭log_slave_updates变量时，gtid_executed_compression_period变量被设置为了0，那么意味着该线程会始终处于休眠状态且永不会唤醒)，如下所示：

mysql> SELECT * FROM performance_schema.threads WHERE NAME LIKE '%gtid%'\G
*************************** 1. row ***************************
          THREAD_ID: 26
               NAME: thread/sql/compress_gtid_table
               TYPE: FOREGROUND
     PROCESSLIST_ID: 1
   PROCESSLIST_USER: NULL
   PROCESSLIST_HOST: NULL
     PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: Daemon
   PROCESSLIST_TIME: 1509
  PROCESSLIST_STATE: Suspending
   PROCESSLIST_INFO: NULL
   PARENT_THREAD_ID: 1
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: NULL
       THREAD_OS_ID: 18677

2.5. ndb_binlog_index

该表提供查询ndb集群引擎相关的统计信息，由于国内较少使用NDB存储引擎，这里不做过多介绍，有兴趣的朋友可自行研究。

本期内容就介绍到这里，本期内容参考链接如下：

https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-concepts.html#replication-gtids-gtid-executed-table

"翻过这座山，你就可以看到一片海！ "。 坚持阅读我们的"全方位认识 mysql 系统库"系列文章分享，你就可以系统地学完它。 谢谢你的阅读，我们下期不见不散！

| 作者简介

罗小波·沃趣科技高级数据库技术专家

IT从业多年，主要负责MySQL 产品的数据库支撑与售后二线支撑。曾参与版本发布系统、轻量级监控系统、运维管理平台、数据库管理平台的设计与编写，熟悉MySQL体系结构，Innodb存储引擎，喜好专研开源技术，多次在公开场合做过线下线上数据库专题分享，发表过多篇数据库相关的研究文章。