复制状态与变量记录表,Mysql主从同步错误

原标题:复制状态与变量记录表 | 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)是以此职务甘休,所以刚刚错开,再往前一点就好
了。
因而那条命令见到日志时间是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
系统库下提供了如下多少个与复制状态相关的表(表含义详见本文后续小节):

  • 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 MASTELacrosse 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字段被分配了八个值,且SELANDVICE_STATE字段被改换为ON了,THREAD_ID字段值与show
    processlist语句中见到的线程id同样。 *
    假诺IO线程空闲或正在从主库接收binlog时,线程的SE奥迪Q7VICE_STATE值会一贯为ON,THREAD_ID线程记录线程ID值,假如IO线程正在品尝连接主库但还不曾中标建设构造连接时,THREAD_ID记录CONNECTING值,THREAD_ID字段记录线程ID,若是IO线程与主库的接连断开,恐怕主动甘休IO线程,则SERAV4VICE_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表记录一条WO翼虎KEKoleos_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字段记录有个别复制通道是还是不是需要实行延迟复制,即使是MGRubicon集群,则记录组复制从节点的推移复制配置参数),该表中的记录在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奥德赛集群,则该表中会记录类似如下MG中华V集群新闻

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)

# 假如是MGHighlander集群,则该表会记录如下MG奇骏集群新闻

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)

# 假如是MGLX570集群,则该表中会记录类似如下MG奥迪Q3集群音信

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表

要是从库是单线程,则该表记录一条WOEscortKE普拉多_ID=0的SQL线程的情形。如若从库是二十八线程,则该表记录系统参数slave_parallel_workers钦赐个数的职业线程状态(WO路虎极光KE奥迪Q3_ID从1开首编号),此时和煦器/SQL线程状态记录在replication_applier_status_by_coordinator表,每三个通道都有谈得来单独的做事线程和和睦器线程(每一种通道的行事线程个数由slave_parallel_workers参数变量钦命,若是是MGCR-V集群时,则该表中记录的工作线程记录为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)

# 即便是MGLAND集群,则该表中会记录类似如下MGRAV4集群信息

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线程状态产生变化,该表中的信息就能够产生修改(多主复制架构中,从库指向了稍稍个主库就能记录多少行记录。MGCRUISER集群架构中,各种节点有两条记下,但这两条记下并未有记录完整的组复制连接配置参数,举例: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)

# 即使是MG汉兰达集群,则该表中会记录类似如下MG昂Cora集群消息

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)

# 假使是MGLacrosse集群,则该表中会记录类似如下MG本田CR-V集群音信

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

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注