原标题：复制状态与变量记录表 | performance_schema全方位介绍（六）
server_id是必须设置在master和每个slave上的唯一标识ID，其取值范围
是1~4294967295之间，且同一个复制组之内不能重复
server_uuid:server_uuid会在GTID复制中使用。当MySQL启动之后，会
首先到数据文件目录下的auto.cnf中寻找是否有指定的server_uuid,如果没有找到,则自己生成一个server_uuid并保存到这个文件中
server_id是必须设置在master和每个slave上的唯一标识ID，其取值范围
是1~4294967295之间，且同一个复制组之内不能重复
server_uuid:server_uuid会在GTID复制中使用。当MySQL启动之后，会
首先到数据文件目录下的auto.cnf中寻找是否有指定的server_uuid,如果没有找到,则自己生成一个server_uuid并保存到这个文件中
log_slave_updates:该参数用来控制是否将收到的主库的更新数据的语句也记录在slave自己的bin
log中。正常情况下是不需要记录的，但如果是想 创建级联复制关系，比如A
-> B -> C，这其中B既要作为A的从库，也要作
为C的主库，则需要既开启log-bin参数，也要开启log_slave_updates参数
relay-log:该参数用来指定relay-log文件的基础名称，默认的名称为
host_name-relay-bin.xxxx，其中的xxxx结尾是依次递增的数字
log_slave_updates:该参数用来控制是否将收到的主库的更新数据的语句也记录在slave自己的bin
log中。正常情况下是不需要记录的，但如果是想 创建级联复制关系，比如A
-> B -> C，这其中B既要作为A的从库，也要作
为C的主库，则需要既开启log-bin参数，也要开启log_slave_updates参数
relay-log:该参数用来指定relay-log文件的基础名称，默认的名称为
host_name-relay-bin.xxxx，其中的xxxx结尾是依次递增的数字
出品 沃趣科技
replicate-do-db:该参数用来指定需要复制的数据库。
在基于语句复制的环境中，指定该参数之后，则slave的SQL
thread进程只会应用在本数据库下的对象相关的语句。如果有多个数据库需要复制，则这
个参数要使用多次。但如果是涉及到跨库操作语句，则复制会丢失，比如:
replicate-do-db=sales
replicate-do-db:该参数用来指定需要复制的数据库。
在基于语句复制的环境中，指定该参数之后，则slave的SQL
thread进程只会应用在本数据库下的对象相关的语句。如果有多个数据库需要复制，则这
个参数要使用多次。但如果是涉及到跨库操作语句，则复制会丢失，比如:
replicate-do-db=sales
IT从业多年，历任运维工程师，高级运维工程师，运维经理，数据库工程师，曾参与版本发布系统，轻量级监控系统，运维管理平台，数据库管理平台的设计与编写，熟悉MySQL的体系结构时，InnoDB存储引擎，喜好专研开源技术，追求完美。
USE prices;
UPDATE sales.january SET amount=amount+1000;
USE prices;
UPDATE sales.january SET amount=amount+1000;
不知不觉中，performance_schema系列快要接近尾声了，今天将带领大家一起踏上系列第六篇的征程(全系共6个篇章)，在这一期里，我们将为大家全面讲解performance_schema中的复制状态与变量统计表。下面，请跟随我们一起开始performance_schema系统的学习之旅吧～
在基于行复制的环境中，只要数据库对象是指定的库，则复制都能正常,比如上述update语句由于january表是属于sales库的，则slave会复制并应用 ，同样下面的语句在基于行复制的环境中也不会执行:
在基于行复制的环境中，只要数据库对象是指定的库，则复制都能正常,比如上述update语句由于january表是属于sales库的，则slave会复制并应用 ，同样下面的语句在基于行复制的环境中也不会执行:
01
USE sales;
UPDATE prices.march SET amount=amount-25;
USE sales;
UPDATE prices.march SET amount=amount-25;
复制信息统计表
在slave的my.cnf上设置replicate-do-db=test，重启mysql
在slave的my.cnf上设置replicate-do-db=test，重启mysql
通常，DBA或相关数据库运维人员在查看从库的复制相关的信息，都习惯性的使用show slave status语句查看。也许你会说，我也会用performance_schema下的表查看一些复制报错信息什么的。但是，你知道show slave status语句、mysql系统库下的复制信息记录表、performance_schema系统库下的复制信息记录表之间有什么区别吗？不知道？别急，本文即将为你详细介绍show slave status语句与performance_schema系统库下的复制信息记录表的区别（mysql系统库下的复制表区别详见后续 "mysql系统库全方位介绍"系列）。
在语句复制环境下查看对指定数据库的修改操作:
在语句复制环境下查看对指定数据库的修改操作:
在开始详细介绍每一张复制信息表之前，我们先花费一些篇幅来整体认识一下这些表。
[mysqld]
binlog-format=statement
主库上执行:
mysql> use test;
mysql> update test2.temp set name='ddd';
mysql> use test2;
mysql> update test.temp set name='eee';
在从库上查看复制结果:
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from temp;
-- 虽然是指定的同步数据库但并没有同步
+------+------+
| id | name |
+------+------+
| 1|abc|
| 2|abc|
| 3|abc|
| 4|abc|
| 5|abc|
+------+------+
mysql> use test2;
mysql> select * from temp;
+------+------+
| id | name |
+------+------+
|10|ddd|
|11|ddd|
|12|ddd|
##虽然不是指定的同步数据库但数据有同步
[mysqld]
binlog-format=statement
主库上执行:
mysql> use test;
mysql> update test2.temp set name='ddd';
mysql> use test2;
mysql> update test.temp set name='eee';
在从库上查看复制结果:
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from temp;
-- 虽然是指定的同步数据库但并没有同步
+------+------+
| id | name |
+------+------+
| 1|abc|
| 2|abc|
| 3|abc|
| 4|abc|
| 5|abc|
+------+------+
mysql> use test2;
mysql> select * from temp;
+------+------+
| id | name |
+------+------+
|10|ddd|
|11|ddd|
|12|ddd|
##虽然不是指定的同步数据库但数据有同步
performance_schema 系统库下提供了如下几个与复制状态相关的表（表含义详见本文后续小节）：
在行复制环境下查看对指定数据库的修改操作:
mysql> show variables like '%binlog_format%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW |
+---------------+-------+
主库上执行:
mysql> use test;
mysql> update test2.temp set name='bcd';
mysql> use test2;
mysql> update test.temp set name='abc';
在从库上查看复制结果:
mysql> use test;
mysql> select * from temp; ##数据已复制
+------+------+
| id | name |
+------+------+
| 1|abc|
| 2|abc|
| 3|abc|
| 4|abc|
| 5|abc|
+------+------+
mysql> use test2;
mysql> select * from temp; ##数据未复制
+------+------+
| id | name |
+------+------+
| 10 | aa |
| 11 | bb |
| 12 | cc |
+------+------+
另一个基于SQL语句复制和基于行复制的区别在于当语句中包含对多个数据库的表进行 操作时。比如设置replicate-do-db=db1,
USE db1;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
基于SQL语句的复制会将table1和table2都在备库修改，而基于行的复制只会在备库修改 table1表
USE db4;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
而对于上述语句来说，基于SQL语句的复制不会在备库修改任何表，而基于行的复制会 在备库修改table1表 如果希望跨库的update语句在多个库上都起作用，可以使用replicate-do- table=db_name.tbl_name
replicate-ignore-db:该参数决定了忽略指定数据库的复制，其行为和replicate-do-db
正好相反
replicate-do-table=db_name.tbl_name:通过该参数告知slave的SQL
thread仅复制指 定表上的数据。如果有多个表，则该参数要使用多次
replicate-ignore-table=db_name.tbl_name:通过该参数告知slave的SQL
thread将指 定表上的数据过滤掉
replicate-wild-do-table=db_name.tbl_name:通过该参数告知SQL的SQL
thread仅复
制符合匹配的表，可以使用_和%作为通配符。比如replicate-wild-do-
table=foo%.bar%表示复制以foo打头的数据库下所有bar打头的表数据。如果是
replicate-wild-do-table=foo%.%,则表示即复制foo打头的所有表的数据，也复制
create/drop/alter database foo打头的命令
replicate-wild-ignore-table=db_name.tbl_name:通过该参数告知SQL的SQL
thread 过滤掉符合匹配的表
设置replicate-do-table参数，重启mysql:
[mysqld]
replicate-do-db=test
replicate-do-table=test.temp
slave-parallel-workers: 该参数决定了slave上启动多个SQL
thread线程来并行应用数据的。默认值是0代表不允许并行，取值范围可以是0~1024
[mysqld] slave-parallel-workers=5
skip-slave-start
:该参数决定了在MySQL启动时是否先不启动slave线程，即暂停复 制
[mysqld]
skip-slave-start=1
slave-parallel-type=type
:该参数决定了当启动了并行之后，采用什么粒度的并行方
式。默认值database表示按照不同的数据库执行并行，LOGICAL_CLOCK则表示按照
在binlog中的一组提交的事务作为并行粒度
slave-skip-errors=[err_code1,err_code2,...|all|ddl_exist_errors]:该参数决定了当slave的SQL
thread执行过程中碰到何种错误时可以忽略并继续接下来的数据复制。正常情况下当有错误发生时，复制会停止而需要人工干预修复才能继续进行。除非非常自信可以忽略某些错误，否则不要使用这个参数，不然会导致虽然复制执行正常，但其实内部的数据已经完全不一致
sql_slave_skip_counter代表在非GTID复制环境下，通过设置此参数来跳过多少个复制事件。
设置完该参数并非立即生效，而是要等待下次start
slave命令的执行生效，并将该参数再次设 置为0
log-bin[=base_name]:该参数表示是否开启binary
log。默认情况下MySQL会使用
host_name-bin.xxxx作为文件的名字，其中xxxx是以数字递增的后缀。如果该参数指定了
base_name，则二进制文件会以base_name.xxxx来命名
binlog-do-db=db_name: 该参数决定了哪些库下的修改会被记录到bin
log中。其行为与
replicate-do-db类型，在基于SQL语句复制的环境下，只记录在当前数据库下的修改。比如指
定binlog-do-db=sales，一下语句不会被记录到bin log中:
USE prices;
UPDATE sales.january SET amount=amount+1000;
而以下语句则会被记录到bin log中:
USE sales; UPDATE prices.discounts SET percentage = percentage + 10;
而基于行复制的环境下，只有属于指定数据的语句才会被记录到bin log中。比如下面的语句会被记录:
USE prices;
UPDATE sales.february SET amount=amount+100;
-- 而下面的语句则不会被记录:
USE sales;
UPDATE prices.march SET amount=amount-25;
-- 针对跨库的语句来说，行为和replicate-do-db相同
binlog-ignore-db=db_name:该参数决定了在bin log中忽略的数据库，其行为与
replicate-ignore-db类型
binlog_format:该参数决定了bin
log中记录的格式，可以是statement,row,mixed，分别
代表基于SQL语句的复制，基于行复制和基于混合复制。在5.7.7版本之前的默认设置是
statement，在5.7.7及以后，则默认是row。当设置为混合模式时，则优先使用statement，
只有当基于语句的复制无法保证复制的准确时会自动替换为row
检查复制状态方法
SHOW SLAVE STATUSG
Slave_IO_State: -- 代表当前slave的状态
Slave_IO_Running: -- 代表负责读取主库bin log的IO线程是否是运行状态，正常情况下应 该是YES
Slave_SQL_Running: -- 代表负责执行备库relay log的SQL线程是否是运行状态，正常情 况下应该是YES
Last_IO_Error, Last_SQL_Error: -- 分别代表最后一次IO线程和SQL线程所发生的错误， 正常情况下应该是空代表没有错误
Seconds_Behind_Master: -- 代表备库的SQL线程比主库的bin log晚多少秒。0代表目前 没有复制延迟
(Master_Log_file, Read_Master_Log_Pos): -- 表示IO线程在主库bin log中的坐标位置
(Relay_Master_Log_File, Exec_Master_Log_Pos): -- 表示SQL线程在主库bin log中的坐 标位置
(Relay_Log_File, Relay_Log_Pos): -- 表示SQL线程在备库relay log中的坐标位置
在主库可以通过执行show processlist命令查看主库的bin log日志生成进程
mysql> SHOW PROCESSLIST G;
*************************** 4. row ***************************
Id: 10
User: root
Host: slave1:58371
db: NULL
Command: Binlog Dump
Time: 777
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL
在行复制环境下查看对指定数据库的修改操作:
mysql> show variables like '%binlog_format%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW |
+---------------+-------+
主库上执行:
mysql> use test;
mysql> update test2.temp set name='bcd';
mysql> use test2;
mysql> update test.temp set name='abc';
在从库上查看复制结果:
mysql> use test;
mysql> select * from temp; ##数据已复制
+------+------+
| id | name |
+------+------+
| 1|abc|
| 2|abc|
| 3|abc|
| 4|abc|
| 5|abc|
+------+------+
mysql> use test2;
mysql> select * from temp; ##数据未复制
+------+------+
| id | name |
+------+------+
| 10 | aa |
| 11 | bb |
| 12 | cc |
+------+------+
另一个基于SQL语句复制和基于行复制的区别在于当语句中包含对多个数据库的表进行 操作时。比如设置replicate-do-db=db1,
USE db1;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
基于SQL语句的复制会将table1和table2都在备库修改，而基于行的复制只会在备库修改 table1表
USE db4;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
而对于上述语句来说，基于SQL语句的复制不会在备库修改任何表，而基于行的复制会 在备库修改table1表 如果希望跨库的update语句在多个库上都起作用，可以使用replicate-do- table=db_name.tbl_name
replicate-ignore-db:该参数决定了忽略指定数据库的复制，其行为和replicate-do-db
正好相反
replicate-do-table=db_name.tbl_name:通过该参数告知slave的SQL
thread仅复制指 定表上的数据。如果有多个表，则该参数要使用多次
replicate-ignore-table=db_name.tbl_name:通过该参数告知slave的SQL
thread将指 定表上的数据过滤掉
replicate-wild-do-table=db_name.tbl_name:通过该参数告知SQL的SQL
thread仅复
制符合匹配的表，可以使用_和%作为通配符。比如replicate-wild-do-
table=foo%.bar%表示复制以foo打头的数据库下所有bar打头的表数据。如果是
replicate-wild-do-table=foo%.%,则表示即复制foo打头的所有表的数据，也复制
create/drop/alter database foo打头的命令
replicate-wild-ignore-table=db_name.tbl_name:通过该参数告知SQL的SQL
thread 过滤掉符合匹配的表
设置replicate-do-table参数，重启mysql:
[mysqld]
replicate-do-db=test
replicate-do-table=test.temp
slave-parallel-workers: 该参数决定了slave上启动多个SQL
thread线程来并行应用数据的。默认值是0代表不允许并行，取值范围可以是0~1024
[mysqld] slave-parallel-workers=5
skip-slave-start
:该参数决定了在MySQL启动时是否先不启动slave线程，即暂停复 制
[mysqld]
skip-slave-start=1
slave-parallel-type=type
:该参数决定了当启动了并行之后，采用什么粒度的并行方
式。默认值database表示按照不同的数据库执行并行，LOGICAL_CLOCK则表示按照
在binlog中的一组提交的事务作为并行粒度
slave-skip-errors=[err_code1,err_code2,...|all|ddl_exist_errors]:该参数决定了当slave的SQL
thread执行过程中碰到何种错误时可以忽略并继续接下来的数据复制。正常情况下当有错误发生时，复制会停止而需要人工干预修复才能继续进行。除非非常自信可以忽略某些错误，否则不要使用这个参数，不然会导致虽然复制执行正常，但其实内部的数据已经完全不一致
sql_slave_skip_counter代表在非GTID复制环境下，通过设置此参数来跳过多少个复制事件。
设置完该参数并非立即生效，而是要等待下次start
slave命令的执行生效，并将该参数再次设 置为0
log-bin[=base_name]:该参数表示是否开启binary
log。默认情况下MySQL会使用
host_name-bin.xxxx作为文件的名字，其中xxxx是以数字递增的后缀。如果该参数指定了
base_name，则二进制文件会以base_name.xxxx来命名
binlog-do-db=db_name: 该参数决定了哪些库下的修改会被记录到bin
log中。其行为与
replicate-do-db类型，在基于SQL语句复制的环境下，只记录在当前数据库下的修改。比如指
定binlog-do-db=sales，一下语句不会被记录到bin log中:
USE prices;
UPDATE sales.january SET amount=amount+1000;
而以下语句则会被记录到bin log中:
USE sales; UPDATE prices.discounts SET percentage = percentage + 10;
而基于行复制的环境下，只有属于指定数据的语句才会被记录到bin log中。比如下面的语句会被记录:
USE prices;
UPDATE sales.february SET amount=amount+100;
-- 而下面的语句则不会被记录:
USE sales;
UPDATE prices.march SET amount=amount-25;
-- 针对跨库的语句来说，行为和replicate-do-db相同
binlog-ignore-db=db_name:该参数决定了在bin log中忽略的数据库，其行为与
replicate-ignore-db类型
binlog_format:该参数决定了bin
log中记录的格式，可以是statement,row,mixed，分别
代表基于SQL语句的复制，基于行复制和基于混合复制。在5.7.7版本之前的默认设置是
statement，在5.7.7及以后，则默认是row。当设置为混合模式时，则优先使用statement，
只有当基于语句的复制无法保证复制的准确时会自动替换为row
检查复制状态方法
SHOW SLAVE STATUSG
Slave_IO_State: -- 代表当前slave的状态
Slave_IO_Running: -- 代表负责读取主库bin log的IO线程是否是运行状态，正常情况下应 该是YES
Slave_SQL_Running: -- 代表负责执行备库relay log的SQL线程是否是运行状态，正常情 况下应该是YES
Last_IO_Error, Last_SQL_Error: -- 分别代表最后一次IO线程和SQL线程所发生的错误， 正常情况下应该是空代表没有错误
Seconds_Behind_Master: -- 代表备库的SQL线程比主库的bin log晚多少秒。0代表目前 没有复制延迟
(Master_Log_file, Read_Master_Log_Pos): -- 表示IO线程在主库bin log中的坐标位置
(Relay_Master_Log_File, Exec_Master_Log_Pos): -- 表示SQL线程在主库bin log中的坐 标位置
(Relay_Log_File, Relay_Log_Pos): -- 表示SQL线程在备库relay log中的坐标位置
在主库可以通过执行show processlist命令查看主库的bin log日志生成进程
mysql> SHOW PROCESSLIST G;
*************************** 4. row ***************************
Id: 10
User: root
Host: slave1:58371
db: NULL
Command: Binlog Dump
Time: 777
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL
- replication_applier_configuration
- replication_applier_status
- replication_applier_status_by_coordinator
- replication_applier_status_by_worker
- replication_connection_configuration
- replication_connection_status
- replication_group_member_stats
- replication_group_members
这些复制表中记录的信息生命周期如下(生命周期即指的是这些表中的信息什么时候写入，什么时候会被修改，什么时候会被清理等）：
- 在执行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相同。 * 如果IO线程空闲或正在从主库接收binlog时，线程的SERVICE_STATE值会一直为ON，THREAD_ID线程记录线程ID值，如果IO线程正在尝试连接主库但还没有成功建立连接时，THREAD_ID记录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两个表）中记录的信息。如果需要清理内存里报错的复制信息，需要使用RESET SLAVE ALL;语句
- 注意：对于replication_applier_status_by_worker、replication_applier_status_by_coordinator表（以及mysql.slave_wroker_info表）来说，如果是以单线程复制运行，则replication_applier_status_by_worker表记录一条WORKER_ID=0的记录，replication_applier_status_by_coordinator表与mysql.slave_wroker_info表为空(使用多线程复制，该表中才有记录)。即，如果slave_parallel_workers系统变量大于0，则在执行START SLAVE时这些表就被填充相应多线程工作线程的信息
performance_schema 系统库中保存的复制信息与SHOW SLAVE STATUS输出的信息有所不同（performance_schema 中记录的一些复制信息是show slave status语句输出信息中没有的，但是也仍然有一些show slave status语句输出的复制信息是performance_schema 中没有的），因为这些表面向全局事务标识符（GTID）使用，而不是基于binlog pos位置，所以这些表记录server UUID值，而不是server ID值。show slave status语句输出的信息在performance_schema 中缺少的内容如下：
用于引用binlog file、pos和relay log file、pos等信息选项，在performance_schema表中不记录 。
PS1：如下系统状态变量被移动到了这些复制状态表中进行记录(MySQL 5.7.5版之前使用以下状态变量查看）：
- Slave_retried_transactions
- Slave_last_heartbeat
- Slave_received_heartbeats
- Slave_heartbeat_period
- Slave_running
PS2：对于组复制架构，组复制的监控信息散布在如下几张表中
- replication_group_member_stats
- replication_group_members
- replication_applier_status
- replication_connection_status
- threads
通过以上内容，我们从整体上能够大致了解了performance_schema中的复制信息表记录了什么信息，下面依次详细介绍这些复制信息表。
1.replication_applier_configuration表
该表中记录从库线程延迟复制的配置参数（延迟复制的线程被称为普通线程，比如CHANNEL_NAME和DESIRED_DELAY字段记录某个复制通道是否需要执行延迟复制，如果是MGR集群，则记录组复制从节点的延迟复制配置参数），该表中的记录在Server运行时可以使用CHANGE MASTER TO语句进行更改，我们先来看看表中记录的统计信息是什么样子的。
# 如果是单主或多主复制，则该表中会为每个复制通道记录一条类似如下信息
admin@localhost : performance_schema 02:49:12> select * from replication_applier_configuration;
+--------------+---------------+
| CHANNEL_NAME |DESIRED_DELAY |
+--------------+---------------+
|| 0 |
+--------------+---------------+
1row inset ( 0. 00sec)
# 如果是MGR集群，则该表中会记录类似如下MGR集群信息
root@localhost : performance_schema 10:56:49> select * from replication_applier_configuration;
+----------------------------+---------------+
| CHANNEL_NAME |DESIRED_DELAY |
+----------------------------+---------------+
|group_replication_applier | 0 |
| group_replication_recovery |0|
+----------------------------+---------------+
2 rows inset (0.00 sec)
表中各字段含义及与show slave status输出字段对应关系如下：
对于replication_applier_configuration表，不允许执行TRUNCATE TABLE语句。
2. replication_applier_status表
该表中记录的是从库当前的一般事务执行状态（该表也记录组复制架构中的复制状态信息）
- 此表提供了所有线程binlog重放事务时的普通状态信息。线程重放事务时特定的状态信息保存在replication_applier_status_by_coordinator表（单线程复制时该表为空）和replication_applier_status_by_worker表（单线程复制时表中记录的信息与多线程复制时的replication_applier_status_by_coordinator表中的记录类似）
我们先来看看表中记录的统计信息是什么样子的。
# 单线程复制和多线程复制时表中的记录相同，如果是多主复制，则每个复制通道记录一行信息
admin@localhost : performance_schema 02:49:28> select * from replication_applier_status;
+--------------+---------------+-----------------+----------------------------+
| CHANNEL_NAME |SERVICE_STATE | REMAINING_DELAY |COUNT_TRANSACTIONS_RETRIES |
+--------------+---------------+-----------------+----------------------------+
|| ON |NULL | 0 |
+--------------+---------------+-----------------+----------------------------+
1row inset ( 0. 00sec)
# 如果是MGR集群，则该表会记录如下MGR集群信息
root@localhost : performance_schema 10:58:33> select * from replication_applier_status;
+----------------------------+---------------+-----------------+----------------------------+
| CHANNEL_NAME |SERVICE_STATE | REMAINING_DELAY |COUNT_TRANSACTIONS_RETRIES |
+----------------------------+---------------+-----------------+----------------------------+
|group_replication_applier | ON |NULL | 0 |
| group_replication_recovery |OFF | NULL |0|
+----------------------------+---------------+-----------------+----------------------------+
2 rows inset (0.00 sec)
表中各字段含义及与show slave status输出字段对应关系如下：
对于replication_applier_status表，不允许执行TRUNCATE TABLE语句。
3. replication_applier_status_by_coordinator表
该表中记录的是从库使用多线程复制时，从库的协调器工作状态记录，当从库使用多线程复制时，每个通道下将创建一个协调器和多个工作线程，使用协调器线程来管理这些工作线程。如果从库使用单线程，则此表为空（对应的记录转移到replication_applier_status_by_worker表中记录），我们先来看看表中记录的统计信息是什么样子的。
# 单线程主从复制时，该表为空，为多线程主从复制时表中记录协调者线程状态信息，多主复制时每个复制通过记录一行信息
admin@localhost : performance_schema 02:49:50> select * from replication_applier_status_by_coordinator;
+--------------+-----------+---------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME |THREAD_ID | SERVICE_STATE |LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE |LAST_ERROR_TIMESTAMP |
+--------------+-----------+---------------+-------------------+--------------------+----------------------+
|| 43 |ON | 0 || 0000-00-00 00:00:00 |
+--------------+-----------+---------------+-------------------+--------------------+----------------------+
1row inset ( 0. 00sec)
# 如果是MGR集群，则该表中会记录类似如下MGR集群信息
root@localhost : performance_schema 11:00:11> select * from replication_applier_status_by_coordinator;
+---------------------------+-----------+---------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME |THREAD_ID | SERVICE_STATE |LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE |LAST_ERROR_TIMESTAMP |
+---------------------------+-----------+---------------+-------------------+--------------------+----------------------+
|group_replication_applier | 91 |ON | 0 || 0000-00-00 00:00:00 |
+---------------------------+-----------+---------------+-------------------+--------------------+----------------------+
1row inset ( 0. 00sec)
表中各字段含义及与show slave status输出字段对应关系如下：
对于replication_applier_status_by_coordinator表，不允许执行TRUNCATE TABLE语句。
4. replication_applier_status_by_worker表
如果从库是单线程，则该表记录一条WORKER_ID=0的SQL线程的状态。如果从库是多线程，则该表记录系统参数slave_parallel_workers指定个数的工作线程状态(WORKER_ID从1开始编号)，此时协调器/SQL线程状态记录在replication_applier_status_by_coordinator表，每一个通道都有自己独立的工作线程和协调器线程（每个通道的工作线程个数由slave_parallel_workers参数变量指定，如果是MGR集群时，则该表中记录的工作线程记录为slave_parallel_workers个group_replication_applier线程+1个group_replication_recovery线程），我们先来看看表中记录的统计信息是什么样子的。
# 单线程主从复制时表中记录的内容如下
root@localhost : performance_schema 12:46:10> select * from replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME |WORKER_ID | THREAD_ID |SERVICE_STATE | LAST_SEEN_TRANSACTION |LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE |LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
|| 0 |82| ON || 0 || 0000-00-00 00:00:00 |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
1row inset ( 0. 00sec)
# 多线程主从复制时表中的记录内容如下（如果是多主复制，则每个复制通道记录slave_parallel_workers参数指定个数的worker线程信息）
admin@localhost : performance_schema 02:50:18> select * from replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME |WORKER_ID | THREAD_ID |SERVICE_STATE | LAST_SEEN_TRANSACTION |LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE |LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
|| 1 |44| ON || 0 || 0000-00-00 00:00:00 |
| |2| 45 |ON | |0| |0000- 00- 0000:00:00|
|| 3 |46| ON || 0 || 0000-00-00 00:00:00 |
| |4| 47 |ON | |0| |0000- 00- 0000:00:00|
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
4 rows inset (0.00 sec)
# 如果是MGR集群，则该表中会记录类似如下MGR集群信息
root@localhost : performance_schema 11:00:16> select * from replication_applier_status_by_worker;
+----------------------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
|CHANNEL_NAME | WORKER_ID |THREAD_ID | SERVICE_STATE |LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER |LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+----------------------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
| group_replication_recovery |0| NULL |OFF | |0| |0000- 00- 0000:00:00|
|group_replication_applier | 1 |92| ON |aaaaaaaa-aaaa-aaaa-aaaa- aaaaaaaaaaaa:104099082| 0 || 0000-00-00 00:00:00 |
| group_replication_applier |2| 93 |ON | |0| |0000- 00- 0000:00:00|
......
+----------------------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
17 rows inset (0.00 sec)
表中各字段含义及与show slave status输出字段对应关系如下：
对于replication_applier_status_by_worker表，不允许执行TRUNCATE TABLE语句。
5. replication_connection_configuration表
该表中记录从库用于连接到主库的配置参数，该表中存储的配置信息在执行change master语句时会被修改
- 与replication_connection_status表相比，replication_connection_configuration更改频率更低。因为它只包含从库连接到主库的配置参数，在连接正常工作期间这些配置信息保持不变的值，而replication_connection_status中包含的连接状态信息，只要IO线程状态发生变化，该表中的信息就会发生修改（多主复制架构中，从库指向了多少个主库就会记录多少行记录。MGR集群架构中，每个节点有两条记录，但这两条记录并未记录完整的组复制连接配置参数，例如：host等信息记录到了replication_group_members表中）。
我们先来看看表中记录的统计信息是什么样子的。
# 单线程、多线程主从复制时表中记录的内容相同，如果是多主复制，则每个复制通道各自有一行记录信息
admin@localhost : performance _schema 02:51:00> select * from replication_connection_configurationG;
*************************** 1. row ***************************
CHANNEL_NAME:
本文由牛彩彩票官网发布于牛彩技术,转载请注明出处：MySQL复制相关变量，performance_schema全方位介绍