快捷搜索:

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

日期:2019-06-20编辑作者:科技技术

原标题:复制状态与变量记录表 | 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 MASTE中华V 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时,线程的SESportageVICE_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八个表)中记录的新闻。假如急需清理内部存款和储蓄器里报错的复制消息,须要利用RESET SLAVE ALL;语句
  • 注意:对于replication_applier_status_by_worker、replication_applier_status_by_coordinator表(以及mysql.slave_wroker_info表)来讲,如若是以单线程复制运营,则replication_applier_status_by_worker表记录一条WO安德拉KE昂科威_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字段记录有个别复制通道是不是须要实施延迟复制,假使是MGENCORE集群,则记录组复制从节点的延迟复制配置参数),该表中的记录在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)

# 假诺是名爵Kuga集群,则该表中会记录类似如下MGPRADO集群音讯

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纳瓦拉集群,则该表会记录如下MGXC60集群消息

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)

# 即使是MG汉兰达集群,则该表中会记录类似如下MG中华V集群音信

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表

倘诺从库是单线程,则该表记录一条WO景逸SUVKESportage_ID=0的SQL线程的动静。假诺从库是多线程,则该表记录系统参数slave_parallel_workers钦赐个数的办事线程状态(WO奥迪Q5KETiguan_ID从1发端编号),此时协和器/SQL线程状态记录在replication_applier_status_by_coordinator表,每多个通路都有谈得来独自的劳作线程和和谐器线程(种种通道的干活线程个数由slave_parallel_workers参数变量钦定,假使是MGPRADO集群时,则该表中著录的办事线程记录为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)

# 假诺是MG冠道集群,则该表中会记录类似如下MG凯雷德集群新闻

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)

# 假使是MG卡宴集群,则该表中会记录类似如下MG陆风X8集群音信

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)

# 假诺是MGKoleos集群,则该表中会记录类似如下MG中华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

本文由澳门新葡8455手机版发布于科技技术,转载请注明出处:复制状态与变量记录表,Mysql主从同步错误

关键词: www.8455.com

X的出世是对科学和技术至美的最棒批注,X经历了

原标题:三个月时间,收获千万好评,OPPO Find X经历了你想象不到的困难 原标题:OPPO Find X的诞生是对科技至美的最佳...

详细>>

【www.8455.com】我不卖手机,黄章拿什么来拯救魅

原标题:魅族:我不卖手机,我只开发布会 离618越来越近,手机降价已经不是什么新鲜事,如果说哪款手机的价格还...

详细>>

凭啥让人一边骂一边买,这次和你聊聊历代背后

原标题:Samsung,凭啥令人一只骂一边买? U.S.A.太平洋大运 2005 年 1 月 9 日晚上,时任 Apple 老板 乔布斯在 Macworld大会...

详细>>

安排详解

原标题:配置详解 | performance_schema全方位介绍(二) MySQL Performance-Schema(一) 配置表,performanceschema       performance-...

详细>>