复制信息记录表|全方位认识 mysql 系统库
在上一期《时区信息记录表|全方位认识 mysql 系统库》中，我们详细介绍了mysql系统库中的时区信息记录表，本期我们将为大家带来系列第七篇《复制信息记录表|全方位认识 mysql 系统库》，下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧！
1、复制信息表概述
复制信息表用于在从库在复制主库的数据期间，用于保存从主库转发到从库的二进制日志事件、记录有关中继日志当前状态和位置的信息。一共有三种类型的日志，如下：
设置itory和ry设置为TABLE可以提高数据库本身或者所在主机意外终止之后crash 的能力（这两张表是表，可以保证crash之后表中的位置信息不丢失），且可以保证数据一致性。
从库crash时，SQL线程可能还有一部分relay log重放延迟，另外，IO线程的位置也可能正处于一个事务的中间，并不完整，所以必须在从库上启用参数relay-log-=ON，启用该参数之后，从库crash 时会清理掉SQL线程未重放完成的relay log，并以SQL线程的位置为准重置掉IO线程的位置重新从主库请求。
这两张表在数据库实例启动时如果无法被初始化，则允许继续启动，但会在错误日志中写入警告信息，这种情况在MySQL从不支持该表的版本升级到支持该表的版本时常常遇见。
PS：
2、复制信息表详解
由于本期所介绍的表中存放的复制信息，在我们日常的数据库维护过程当中尤其重要，所以，下文中会在每张表的介绍过程中适度进行一些扩展。
2.1. 该表提供查询IO线程读取主库的位置信息，以及从库连接主库的IP、账号、端口、密码等信息。 下面是该表中存储的信息内容。
root@localhost : mysql 01:08:29> select * from slave_master_info\G;
*************************** 1. row ***************************Number_of_lines: 25Master_log_name: mysql-bin.000292Master_log_pos: 194Host: 192.168.2.148User_name: qfsysUser_password: letsg0Port: 3306Connect_retry: 60Enabled_ssl: 0Ssl_ca:Ssl_capath:Ssl_cert:Ssl_cipher:Ssl_key:
Ssl_verify_server_cert: 0Heartbeat: 5Bind:Ignored_server_ids: 0Uuid: ec123678-5e26-11e7-9d38-000c295e08a0Retry_count: 86400Ssl_crl:Ssl_crlpath:Enabled_auto_position: 0Channel_name:Tls_version:
1 row in set (0.00 sec)表字段与show slave 输出字段、文件中的行信息对应关系及其表字段含义如下： 文件中的行数mysql.表字段show slave 命令输出字段字段含义描述
[None]
表示中的信息行数或者表中的信息字段数
表示从库IO线程当前读取主库最新的 file名称
表示从库IO线程当前读取主库最新的
Host
表示从库IO线程当前正连接的主库IO或者主机名
表示从库IO线程用于连接主库用户名
[None]
表示从库IO线程用于连接主库的用户密码
Port
表示从库IO线程所连接主库的网络端口
表示从库IO线程断线重连主库的间隔时间，单位为秒，默认值为60
表示主从之间的连接是否支持SSL
10
表示CA( )认证文件名
11
表示CA( )认证文件路径
12
表示SSL认证证书文件名
13
表示用于SSL连接握手中可能使用到的密码列表
14
表示SSL认证的密钥文件名
15
rt
表示是否需要校验的证书
16
[None]
表示主从之间的复制心跳包的间隔时间，单位为秒
17
Bind
表示从库可用于连接主库的网络接口，默认为空
18
表示从库复制需要忽略哪些-id，注意：这是一个列表，第一个数字表示需要忽略的实例-id总数
19
Uuid
表示主库的UUID
20
表示从库最大允许重连主库的次数
21
[None]
SSL证书撤销列表文件的路径
22
[None]
包含ssl证书吊销列表文件的目录路径
23
n
表示从库是否启用在主库中自动寻找位置的功能（使用1时启动自动寻找位置，如果使用=0，则不会自耦东找位置）
24
表示从库复制通道名称，一个通道代表一个复制源
25
表示在上的TLS版本号
2.2. 该表提供查询SQL线程重放的二进制文件对应的主库位置和relay log当前最新的位置。 下面是该表中存储的信息内容。
root@localhost : mysql 10:39:31> select * from slave_relay_log_info\G
*************************** 1. row ***************************Number_of_lines: 7Relay_log_name: /home/mysql/data/mysqldata1/relaylog/mysql-relay-bin.000205Relay_log_pos: 14097976Master_log_name: mysql-bin.000060Master_log_pos: 21996812Sql_delay: 0
Number_of_workers: 16Id: 1Channel_name:
1 row in set (0.00 sec)
表字段与show slave 输出字段、文件中的行信息对应关系及其表字段含义如下： 文件中的行数mysql.表字段show slave 命令输出字段字段含义描述
[None]
表示中的信息行数或者表中的信息字段数，用于版本化表定义
表示当前最新的relay log文件名称
表示当前最新的relay log文件对应的最近一次完整接收的event的位置
e
表示SQL线程当前正在重放的中继日志对应的主库 文件名
表示SQL线程当前正在重放的中继日志对应主库 文件中的位置
表示延迟复制指定的从库必须延迟主库多少秒
[None]
表示从库当前并行复制有多少个线程
Id
[None]
用于内部唯一标记表中的每一行记录，目前总是1
表示从库复制通道名称，用于多源复制，一个通道对应一个主库源
什么是中继日志：
在什么情况下会产生新的中继日志文件。
SQL线程在执行完relay log之后，会自行决定何时清理掉这些已经执行完成的relay log文件，但如果使用FLUSH LOGS语句或 flush-logs命令强制滚动中继日志时，SQL线程可能会同时清理掉已经执行完成的relay log文件。
2.3. 该表提供查询多线程复制时的线程状态信息，与.表的区别是：表记录线程重放的relay log和主库位置信息，而.表记录的是线程重放的GTID位置信息。 下面是该表中存储的信息内容。
root@localhost : mysql 01:09:39> select * from slave_worker_info limit 1\G;
*************************** 1. row ***************************Id: 1Relay_log_name:Relay_log_pos: 0Master_log_name:Master_log_pos: 0Checkpoint_relay_log_name:Checkpoint_relay_log_pos: 0
Checkpoint_master_log_name:Checkpoint_master_log_pos: 0Checkpoint_seqno: 0Checkpoint_group_size: 64Checkpoint_group_bitmap:Channel_name:
1 row in set (0.00 sec)
表字段含义。 该表中记录的内容对从库多线程复制crash 至关重要，所以下文对该表中记录的内容如何作用于crash 过程进行一些必要的说明。 从库多线程复制如何做复制分发。
从库多线程复制的crash 。
每一个事务在分发到线程之后，都会分配一个编号，这个编号在某一段时间内，都是相对固定的，这个编号一旦被分配，就不会再改变。在事务被某个线程执行完成之后，它的位置信息就会被flush一次，这与5.5版本中的记录的原理是类似的（中存放了从库当前SQL线程重放的位置），但是现在是多线程，每个线程的执行位置不能直接存放在中了，中存放的是所有线程汇总之后的位置，每个线程独立的位置信息存放在了mysql.表中，在该表中，有多少个并行复制线程，就有多少行记录（如果是多主复制，则每个复制通道都有rs变量指定的记录数）。 mysql.表中，开头的字段记录了每个线程的检查点相关的信息（这里与存储引擎的检查点不同，但是概念相通），线程的检查点的作用是什么呢？ PS：如果在主从复制架构中，有2个以上的从库，且从库永远不做提升主库的操作时，可以使用如下方法优化从库延迟（在该场景下，从库无需担心数据丢失问题，因为有另外一个从库兜底+不做主从切换，只需要专心提供快速应用主库与只读业务即可）。
2.4. 前面介绍的三张表中，存放的都不包括GTID信息，在数据库运行过程中，GTID相关的信息是保存在下的相关表中，详见"全方位认识 "系列文章《复制状态与变量记录表 | 全方位介绍》。但是下的表都是内存表，记录的信息是易失的。表才是GTID信息的持久表，该表提供查询与当前实例中的数据一致的GTID集合（该表用于存储所有事务分配的 GTID集合，GTID集合由UUID集合构成，每个UUID集合的组成为：uuid:[:]...，例如 ：-3dfb-11e8-a76d-:1-,-3dfb-11e8-a448-:1-） 从MySQL 5.7.5开始，GTID存储在mysql数据库的名为的表中。对于每个GTID集合，默认情况下值记录每个GTID集合的起始和结束的事务号对应的GTID，该表只在数据库初始化或者执行升级的时候创建，不允许手工创建于修改。
当实例本身有客户端访问数据写入或者有从其他主库通过复制插件同步数据的时候，该表中会有新的GTID记录写入，另外，该表中的记录还会在滚动或者实例重启的时候被更新（日志滚动时该表需要把除了最新的之外其他中的所有GTID结合记录到该表中，实例重启时，需要把所有的中的GTID集合记录到该表中）。 由于有mysql.表记录GTID（避免了丢失的时候丢失GTID历史记录），所以，从5.7.5版本开始，在复制拓扑中的从库允许关闭，也允许在开启的情况下关闭变量。 由于GTID必须要再为ON或者为时才会生成，所以自然该表中的记录也需要依赖于变量为ON或时才会进行记录，另外，该表中是否实时存储GTID，取决于日志是否开启，或者启用时是否启用变量，如下： 该表中的记录周期性执行压缩示例。
# 假设表中有如下实时记录的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时，周期性自动压缩功能失效，你需要预防该表被撑爆的风险
表字段含义。 对该表的压缩功能由名为 /sql/ 的专用前台线程执行。该线程使用SHOW 无法查看，但它可以在.表中查看到(线程 /sql/ 大多数时候都处于休眠状态，直到每满个事务之后，该线程被唤醒以执行前面所述的对mysql.表的压缩。然后继续进入睡眠状态，直到下一次满个事务，然后被唤醒再次执行压缩，以此类推，无限重复此循环。但如果当关闭或者启用但关闭变量时，变量被设置为了0，那么意味着该线程会始终处于休眠状态且永不会唤醒)，如下所示：
mysql> SELECT * FROM performance_schema.threads WHERE NAME LIKE '%gtid%'\G
*************************** 1. row ***************************THREAD_ID: 26NAME: thread/sql/compress_gtid_tableTYPE: FOREGROUNDPROCESSLIST_ID: 1PROCESSLIST_USER: NULLPROCESSLIST_HOST: NULLPROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: DaemonPROCESSLIST_TIME: 1509PROCESSLIST_STATE: SuspendingPROCESSLIST_INFO: NULLPARENT_THREAD_ID: 1ROLE: NULLINSTRUMENTED: YESHISTORY: YESCONNECTION_TYPE: NULLTHREAD_OS_ID: 18677
2.5. 该表提供查询ndb集群引擎相关的统计信息，由于国内较少使用NDB存储引擎，这里不做过多介绍，有兴趣的朋友可自行研究。 本期内容就介绍到这里，本期内容参考链接如下： #-gtids-gtid--table
“
"翻过这座山，你就可以看到一片海！"。坚持阅读我们的"全方位认识 mysql 系统库"系列文章分享，你就可以系统地学完它。谢谢你的阅读，我们下期不见不散！
”
| 作者简介
罗小波·数据库技术专家
《千金良方——MySQL性能优化金字塔法则》、《数据生态：MySQL复制技术与生产实践》作者之一。
熟悉MySQL体系结构，擅长数据库的整体调优，喜好专研开源技术，并热衷于开源技术的推广，在线上线下做过多次公开的数据库专题分享，发表过近100篇数据库相关的研究文章。
全文完。
Enjoy MySQL:)
叶老师的「MySQL核心优化」大课已升级到MySQL 8.0，扫码开启MySQL 8.0修行之旅吧
