replication tables

• 在performance_schema库下的replication_开头的几个表提供了复制状态的详细信息，这与SHOW SLAVE STATUS查看到的一些复制状态信息类似，但是这些信息是保存在表里，更易于访问和保存

  • SHOW SLAVE STATUS的输出信息用于肉眼检查比较方便，但对于把这些复制状态信息获取出来复制给程序变量使用就比较麻烦，相比之下，使用表保存复制状态信息，可以使用SELECT语句查询（还可以使用一些复杂的WHERE条件，以及join连接查询等）来查询需要的复制信息。
  • 对于多线程从库，SHOW SLAVE STATUS语句的Last_SQL_Errno和Last_SQL_Error字段表明了所有协调器和工作线程的错误汇总，只有最近一次发生的错误才会显示在这里，也就是说，如果不是最后一次的报错信息，则可能会丢失。而采用表存储，则每个协调器线程或者工作线程的错误都会各自保存一行数据，自己记录自己的信息，不会出现show slave status语句输出信息时的尴尬。
  • 在replication_applier_status_by_worker表中，所有线程都有一个字段LAST_SEEN_TRANSACTION来记录从库中最后一个事务是多少，即所有的工作线程都可以看到最后一个事务，而show slave status语句不提供这样的信息。

• performance_schema下提供了如下几个与复制状态相关的表：

  • 记录有关从库与主库连接信息的表：
    • replication_connection_configuration：从库连接主库的配置参数，一个主库一条记录（多源复制时从库指向了多少个主库就会记录多少行记录）
    • replication_connection_status：从库与主库的复制线程连接状态，主从之间的复制线程就是指的IO线程
  • 记录有关延迟复制事务时的应用线程（非worker线程）信息的表，要注意的是，延迟复制也是使用协调器线程和worker线程来重放，这两个表只是为了避免与即时重放的事务及其相关状态混淆，单独拧出来做记录用：
    • replication_applier_configuration：从库上的延迟复制事务使用的应用线程（被称为普通线程）配置参数，比如CHANNEL_NAME和DESIRED_DELAY字段记录某个复制通道是否需要执行延迟复制
    • replication_applier_status：从库上的延迟复制事务应用线程的当前状态
  • 记录协调器线程和worker线程应用主库binlog的状态信息表（被称为特殊线程）：
    • replication_applier_status_by_coordinator：协调器线程的状态（单线程复制时为空，启用了多线程复制时，一个主库一行记录，如果还启用了多源复制，则每个channel会有一行记录，因为每个channel都会有一个自己的协调器）
    • replication_applier_status_by_worker：如果从库启用了多线程复制，则该表记录应用线程或者说工作线程的状态，需要注意的是，从库slave_parallel_workers配置参数设置的数字多少，则每个主库都会记录多少行记录，多源复制时，每个channel都会记录slave_parallel_workers指定行数的记录，因为每个channel都有自己独立的工作线程，即，该表记录的工作线程记录行数为：channel_number * slave_parallel_workers
  • 记录有关复制组成员信息的表(组复制拓扑中会用到)：
    • replication_group_members：记录组成员网络和状态信息。
    • replication_group_member_stats：记录有关组成员参与事务的统计信息

• 这些复制表中记录的信息生命周期如下(生命周期即指的是这些表中的信息什么时候写入，什么时候会被修改，什么时候会被清理等）：

  • 在执行CHANGE MASTER TO之前，这些表是空的
  • 执行CHANGE MASTER TO之后，在配置参数表replication_applier_configuration和replication_connection_configuration中可以查看到配置信息了。此时，由于并没有启动复制，所以表中THREAD_ID列为NULL，SERVICE_STATE列的值为OFF（这两个字段存在与表replication_applier_status、replication_applier_status_by_coordinator、replication_applier_status_by_worker、replication_connection_status几个表中）
  • 执行START SLAVE后，可以看到连接线程和协调器线程，工作线程状态表中的THREAD_ID字段被分配了一个值，且SERVICE_STATE字段被修改为ON了，THREAD_ID字段值与show processlist中看到的线程id不相同（可以通过performance_schema.threads表中查询两者的关联）。举个例子：如果IO线程空闲或正在从主库接收binlog时，线程的SERVICE_STATE值会一直为ON，THREAD_ID线程记录线程ID值，如果IO线程正在尝试连接主库但还没有成功建立连接时，SERVICE_STATE记录CONNECTING值，THREAD_ID字段记录线程ID，如果IO线程与主库的连接段考，或者主动停止IO线程，则SERVICE_STATE字段记录为OFF，THREAD_ID字段被修改为NULL
  • 执行 STOP SLAVE之后，所有复制IO和协调器、工作线程状态表中的THREAD_ID列变为NULL，SERVICE_STATE列的值变为OFF。注意：停止复制相关线程之后，这些记录并不会被清理 ，因为复制意外终止或者临时需要会执行停止操作，可能需要获取一些状态信息用于排错或者其他用途。
  • 执行RESET SLAVE之后，所有记录复制配置和复制状态的表中记录的信息都会被清除。但是show slave status语句还是能查看到一些复制状态和配置信息，因为该语句是从内存中获取，RESET SLAVE语句并没有清理内存，而是清理了磁盘文件、表（还包括mysql.slave_master_info和mysql.slave_relay_log_info两个表）中记录的信息。如果需要清理show slave status语句能查看到的内存信息，需要使用RESET SLAVE ALL;语句
  • 注意：对于replication_applier_status_by_worker表来说，如果是以单线程复制运行，则该表是空的，如果使用多线程复制，该表中才有记录，即，如果slave_parallel_workers系统变量大于0，则在执行START SLAVE时该表被填充相应工作线程的值

• Performance Schema复制表中的信息与SHOW SLAVE STATUS输出的信息有所不同（尽管这些表中记录的一些信息是show slave status语句输出信息中没有的，但是也仍然有一些show slave status语句输出的信息是这些表中没有的），因为这些表面向全局事务标识符（GTID）使用，而不是基于binlog pos位置，所以这些表记录server UUID值，而不是server ID值。前面已经经过这些表中记录了什么内容，现在列出show slave status语句输出的信息哪些是这些表中不记录的：

  • 以下show slave status输出字段值用于引用binlog file和pos，这些表中不记录：
    • MASTER_LOG_FILE
    • Read_Master_Log_Pos
    • RELAY_LOG_FILE
    • RELAY_LOG_POS
    • Relay_Master_Log_File
    • Exec_Master_Log_Pos
    • Until_Condition
    • Until_Log_File
    • Until_Log_Pos
  • show slave status输出字段Master_Info_File在这些表中不记录，它表示master.info文件路径，因为，如果master_info_repository设置为TABLE，则该文件中的信息被保存在mysql.slave_master_info表中，Master_Info_File字段也会显示mysql.slave_master_info字符串值
  • show slave status输出中以下字段是基于server_id使用，而不是server_uuid，所以不会被记录到这些表中：
    • Master_Server_Id
    • Replicate_Ignore_Server_Ids
  • show slave status输出中Skip_Counter字段是基于事件计数，而不是GTID，所以在这些表中不记录
  • show slave status输出中，以下字段是Last_SQL_Errno和Last_SQL_Error字段的别名，所以在这些表中不记录：
    • Last_Errno
    • Last_Error
    • 在performance_schema库中，replication_applier_status_by_coordinator表的LAST_ERROR_NUMBER和LAST_ERROR_MESSAGE列的值对应了Last_SQL_Errno和Last_SQL_Error字段值（如果从库为多线程复制，则具体的工作线程报错信息还需要查询表replication_applier_status_by_worker，这些表提供比Last_Errno和Last_Error字段更具体的错误信息）
  • show slave status输出中，以下用于复制过滤的字段在这些表中不记录：
    • Replicate_Do_DB
    • Replicate_Ignore_DB
    • Replicate_Do_Table
    • Replicate_Ignore_Table
    • Replicate_Wild_Do_Table
    • Replicate_Wild_Ignore_Table
  • show slave status输出中Slave_IO_State和Slave_SQL_Running_State字段在这些表中不记录。如果需要使用SELECT语句查询，可以使用对应复制状态表中的THREAD_ID列与INFORMATION_SCHEMA PROCESSLIST表中的ID列相关联，然后使用processlist表的STATE列作为select列执行join查询得到两个线程的状态值。如查询IO线程的状态值可以使用语句：select STATE,ID,pr.THREAD_ID from performance_schema.replication_connection_status as pr join information_schema.processlist as ip on pr.THREAD_ID - 41=ip.ID; 查询SQL线程的状态值，可以使用语句： select STATE,ID,pr.THREAD_ID from performance_schema.replication_applier_status_by_coordinator as pr join information_schema.processlist as ip on pr.THREAD_ID - 41=ip.ID;
    • 注：不知道为毛，replication_系列表中记录的线程ID值要比processlist的线程ID值大41，要先在join条件中把performance_schema表的线程ID字段减去41才能关联起来，估计是个BUG
  • show slave status输出中，Executed_Gtid_Set字段可以显示当前从库已有事务的GTID集合，在replication_applier_status_by_worker表中LAST_SEEN_TRANSACTION字段显示了每一个worker线程当前正在应用的事务GTID。gtid_executed系统变量也记录了与Executed_Gtid_Set字段相同的GTID集合值
  • show slave status输出中Seconds_Behind_Master和Relay_Log_Space字段在这些表中不记录

• 如下状态变量被移动到了这些复制状态表中进行记录，从MySQL 5.7.5版开始，以下状态变量（5.7.5版本之前使用SHOW STATUS进行查看）：

  • Slave_retried_transactions
  • Slave_last_heartbeat
  • Slave_received_heartbeats
  • Slave_heartbeat_period
  • Slave_running

• 参考链接：

  • https://dev.mysql.com/doc/refman/5.7/en/performance-schema-replication-tables.html
  • http://www.iteye.com/news/32090

• PS：对于组复制架构，组复制的监控信息散布在如下几张表中

  • replication_group_member_stats
  • replication_group_members
  • replication_applier_status
  • replication_connection_status
  • threads

---

上一篇： user_variables_by_thread表 | 下一篇： replication_applier_configuration表