高级运维工程师

图片 12

原标题:复制状态与变量记录表 | performance_schema全方位介绍(六卡塔 尔(阿拉伯语:قطر‎

Coordinator stopped because there were error(s) in the worker(s). The
most recent failure being: Worker 2 failed executing transaction
‘ANONYMOUS’ at master log mysql-bin.005656, end_log_pos 4529152. See
error log and/or
performance_schema.replication_applier_status_by_worker table for
more details about this failure or others, if any.

图片 1

在从库中查看表performance_schema.replication_applier_status_by_worker
select * from
performance_schema.replication_applier_status_by_workerG

附加物 沃趣科学技术

*************************** 2. row
***************************
CHANNEL_NAME:
WORKER_ID: 2
THREAD_ID: NULL
SERVICE_STATE: OFF
LAST_SEEN_TRANSACTION: ANONYMOUS
LAST_ERROR_NUMBER: 1168
LAST_ERROR_MESSAGE: Worker 2 failed executing transaction ‘ANONYMOUS’
at master log mysql-bin.005656, end_log_pos 4529152; Error executing
row event: ‘Uerlying table which is differently defined or of non-MyISAM
type or doesn’t exist’
LAST_ERROR_TIMESTAMP: 2017-12-01 08:57:55

IT从业多年,历任运转技术员,高档运行程序员,运转高管,数据库技术员,曾参加版本发表种类,轻量级监察和控制体系,运行管理平台,数据库管理平台的筹算与编辑,熟知MySQL的类别布局时,InnoDB存款和储蓄引擎,喜好专研开源技巧,追求八面驶风。

去主库查找binlog日志,看看爆发了怎么业务(日志定位格局有一些挫卡塔尔国
mysqlbinlog –start-position=4529152 –stop-position=4539152
mysql-bin.005656 | more
那条命令是从4529152岗位上马,不过大家失误的职责(end_log_pos卡塔 尔(英语:State of Qatar)是那些职位截止,所以刚刚错开,再往前一点就好
了。
通过这条命令看见日志时间是2017-12-01 01:47:41,所以本人用了其余一条命令
mysqlbinlog –start-datetime=2017-12-01 01:47:41
–stop-datetime=2017-12-01 01:47:50 mysql-bin.005656 | more
找到日志:

无意中,performance_schema类别快要贴近尾声了,几近日将指点大家一同踏上聚众商量第六篇的征程(全系共6个篇章),在这里风流倜傥期里,大家将为大家体贴入妙授课performance_schema中的复制状态与变量总括表。上面,请跟随我们风度翩翩道在此以前performance_schema系统的就学之旅吧~

图片 2

01

image.png

复制消息计算表

翻开这些ID为332的这张表,开掘那张表是机关创立的,成立的时候从不点名存款和储蓄引擎,所以基本都出错了

通常,DBA或相关数据库运营人士在翻看从库的复制相关的消息,都习贯性的利用show
slave
status语句查看。只怕你会说,作者也会用performance_schema下的表查看一些复制报错音讯什么的。可是,你知道show
slave
status语句、mysql系统库下的复制音信记录表、performance_schema系统库下的复制新闻记录表之间有何界别吧?不知道?别急,本文将在为你详细介绍show
slave
status语句与performance_schema系统库下的复制音讯记录表的分别(mysql系统库下的复制表不同详见后续
“mysql系统库全方位介绍”连串卡塔 尔(阿拉伯语:قطر‎。

在始发详细介绍每一张复制新闻表以前,大家先费用一些篇幅来全部会认知识一下这一个表。

performance_schema
系统库下提供了之类多少个与复制状态相关的表(表含义详见本文后续小节卡塔 尔(英语:State of Qatar):

  • 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 MASTE陆风X8 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字段被分配了三个值,且SE揽胜VICE_STATE字段被涂改为ON了,THREAD_ID字段值与show
    processlist语句中来看的线程id相似。 *
    假如IO线程空闲或正在从主库选择binlog时,线程的SE哈弗VICE_STATE值会从来为ON,THREAD_ID线程记录线程ID值,倘若IO线程正在品尝连接主库但还没曾得逞建设构造连接时,THREAD_ID记录CONNECTING值,THREAD_ID字段记录线程ID,尽管IO线程与主库的接连几日断开,可能主动截止IO线程,则SE大切诺基VICE_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四个表卡塔 尔(英语:State of Qatar)中著录的新闻。假使急需清理内部存款和储蓄器里报错的复制音讯,供给使用RESET
    SLAVE ALL;语句
  • 注意:对于replication_applier_status_by_worker、replication_applier_status_by_coordinator表(以及mysql.slave_wroker_info表卡塔 尔(英语:State of Qatar)来讲,如若是以单线程复制运转,则replication_applier_status_by_worker表记录一条WO奥迪Q5KE福特Explorer_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
中并未有的卡塔 尔(英语:State of Qatar),因为那几个外部向全局专门的学业标志符(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字段记录有个别复制通道是还是不是须要实践延迟复制,假使是MGRAV4集群,则记录组复制从节点的延期复制配置参数卡塔 尔(阿拉伯语:قطر‎,该表中的记录在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)

# 要是是MG路虎极光集群,则该表中会记录相似如下MGKuga集群新闻

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输出字段对应关系如下:

图片 3

对于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)

# 若是是MG凯雷德集群,则该表会记录如下MG讴歌ZDX集群消息

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输出字段对应关系如下:

图片 4

对于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)

# 要是是MGENVISION集群,则该表中会记录相像如下MGLacrosse集群新闻

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输出字段对应关系如下:

图片 5

对于replication_applier_status_by_coordinator表,不一致敬履行TRUNCATE
TABLE语句。

4. replication_applier_status_by_worker表

假使从库是单线程,则该表记录一条WOGL450KE昂Cora_ID=0的SQL线程的场所。假若从库是八十九线程,则该表记录系统参数slave_parallel_workers内定个数的行事线程状态(WO哈弗KETiggo_ID从1方始编号),当时和谐器/SQL线程状态记录在replication_applier_status_by_coordinator表,每贰个通道都有温馨单独的劳作线程和和煦器线程(每一种通道的劳作线程个数由slave_parallel_workers参数变量钦赐,要是是MGENCORE集群时,则该表中著录的办事线程记录为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)

# 若是是名爵Evoque集群,则该表中会记录相像如下MGKoleos集群音信

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输出字段对应关系如下:

图片 6

图片 7

图片 8

图片 9

图片 10

对于replication_applier_status_by_worker表,区别意实践TRUNCATE
TABLE语句。

5. replication_connection_configuration表

该表中记录从库用于连接到主库的安顿参数,该表中存放的配置消息在施行change
master语句时会被改造

  • 与replication_connection_status表相比,replication_connection_configuration更正频率更低。因为它只包括从库连接到主库的配置参数,在连接平常专门的工作中间这么些配置消息保持不变的值,而replication_connection_status中含有的连年意况音讯,只要IO线程状态发生变化,该表中的音信就能发生校勘(多主复制架构中,从库指向了微微个主库就可以记录多少行记录。MG福睿斯集群框架结构中,每种节点有两条记下,但这两条记下并未记录完整的组复制连接配置参数,比方:host等消息记录到了replication_group_members表中)。

大家先来会见表中著录的总计消息是何等体统的。

#
单线程、八线程主从复制时表中著录的剧情千篇黄金时代律,借使是多主复制,则每一个复制通道分别有生机勃勃行记录音信

admin@localhost : performance _schema 02:51:00> select * from
replication_connection_configurationG;

*************************** 1. row
***************************

CHANNEL_NAME:

HOST: 10.10.20.14

PORT: 3306

USER: qfsys

NETWORK_INTERFACE:

AUTO_POSITION: 1

SSL_ALLOWED: NO

SSL _CA_FILE:

SSL _CA_PATH:

SSL_CERTIFICATE:

SSL_CIPHER:

SSL_KEY:

SSL _VERIFY_SERVER_CERTIFICATE: NO

SSL _CRL_FILE:

SSL _CRL_PATH:

CONNECTION _RETRY_INTERVAL: 60

CONNECTION _RETRY_COUNT: 86400

HEARTBEAT_INTERVAL: 5.000

TLS_VERSION:

1 row in set (0.00 sec)

# 假设是MGPRADO集群,则该表中会记录相仿如下名爵PRADO集群音讯

root@localhost : performance _schema 11:02:03> select * from
replication_connection_configurationG

*************************** 1. row
***************************

CHANNEL _NAME: group_replication_applier

HOST: <NULL>

……

*************************** 2. row
***************************

CHANNEL _NAME: group_replication_recovery

HOST: <NULL>

……

2 rows in set (0.00 sec)

表中各字段含义以致与change master
to语句的筛选对应关系如下:

图片 11

图片 12

注意:对于replication_connection_configuration表,不相同意实践TRUNCATE
TABLE语句。

6. replication_connection_status表

该表中著录的是从库IO线程的接连几天景况音信(也记录组复制架构中别的节点的连年音讯,组复制架构中二个节点参加集群早前的数据必要动用异步复制通道举行数据同步,组复制的异步复制通道新闻在show
slave
status中不可知卡塔尔国,大家先来拜会表中著录的总括音讯是何许样子的。

#
多线程和单线程主从复制时表中著录风流罗曼蒂克致,借使是多主复制,则每种复制通道在表中个记录风流倜傥行音信

root@localhost : performance _schema 12:55:26> select * from
replication_connection_statusG

*************************** 1. row
***************************

CHANNEL_NAME:

GROUP_NAME:

SOURCE_UUID: ec123678-5e26-11e7-9d38-000c295e08a0

THREAD_ID: 101

SERVICE_STATE: ON

COUNT _RECEIVED_HEARTBEATS: 136

LAST _HEARTBEAT_TIMESTAMP: 2018-06-12 00:55:22

RECEIVED _TRANSACTION_SET:

LAST _ERROR_NUMBER: 0

LAST _ERROR_MESSAGE:

LAST _ERROR_TIMESTAMP: 0000-00-00 00:00:00

1 row in set (0.00 sec)

# 如若是MGEnclave集群,则该表中会记录肖似如下MG奥迪Q5集群新闻

root@localhost : performance _schema 10:56:40> select * from
replication_connection_statusG

*************************** 1. row
***************************

CHANNEL _NAME: group_replication_applier

GROUP_NAME: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa

SOURCE_UUID: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa

THREAD_ID: NULL

SERVICE_STATE: ON

COUNT _RECEIVED_HEARTBEATS: 0

LAST _HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00

RECEIVED _TRANSACTION_SET:
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:104099082

LAST _ERROR_NUMBER: 0

LAST _ERROR_MESSAGE:

LAST _ERROR_TIMESTAMP: 0000-00-00 00:00:00

*************************** 2. row
***************************

CHANNEL _NAME: group_replication_recovery