-
Notifications
You must be signed in to change notification settings - Fork 111
replication_applier_status_by_worker
xiaoboluo768 edited this page Jun 8, 2020
·
2 revisions
- 如果从库是单线程,则该表记录应用/SQL线程的状态。如果从库是多线程,则该表记录工作线程的状态。协调器/SQL线程状态记录在replication_applier_status_by_coordinator表,每一个通道都有自己独立的工作线程和协调器线程
- replication_applier_status_by_worker表各字段含义及与show slave status输出字段对应关系如下:
replication_applier_status_by_worker表列名 | 含义 | 对应show slave status输出字段名 |
---|---|---|
CHANNEL_NAME | 显示复制通道名称 | Channel_Name |
WORKER_ID | 该通道下在该表中的工作线程标识符(与mysql.slave_worker_info表中的工作线程id列值相同),按照数值范围1~slave_parallel_workers系统参数定义的值,依次编号(如slave_parallel_workers定义为4,则就会产生1,2,3,4这几个WORKER_ID)。当执行STOP SLAVE宇航局之后,THREAD_ID列变为NULL,但WORKER_ID值不会发生变化 | 无 |
THREAD_ID | 该通道下工作线程ID | 无 |
SERVICE_STATE | 该通道下工作线程的状态,有效值有:ON(工作线程存在且处于活跃状态或空闲状态)或OFF(工作线程不再存在,可能没有启动) | 无 |
LAST_SEEN_TRANSACTION | 该通道下工作线程最后看到的事务。即工作线程正在执行的事务号。如果gtid_mode系统变量值为OFF,则此列为ANONYMOUS,表示事务不具有全局事务标识符(GTID);如果gtid_mode为ON,则此列值可能有几种情况:如果工作线程从启动复制以来一直处于空闲状态,则该列为空串。如果工作线程正在执行事务,则此列值总是显示正在执行的事务的GTID。如果工作线程执行过事务,后续再处于空闲状态,则一直保留最后一个执行的事务GTID号,直到下一个事务被分配到该工作线程时进行更新GTID值。如果工作线程在应用事务时发生错误,则此列值是发生错误时该工作线程正确执行完成的最后一个事务的GTID值;注:任何一个工作线程发生错误,会被协调器线程捕获,然后该通道下的所有工作线程都会被停止掉 | 无 |
LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE | 该通道下从库SQL/工作线程发生错误停止的最新错误号和错误消息。如果错误编号为0,错误信息字段为空串,则表示“无错误”。如果LAST_ERROR_MESSAGE字段值不为空,则错误值也会打印在从库的错误日志中,注意,在执行RESET MASTER或RESET SLAVE语句时这两个列值会被重置 | 从库使用单线程时对应Last_SQL_Errno,Last_SQL_Error,从库使用多线程时在show slave status输出中不显示,这俩字段显示协调器工作线程的错误编号和错误信息 |
LAST_ERROR_TIMESTAMP | 该通道下从库SQL/工作线程发生错误的时间,时间格式为:YYMMDD HH:MM:SS | Last_SQL_Error_Timestamp |
-
对于replication_applier_status_by_worker表,不允许执行TRUNCATE TABLE语句
-
表记录内容示例
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-00 00:00:00 |
| | 3 | 46 | ON | | 0 | | 0000-00-00 00:00:00 |
| | 4 | 47 | ON | | 0 | | 0000-00-00 00:00:00 |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
4 rows in set (0.00 sec)
- 表结构定义
CREATE TABLE `replication_applier_status_by_worker` (
`CHANNEL_NAME` char(64) NOT NULL,
`WORKER_ID` bigint(20) unsigned NOT NULL,
`THREAD_ID` bigint(20) unsigned DEFAULT NULL,
`SERVICE_STATE` enum('ON','OFF') NOT NULL,
`LAST_SEEN_TRANSACTION` char(57) NOT NULL,
`LAST_ERROR_NUMBER` int(11) NOT NULL,
`LAST_ERROR_MESSAGE` varchar(1024) NOT NULL,
`LAST_ERROR_TIMESTAMP` timestamp NOT NULL
) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8
上一篇: replication_applier_status_by_coordinator表 | 下一篇: replication_connection_configuration表
- 验证、测试、整理:罗小波
- QQ:309969177
- 提示:本系列文章的主体结构遵循Oracle MySQL 官方 5.7 手册中,关于information_schema、mysql schema、performance_schema、sys schema的章节结构体系,并额外添加了一些验证、测试数据。鉴于本人精力和能力有限,难免出现一些纰漏,欢迎大家踊跃指正!