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

作者: 上市公司  发布:2019-09-08

admin@localhost : performance_schema 09:50:52> select * from variables_by_thread limit 5; # 可以看来比前边两张表多了个THREAD_ID 字段来记录线程ID

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.

IT从业多年,历任运转工程师,高档运转程序员,运营老董,数据库程序员,曾子舆与版本发表连串,轻量级监察和控制系统,运转处理平台,数据库管理平台的规划与编写制定,熟识MySQL的种类布局时,InnoDB存款和储蓄引擎,喜好专研开源技能,追求完善。

image.png

# 假如是MG库罗德集群,则该表中会记录类似如下MGXC90集群新闻

图片 1

COUNT_HOST_ACL_ERRORS: 0

去主库查找binlog日志,看看产生了哪些事情(日志定位格局有一点点挫)
mysqlbinlog --start-position=4529152 --stop-position=4539152 mysql-bin.005656 | more
那条命令是从4529154人置上马,不过我们失误的岗位(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
找到日志:

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

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

# status_by_user表

*************************** 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

# 单线程、十二线程主从复制时表中著录的内容同样,要是是多主复制,则每种复制通道分别有一行记录音信

查阅这些ID为332的那张表,开采那张表是机动创设的,创设的时候未有一点名存款和储蓄引擎,所以基本都出错了

+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+

1row inset ( 0. 00sec)

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

那么些复制表中著录的音讯生命周期如下(生命周期即指的是那一个表中的音讯什么日期写入,何时会被涂改,曾几何时会被清理等):

performance_schema记录系统变量的这么些表不援助TRUNCATE TABLE语句

RECEIVED _TRANSACTION_SET:

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

CONNECTION _RETRY_INTERVAL: 60

该表记录组复制架构中,组成员的网络和情状消息。仅在组复制组件运维时表中才会有记录,大家先来看看表中著录的总结消息是怎么样样子的。

+---------------------------+-----------+---------------+-------------------+--------------------+----------------------+

- END -回去腾讯网,查看更加的多

1 row in set (0.00 sec)

SSL _CRL_PATH:

1 row in set (0.00 sec)

|| 43 |ON | 0 || 0000-00-00 00:00:00 |

PS2:对此组复制架构,组复制的监督检查音信散播在如下几张表中

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

root@localhost : performance_schema 11:00:16> select * from replication_applier_status_by_worker;

+-----------+-------------------------+----------------+

大家先来拜见表中著录的总计新闻是哪些样子的。

COUNT _RECEIVED_HEARTBEATS: 0

LAST_SEEN: 2017 -12-3022 :35:29

表中各字段含义如下:

......

图片 2

COUNT_AUTH_PLUGIN_ERRORS: 0

复制新闻计算表

USER: qfsys

表中各字段含义如下:

SOURCE_UUID: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa

图片 3

7. replication_group_member_stats表

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

1row inset ( 0. 00sec)

+-----------+-------------------------+----------------+

| group_replication_applier |5d78a458- 30d2- 11e8-a66f- 5254002a54f2 | node1 |3306| ONLINE |

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

1 rowinset(0 .00sec)

17 rows inset (0.00 sec)

SSL_KEY:

表中各字段含义及与show slave status输出字段对应关系如下:

IP: 192 .168.2.122

GROUP_NAME:

图片 4

FIRST_SEEN: 2017 -12-3022 :34:51

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

2 rows in set (0.00 sec)

admin@localhost : performance_schema 09:50:40> select * from session_variables limit 5;

2 rows in set (0.00 sec)

+---------------------------+-----------+---------------+-------------------+--------------------+----------------------+

# 单线程主从复制时,该表为空,为二十多线程主从复制时表中记录协和者线程状态消息,多主复制时各类复制通过记录一行信息

  • global_variables:全局系统变量。只供给全局系统变量值的应用程序能够从该表中赢得
  • session_variables:当前对话的连串变量。只要求获得本身近期对话的系统变量值能够从该表中得到(注意,该表中隐含了无会话品级的全局变量值,且该表不记录已断开连接的种类变量)
  • variables_by_thread:依据线程ID为标志符记录的对话系统变量。想要在脚下线程中询问任何钦命线程ID的对话等级系统变量时,应用程序能够从该表中获取(注意,该表中仅包罗有对话级其他连串变量)

对于replication_applier_configuration表,不容许施行TRUNCATE TABLE语句。

PS:

......

大家先来拜谒表中著录的总结新闻是如何样子的。

THREAD_ID: 101

2d623f55-2111-11e8-9cc3-0025905b06da:1-2,

+-----------+-------------------------+--------------------------------------+

admin@localhost : performance_schema 02:50:18> select * from replication_applier_status_by_worker;

  • global_status:推行truncate会重新恢复设置线程、帐户、主机、客商相关的全局状态变量值,但不会复位一些尚无重新初始化的大局状态变量值,同期会影响到status_by_account表中的状态变量值
  • session_status:不扶助实践truncate语句
  • status_by_thread:将有着线程的气象变量值聚合到全局状态变量表(global_status)和帐户状态变量表(status_by_account),然后重新设置线程状态变量表。倘诺不访问帐户相关的总括消息,则会在status_by_user和status_by_host中单独访问主机和顾客的状态变量值,是不是收罗host,user,account的状态变量值,能够选取系统变量performance_schema_accounts_size,performance_schema_hosts_size和performance_schema_users_size在server运营从前分别张开安装,设置为0,则意味着不访问,大于0则意味要采摘(注意,那一个系统变量原来是用来调节accounts、hosts、users表中的行数,可是status_by_account,status_by_user,status_by_host中的account,user,host值是出自于accounts、hosts、users表,so…你懂的)

5 rows inset (0.00 sec)

+-----------+-------------------------+----------------+

+--------------+---------------+

2 rows inset (0.00 sec)

host_cache表保存连接到server的主机相关音信缓存,在那之中满含顾客机主机名和IP地址音信,能够用来防止DNS查找。该表能够应用SELECT语句进行查询,但须要在server运营此前开启performance_schema参数,不然表记录为空。

FLUSH STATUS将会话状态从具有移动会话增添到全局状态变量,然后重新恢复设置全数移动会话的状态变量值,并在依照account、host、user分类聚合表中重新初始化已断开连接的动静变量值。

02

COUNT _CONFLICTS_DETECTED: 0

8. replication_group_members表

+--------------+-----------+---------------+-------------------+--------------------+----------------------+

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

variables_by_thread表字段含义如下:

COUNT_ADDRINFO_PERMANENT_ERRORS: 0

SSL_ALLOWED: NO

+-----------+-----------------------------------------+----------------+

该表中记录了MySQL组复制作而成员的总结新闻。仅在组复制组件运维时表中才会有记录,我们先来探问表中记录的总括新闻是怎么样体统的。

+--------------+---------------+

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

| group_replication_recovery |OFF | NULL |0|

......

  • 此表提供了全体线程binlog重播事务时的一般性状态新闻。线程重播事务时特定的动静音讯保存在replication_applier_status_by_coordinator表(单线程复制时该表为空)和replication_applier_status_by_worker表(单线程复制时表中记录的新闻与四线程复制时的replication_applier_status_by_coordinator表中的记录类似)

该表中著录的是从库当前的貌似工作执生势况(该表也记录组复制架构中的复制状态消息)

+-------+-----------+-------------------------+----------------+

| CHANNEL_NAME |DESIRED_DELAY |

root@localhost : performance_schema 11:00:11> select * from replication_applier_status_by_coordinator;

05

1 row in set (0.00 sec)

|admin | Bytes_sent |306781|

COUNT_HANDSHAKE_ERRORS: 0

performance_schema提供了三个保留顾客定义变量的user_variables_by_thread表(该表也保留由mysql内部连接线程创造的变量)。那些变量是在一定会话中定义的变量,变量名由@字符最初。

+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+

| CHANNEL_NAME |DESIRED_DELAY |

图片 5

  • CHANNEL_NAME:组复制架构中使用的大道名称,通道名字为:group_replication_applier
  • MEMBER_ID:组复制架构中,组成员的ID,与组成员实例的server UUID相同
  • MEMBER_HOST:组复制架构中,组成员的互联网地址(主机名或IP地址,与成员实例的hostname或report_host系统变量的值一样)
  • MEMBER_PORT:组复制架构中,组成员的侦听端口,与组成员实例的port或report_port系统变量的值同样
  • MEMBER_STATE:组复制架构中,组成员的动静 有效状态如下: * OFFLINE:组复制作而成员已经安装组复制插件,但未运转 * RECOVERAV4ING:组复制作而成员已经投入到组复制架构中,正在从组中接收数据,即正在加入集群 * ONLINE:组复制成员处李晓明常运行情况 * PS:组复制框架结构中,假使组成员的组复制状态发生错误,不可能不奇怪从组中接收数据是,可能会产生ERRO库罗德状态。假若发生网络故障或然别的成员宕机,那么剩余存活的孤立节点的景况只怕会变为UNREACHABLE

......

COUNT _TRANSACTIONS_CHECKED: 0

HOST_VALIDATED: YES

......

|group_replication_applier | 91 |ON | 0 || 0000-00-00 00:00:00 |

一般来讲,DBA或有关数据库运维职员在查看从库的复制相关的新闻,都习贯性的运用show slave status语句查看。可能你会说,我也会用performance_schema下的表查看有的复制报错音讯什么的。可是,你理解show slave status语句、mysql系统库下的复制音信记录表、performance_schema系统库下的复制信息记录表之间有啥样差异呢?不清楚?别急,本文将要为你详细介绍show slave status语句与performance_schema系统库下的复制新闻记录表的分裂(mysql系统库下的复制表区别详见后续 "mysql系统库全方位介绍"种类)。

PS:

表中各字段含义

COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS: 0

CHANNEL _NAME: group_replication_recovery

| CHANNEL_NAME |WORKER_ID | THREAD_ID |SERVICE_STATE | LAST_SEEN_TRANSACTION |LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE |LAST_ERROR_TIMESTAMP |

| group_replication_recovery |0|

TRANSACTIONS _COMMITTED_ALL_MEMBERS: 0a1e8349-2e87-11e8-8c9f-525400bdd1f2:1-148826,

咱俩先来看看表中记录的总括消息是哪些样子的。

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

CHANNEL_NAME:

host_cache表

LAST_ERROR_SEEN: 2017 -12-3022 :34:51

无意中,performance_schema类别快要附近尾声了,明日将引导我们一齐踏上层层第六篇的道路(全系共6个篇章),在这一期里,大家将为我们关怀备至授课performance_schema中的复制状态与变量计算表。上边,请随行大家一道开首performance_schema系统的就学之旅吧~

+----------------------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+

COUNT _TRANSACTIONS_IN_QUEUE: 0

网编:

root@ localhost: performance_schema 10: 35: 47> select * from host_cacheG;

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

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

SSL _CA_FILE:

+-----------+-------------------------+--------------------------------------+

1row inset ( 0. 00sec)

COUNT_FCRDNS_ERRORS: 0

|| 0 |

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

+--------------+---------------+

# 假如是名爵福特Explorer集群,则该表中会记录类似如下MGKoleos集群新闻

|admin | Bytes_received |6177|

2 rows inset (0.00 sec)

+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+

......

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

对于replication_group_member_stats表,不允许实施TRUNCATE TABLE语句。

|auto_increment_increment | 2 |

COUNT_LOCAL_ERRORS: 0

+----------------------------+---------------+

LAST _ERROR_NUMBER: 0

user_variables_by_thread表分化意行使TRUNCATE TABLE语句

03

# status_by_thread 表

|group_replication_applier | ON |NULL | 0 |

MySQL server维护着非常多状态变量,提供有关当中间有关操作的音讯。如下一些performance_schema表中记录着状态变量消息:

COUNT_PROXY_USER_ERRORS: 0

  • show_compatibility_56系统变量的值会影响这一个表中的音讯记录
  • 对话变量表(session_variables,variables_by_thread)仅蕴含活跃会话的音讯,已经告一段落的对话不会记录
  • variables_by_thread表仅富含关于前台线程的对话品级系统变量新闻。且只记录具有会话级其余系统变量,另外,假使在该表中有不可见被记录的对话等第系统变量,那么将净增状态变量Performance_schema_thread_instances_lost的值

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 中缺乏的剧情如下:

HOST: 10.10.20.14

  • VARIABLE_NAME:系统变量名
  • VARIABLE_VALUE:系统变量值。对于global_variables,此列包涵全局值。对于session_variables,此列包括当前对话生效的变量值

|Aborted_clients | 0 |

  • Slave_retried_transactions
  • Slave_last_heartbeat
  • Slave_received_heartbeats
  • Slave_heartbeat_period
  • Slave_running

+-----------+-----------------------------------------+----------------+

5 rows inset (0.00 sec)

+--------------------------+----------------+

|45| Bytes_sent |2901|

大家先来拜望表中记录的总计音讯是哪些体统的。

HEARTBEAT_INTERVAL: 5.000

  • 当会话终止时征集的account相关状态变量会增添到全局状态变量表的计数器和accounts表的连锁计数器中。若是account分类关闭了访谈而host和user分类开启了访问,则会指向主机和客户分类聚合相应的状态变量值,同期将会话状态增多到hosts和users表中的相关计数器中
  • 如果将performance_schema_accounts_size,performance_schema_hosts_size和performance_schema_users_size系统变量分别安装为0,则不会采撷帐户,主机和客商分类的总括音信
  • show_compatibility_56系统变量的值会影响那一个表中的计算音信

+---------------------------+--------------------------------------+-------------+-------------+--------------+

|45| auto_increment_offset |2|

经过以上内容,大家从全体上能够大要掌握了performance_schema中的复制新闻表记录了什么音讯,下边依次详细介绍这几个复制音讯表。

admin@localhost : performance_schema 04:08 :36> select * from status_by_account where USER is notnull limit 5;

MySQL server维护着相当的多年体育系变量,在performance_schema中提供了对全局、当前对话、以及依照线程分组的系统变量音讯记录表:

|admin | localhost |Bytes_received | 6049 |

  • VARIABLE_NAME:状态变量名称
  • 与VARIABLE_VALUE:状态变量值,要稳重:该段值包括活跃和已告一段落的对话的状态变量总计值
  • USER:用户名
  • HOST:主机名或IP

+----------------------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+

图片 6

1.replication_applier_configuration表

| 45 |slave_uuid | 4b0027eb-6223-11e7-94ad-525400950aac |

SUM_CONNECT_ERRORS: 0

|HOST | VARIABLE_NAME |VARIABLE_VALUE |

| 45 |master_binlog_checksum | CRC32 |

+-----------+-------------------------+----------------+

图片 7

.............

该表中著录从库用于连接到主库的配置参数,该表中存款和储蓄的配备音信在奉行change master语句时会被涂改

......

表中各字段含义如下:

COUNT_INIT_CONNECT_ERRORS: 0

| VARIABLE_NAME |VARIABLE_VALUE |

NETWORK_INTERFACE:

VIEW_ID: 15287289928409067:1

PS:只要开发银行选项 skip_name_resolve 设置为ON,则该表不记录任何消息,因为该表的效果与利益正是用来防止、加快域名深入分析用于,跳过域名深入分析成效时则该表记录的音信用途相当小。

|localhost | Bytes_received |6113|

如果从库是单线程,则该表记录一条WOTucsonKE凯雷德_ID=0的SQL线程的状态。固然从库是十二线程,则该表记录系统参数slave_parallel_workers钦定个数的行事线程状态(WOWranglerKEHaval_ID从1从头编号),此时和煦器/SQL线程状态记录在replication_applier_status_by_coordinator表,每一个通路都有和好单身的办事线程和和谐器线程(各个通道的劳作线程个数由slave_parallel_workers参数变量钦命,倘使是MGKoleos集群时,则该表中记录的行事线程记录为slave_parallel_workers个group_replication_applier线程+1个group_replication_recovery线程),我们先来拜谒表中记录的总计消息是怎么体统的。

| CHANNEL_NAME |SERVICE_STATE | REMAINING_DELAY |COUNT_TRANSACTIONS_RETRIES |

| USER |HOST | VARIABLE_NAME |VARIABLE_VALUE |

|| 0 |82| ON || 0 || 0000-00-00 00:00:00 |

COUNT_FORMAT_ERRORS: 0

对于replication_group_members表,不允许实践TRUNCATE TABLE语句。

| admin |localhost | Bytes_sent |305705|

PS1:如下系统状态变量被移位到了那些复制状态表中实行记录(MySQL 5.7.5版在此以前使用以下状态变量查看):

COUNT_NAMEINFO_PERMANENT_ERRORS: 1

|USER | VARIABLE_NAME |VARIABLE_VALUE |

admin@localhost : performance_schema 04:08:58> select * from status_by_user where USER is notnull limit 5;

# 假若是单主或多主复制,则该表中会为种种复制通道记录一条看似如下新闻

THREAD_ID: NULL

|group_replication_applier | 0 |

CHANNEL_NAME:

admin@localhost : performance_schema 02:49:12> select * from replication_applier_configuration;

  • THREAD_ID:与该状态变量相关联的线程ID
  • VARIABLE_NAME:有对话品级的状态变量名称
  • VARIABLE_VALUE:与线程ID相关的对话等第状态变量值

|THREAD_ID | VARIABLE_NAME |VARIABLE_VALUE |

CONNECTION _RETRY_COUNT: 86400

5. replication_connection_configuration表

表中各字段含义及与show slave status输出字段对应关系如下:

该表中著录从库线程延迟复制的配置参数(延迟复制的线程被叫作普通线程,举个例子CHANNEL_NAME和DESIRED_DELAY字段记录某些复制通道是或不是须要推行延迟复制,假设是MG奥迪Q5集群,则记录组复制从节点的推移复制配置参数),该表中的记录在Server运维时能够运用CHANGE MASTER TO语句实行更换,大家先来探望表中著录的总计音讯是怎样样子的。

|group_replication_applier | 1 |92| ON |aaaaaaaa-aaaa-aaaa-aaaa- aaaaaaaaaaaa:104099082| 0 || 0000-00-00 00:00:00 |

3. replication_applier_status_by_coordinator表

# 假如是MG奥迪Q5集群,则该表会记录如下MG奥德赛集群音信

COUNT_SSL_ERRORS: 0

COUNT_DEFAULT_DATABASE_ERRORS: 0

admin@localhost : performance_schema 09 :50:31> select * from global_variables limit 5;

LAST _ERROR_MESSAGE:

|| ON |NULL | 0 |

# 八线程主从复制时表中的记录内容如下(假若是多主复制,则各个复制通道记录slave_parallel_workers参数钦定个数的worker线程消息)

4. replication_applier_status_by_worker表

5 rows inset (0.00 sec)

该表中记录的是从库IO线程的连日情况音讯(也记录组复制架构中其余节点的连年音信,组复制架构中二个节点出席集群在此之前的数据须要运用异步复制通道实行多少同步,组复制的异步复制通道新闻在show slave status中不可知),大家先来看看表中记录的总计音讯是怎么样样子的。

| group_replication_recovery |0| NULL |OFF | |0| |0000- 00- 0000:00:00|

  • status_by_thread表仅包括前台线程的状态变量音信。该表记录数据自动计算,不提入手工业钦定系统变量perform_schema_max_thread_instances的值,即使手工业钦点,务供给超过后台线程数量*2,不然也许导致因为该变量的限量没有丰裕的intruments thread instances体积导致无法制造,进而不能监督前台线程的状态变量总结音讯,假使不能监督前台线程的状态变量总计新闻时,该表为空
  • show_compatibility_56系统变量的值会影响那个表中的音信记录
  • performance_schema实行状态变量搜集时,对于全局级其他状态变量,如若threads表中INSTRUMENTED列值为“yes”则进行搜集,不然不访谈。但对此会话级其他状态变量,无论threads表的INSTRUMENTED字段值是不是为yes,始终试行搜集
  • performance_schema不会在情形变量表中收罗Com_xxx状态变量的总计音讯。要收获全局和各样会说话句的连锁实行计数,请分别使用events_statements_summary_global_by_event_name和events_statements_summary_by_thread_by_event_name表实行询问。例如:SELECT EVENT_NAME, COUNT_STAR FROM events_statements_summary_global_by_event_name WHERE EVENT_NAME LIKE 'statement/sql/%';
  • 对于按帐户,主机名和顾客名聚合的状态变量音信。详见下文。

4 rows inset (0.00 sec)

| THREAD_ID |VARIABLE_NAME | VARIABLE_VALUE |

+-----------+-------------------------+--------------------------------------+

............

+--------------+-----------+---------------+-------------------+--------------------+----------------------+

+--------------+---------------+-----------------+----------------------------+

+---------------------------+--------------------------------------+-------------+-------------+--------------+

| 45 |master_heartbeat_period | 5000000000 |

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

+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+

图片 8

COUNT_MAX_USER_CONNECTIONS_ERRORS: 0

对于replication_connection_status表,分裂意推行TRUNCATE TABLE语句。

......

global_variables和session_variables表字段含义如下:

aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-104099082

  • global_status:全局状态变量。如若只须要全局状态变量值的应用程序能够查询此表,中断的对话状态变量值会被会集在此表中
  • session_status:当前对话的状态变量。借使只愿意查询本身对话的具有境况变量值的应用程序能够查询此表(注意:该表包涵未有对话级其余全局状态变量),只记录活跃会话,不记录已暂停的对话
  • status_by_thread:依照线程ID作为标志符记录每一个活跃会话的状态变量。如若急需在某些会话中询问任何会话的境况变量值能够查询此表(注意:该表不分包只享有全局级其他状态变量),只记录活跃会话,不记录中断的对话

COUNT _TRANSACTIONS_ROWS_VALIDATING: 0

  • CHANNEL_NAME:组成员所在组所选取的复制通道名称,通道名字为:group_replication_applier
  • VIEW_ID:组成员所在组的眼下视Logo记符
  • MEMBER_ID:展现当前组成员server的UUID,组成员实例的UUID同样。组中的各样节点有所不一样的值(因为是选择的组成员实例的UUID,该UUID随机生成,保险全局独一)且唯一
  • COUNT_TRANSACTIONS_IN_QUEUE:表示最近队列中等待抵触检查的事务数(等待全局专业认证的事务数),一旦冲突检查评定通过,他们将排队等候应用
  • COUNT_TRANSACTIONS_CHECKED:表示已经过争辩检查机制检查的事务数(已透过全局职业认证的事务数,从节点插足组复制时始于总括)
  • COUNT_CONFLICTS_DETECTED:表示未通过争辨检查实验机制检查的事务数(在大局工作认证时未经过的事务数)
  • COUNT_TRANSACTIONS_ROWS_VALIDATING:表示争论检查实验数据库的此时此刻高低(用于寄存每种经过证实的事体的数据库),可用来注明新业务,但从不被垃圾回收的可用行数
  • TRANSACTIONS_COMMITTED_ALL_MEMBETiggoS:展现已在此时此刻视图中的全数成员上成功交付的事体(类似具有成员实例的gtid_executed集合的混合),该值固定期期间隔更新(所以并不实时)
  • LAST_CONFLICT_FREE_TRANSACTION:显示最终一遍无争论校验检查的政工标志符(最终一个从未有过冲突的专门的学问的GTID)

+----------------------------+---------------+-----------------+----------------------------+

原标题:复制状态与变量记录表 | performance_schema全方位介绍(六)

HOST: NULL

状态变量摘要表允许推行TRUNCATE TABLE语句,实行truncate语句时活动会话的状态变量不受影响:

SSL_CIPHER:

status_by_thread表蕴涵各样活跃线程的景色。字段含义如下:

# 单线程复制和十二线程复制时表中的记录同一,假设是多主复制,则各样复制通道记录一行新闻

1row inset ( 0. 00sec)

5 rows inset (0.01 sec)

# 要是是MGLAND集群,则该表中会记录类似如下MG帕杰罗集群新闻

COUNT_PROXY_USER_ACL_ERRORS: 0

该表中著录的是从库使用八线程复制时,从库的和谐器工作状态记录,当从库使用二十二十四线程复制时,每一种通道下将创制二个和煦器和四个干活线程,使用和谐器线程来保管这一个干活儿线程。即使从库使用单线程,则此表为空(对应的记录转移到replication_applier_status_by_worker表中记录),大家先来看看表中著录的计算新闻是何许样子的。

  • 与replication_connection_status表相比,replication_connection_configuration退换频率更低。因为它只包涵从库连接到主库的安排参数,在接连平常职业时期那些安排音信保持不改变的值,而replication_connection_status中包罗的总是意况音信,只要IO线程状态发生变化,该表中的新闻就能时有产生修改(多主复制框架结构中,从库指向了稍稍个主库就能记录多少行记录。MGEvoque集群架构中,每一个节点有两条记下,但这两条记下并未有记录完整的组复制连接配置参数,比方:host等音讯记录到了replication_group_members表中)。

+----------------------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+

# variables_by_thread表

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

performance_schema允许对这么些状态变量音讯总计表试行TRUNCATE TABLE语句:

# 假使是MGGL450集群,则该表中会记录类似如下MGRAV4集群音讯

小编们先来探视表中记录的总结消息是什么样体统的。

|| 3 |46| ON || 0 || 0000-00-00 00:00:00 |

COUNT_NO_AUTH_PLUGIN_ERRORS: 0

CHANNEL _NAME: group_replication_applier

1row inset ( 0. 00sec)

| auto_increment_offset |2|

+----------------------------+---------------+-----------------+----------------------------+

我们先来探视表中记录的总计音信是何等体统的。

# session_status表(记录内容与global_status 表类似)

# 单线程主从复制时表中记录的开始和结果如下

| CHANNEL_NAME |MEMBER_ID | MEMBER_HOST |MEMBER_PORT | MEMBER_STATE |

# 要是是MG福睿斯集群,则该表中会记录类似如下MGPRADO集群消息

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

| VARIABLE_NAME |VARIABLE_VALUE |

MEMBER_ID: 5d78a458-30d2-11e8-a66f-5254002a54f2

| |4| 47 |ON | |0| |0000- 00- 0000:00:00|

# status_by_account表

admin@localhost : performance_schema 04:08:43> select * from status_by_host where HOST is notnull limit 5;

+--------------+---------------+-----------------+----------------------------+

表中各字段含义及与show slave status输出字段对应关系如下:

HOST: <NULL>

| CHANNEL_NAME |SERVICE_STATE | REMAINING_DELAY |COUNT_TRANSACTIONS_RETRIES |

# session_variables表(查询结果与global_variables 表类似)

HOST: <NULL>

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

01

顾客自定义变量记录表

图片 9

|45| Bytes_received |0|

+---------------------------+--------------------------------------+-------------+-------------+--------------+

  • status_by_account:根据每一种帐户进行联谊的状态变量
  • status_by_host:根据各种主机名举行联谊的状态变量
  • status_by_user:遵照各类客商名打开联谊的状态变量

+----------------------------+----------------+

+--------------+-----------+---------------+-------------------+--------------------+----------------------+

对于replication_applier_status_by_coordinator表,差别意施行TRUNCATE TABLE语句。

LAST _ERROR_MESSAGE:

1row inset ( 0. 00sec)

|CHANNEL_NAME | WORKER_ID |THREAD_ID | SERVICE_STATE |LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER |LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |

+----------------------------+----------------+

CHANNEL _NAME: group_replication_applier

5 rows inset (0.00 sec)

system variables记录表

| CHANNEL_NAME |THREAD_ID | SERVICE_STATE |LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE |LAST_ERROR_TIMESTAMP |

LAST _ERROR_NUMBER: 0

status variables统计表

+----------------------------+---------------+

admin@localhost : performance_schema 02:49:50> select * from replication_applier_status_by_coordinator;

  • THREAD_ID:会话等第系统变量对应的线程ID
  • VARIABLE_NAME:会话等第系统变量名
  • VARIABLE_VALUE:会话等级系统变量值

图片 10

COUNT_ADDRINFO_TRANSIENT_ERRORS: 0

| |2| 45 |ON | |0| |0000- 00- 0000:00:00|

admin@localhost : performance_schema 11:02:49> select * from status_by_thread limit 5;

  • status_by_account:终止的对话在account聚合表中的状态变量值将被集结到客户和主机聚合表中的状态变量计数器中,然后重新初始化帐户聚合表中的状态变量值
  • status_by_host:终止的对话对应的状态变量被重新恢复设置
  • status_by_user:终止的对话对应的状态变量被重新初始化

表中各字段含义及与show slave status输出字段对应关系如下:

+-------+-------------------------+----------------+

+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+

AUTO_POSITION: 1

|45| auto_increment_increment |2|

CHANNEL _NAME: group_replication_applier

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

表中各字段含义及与show slave status输出字段对应关系如下:

+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+

root@localhost : performance_schema 10:58:33> select * from replication_applier_status;

用以援引binlog file、pos和relay log file、pos等新闻选项,在performance_schema表中不记录 。

SSL_CERTIFICATE:

SSL _CA_PATH:

|localhost | Bytes_sent |306310|

COUNT_HOST_BLOCKED_ERRORS: 0

+--------------------------+----------------+

|THREAD_ID | VARIABLE_NAME |VARIABLE_VALUE |

5 rows inset (0.00 sec)

# global_status表

04

root@localhost : performance_schema 10:56:49> select * from replication_applier_configuration;

3rows inset ( 0. 01sec)

root@localhost : performance _schema 11:02:10> select * from replication_group _member_statsG

TLS_VERSION:

.......

COUNT_NAMEINFO_TRANSIENT_ERRORS: 0

......

......

# 二十八线程和单线程主从复制时表中记录同一,倘使是多主复制,则各个复制通道在表中个记录一行音讯

PORT: 3306

| CHANNEL_NAME |WORKER_ID | THREAD_ID |SERVICE_STATE | LAST_SEEN_TRANSACTION |LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE |LAST_ERROR_TIMESTAMP |

  • 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

06

| group_replication_applier |2| 93 |ON | |0| |0000- 00- 0000:00:00|

admin@localhost : performance_schema 02:49:28> select * from replication_applier_status;

+----------------------------+---------------+

admin@localhost : performance_schema 11:01:51> select * from global_status limit 5;

CHANNEL _NAME: group_replication_recovery

GROUP_NAME: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa

COUNT_UNKNOWN_ERRORS: 0

root@localhost : performance_schema 12:46:10> select * from replication_applier_status_by_worker;

global_status和session_status表字段含义如下:

FLUSH STATUS语句会把持有活跃会话的景色变量值聚合到全局状态变量值中,然后复位全体活跃会话的状态变量值,并在account,host和user状态变量对应的总括表中重新载入参数已断开连接的状态变量聚合值。

COUNT _RECEIVED_HEARTBEATS: 136

+-------+-----------+-------------------------+----------------+

FIRST_ERROR_SEEN: 2017 -12-3022 :34:51

5 rows inset (0.00 sec)

+----------------------------+---------------+-----------------+----------------------------+

| Aborted_connects |0|

|| 1 |44| ON || 0 || 0000-00-00 00:00:00 |

  • VARIABLE_NAME:状态变量名称
  • VARIABLE_VALUE:状态变量值。对于global_status,此列满含全局状态变量值。对于session_status,此列包涵当前对话的气象变量值(同期含有无会话等第的全局状态变量值,且只含有活跃会话的图景变量值)。

+---------------------------+-----------+---------------+-------------------+--------------------+----------------------+

+-------+-------------------------+----------------+

SSL _CRL_FILE:

root@localhost : performance_schema 11:03:38> select * from replication_group_members;

图片 11

| CHANNEL_NAME |THREAD_ID | SERVICE_STATE |LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE |LAST_ERROR_TIMESTAMP |

COUNT_AUTHENTICATION_ERRORS: 0

admin@localhost : performance_schema 01:50:16> select * from user_variables_by_thread;

在上马详细介绍每一张复制新闻表此前,大家先开销一些篇幅来完全认知一下那些表。

FLUSH HOSTS和TRUNCATE TABLE host_cache具备同样的成效:它们清除主机缓存。host_cache表被清空并化解阻塞任何因为破绽相当多记录数据超过限制而被封堵的主机连接。FLUSH HOSTS必要RELOAD权限。 TRUNCATE TABLE要求host_cache表的DROP权限。

+--------------+---------------+-----------------+----------------------------+

图片 12

admin@localhost : performance_schema 11:02:21> select * from session_status limit 5;

遵纪守法帐号、主机、客商总结的状态变量总结表

表中各字段含义以及与change master to语句的挑三拣四对应关系如下:

遵从帐号、主机名、客商名称叫分组对状态变量实行归类数据,比方:遵照帐号表总括的表分组列为host和user列,聚合列当然便是状态变量本人(该作用是MySQL 5.7本子新扩大的),有如下几张表:

  • THREAD_ID:定义变量的对话的线程标志符(ID)
  • VARIABLE_NAME:定义的变量名称,在该表中去掉了@字符的款式显式
  • VARIABLE_VALUE:定义的变量值
  • replication_group_member_stats
  • replication_group_members
  • replication_applier_status
  • replication_connection_status
  • threads

我们先来寻访表中著录的总结音信是怎么着样子的。

SERVICE_STATE: ON

产品 沃趣科学和技术

图片 13

# global_variables表

对于replication_applier_status_by_worker表,不容许施行TRUNCATE TABLE语句。

  • IP:连接到server的顾客端的IP地址,以字符串格局记录
  • HOST:该客商端IP分析的DNS主机名,若无计算利息记录,则该字段为NULL
  • HOST_VALIDATED:有个别IP的顾客端的'IP-主机名称-IP'的分析是还是不是中标。如若HOST_VALIDATED为YES,则HOST列被看作与之相关的IP使用,以制止选拔DNS深入分析。当HOST_VALIDATED为NO时,对于每一个连会再三地品尝DNS深入分析,直到最后回到有效的解析结果还是重回一个不当。能够选择该音信来在server所使用的DNS服务器故障时期制止实行DNS分析
  • SUM_CONNECT_EOdysseyROHavalS:该字段记录的连接错误数量被以为是“正在围堵中”的连接数(此时你也许供给关切下max_connect_errors系统变量值,一旦该列值超越该变量的值,则延续的接连将间接被拒绝)。只对左券握手错误实行计数,况且仅对通过认证的主机(HOST_VALIDATED = YES)举行计数
  • COUNT_HOST_BLOCKED_ERRORS:由于SUM_CONNECT_ERRORS超出了max_connect_errors系统变量的值而被封堵的连接数
  • COUNT_NAMEINFO_TRANSIENT_EENCOREROTiggoS:从IP到主机名称的DNS分析时期的短暂错误的多少,举个例子第三遍分析失利,第一次剖析成功
  • COUNT_NAMEINFO_PERMANENT_E奥迪Q5ROLANDS:从IP到主机名称DNS解析时期的永恒性错误的数码,深入分析DNS直到不再尝试再次分析的荒唐
  • COUNT_FORMAT_EWranglerRO揽胜极光S:主机名格式错误的数码。 对于主机名(DNS中的主机名),MySQL不会在mysql.user表中重试实施与主机列相称操作,举个例子:1.2.example.com(主机名部分是数字是大错特错的格式)。可是借使直接运用IP地址时则前缀是数字的不会被识别为错误格式,会接纳IP格式相配并不是DNS格式
  • COUNT_ADDRINFO_TRANSIENT_E中华VROKoleosS:从主机名称到IP反向DNS深入分析进度中的短暂错误数量
  • COUNT_ADDRINFO_PERMANENT_ETiggoROENVISIONS:从主机名称到IP反向DNS分析时期的长久性错误的数目
  • COUNT_FCRDNS_E奥迪Q3RO揽胜极光S:DNS反向深入分析发生错误的数据。当IP-主机名称-IP的剖判爆发了分析的结果IP与倡导呼吁的顾客端原始IP不相配时,就产后了这几个张冠李戴
  • COUNT_HOST_ACL_E福特ExplorerROWranglerS:有个别主机未有有权力的顾客可记名server时,从这么些主机尝试登陆server会发生这一个漏洞非常多。在这种意况下,server再次回到E奥迪Q3_HOST_NOT_PRIVILEGED错误
  • COUNT_NO_AUTH_PLUGIN_E中华VRO揽胜极光S:由于须要的身份验证插件不可用而招致的荒谬数量。比如:有个别身份验证插件并未有加载,那么那些插件被呼吁时就能够发生那几个错误
  • COUNT_AUTH_PLUGIN_E奥德赛ROXC60S:身份验证插件报告的谬误数。验证插件能够告诉分化的错误代码,以提议故障的根本原因。依据错误类型,相应地充实对应错误类型的失实计数列值(COUNT_AUTHENTICATION_ERRORS、COUNT_AUTH_PLUGIN_ERRORS、COUNT_HANDSHAKE_ELX570RO逍客S),未知的插件错误在COUNT_AUTH_PLUGIN_EEnclaveRO陆风X8S列中计数
  • COUNT_HANDSHAKE_EEscortRO福睿斯S:在握手球组织议等级检验到的失实数
  • COUNT_PROXY_USER_E冠道RO福睿斯S:代理客户A在代理不设有的另一客户B时检查测量试验到的荒谬数
  • COUNT_PROXY_USER_ACL_E福睿斯RORubiconS:今世理顾客A被代理给另壹个设有可是对于A未有PROXY权限的客商B时,检查测试到的荒唐数量
  • COUNT_AUTHENTICATION_EXC90RO奇骏S:认证战败致使的一无是处次数
  • COUNT_SSL_E陆风X8RO瑞鹰S:由于SSL难点变成的不当数量
  • COUNT_MAX_USER_CONNECTIONS_ERAV4RO路虎极光S:高出各种客商连接分配的定额变成的荒谬数
  • COUNT_MAX_USER_CONNECTIONS_PER_HOUR_E传祺ROENVISIONS:高出每客户连接每时辰分配的定额产生的失实数量
  • COUNT_DEFAULT_DATABASE_E本田UR-VRO库罗德S:与暗许数据库相关的荒谬数。比方:数据库不设有或客商未有权力访谈
  • COUNT_INIT_CONNECT_ERRORS:由init_connect系统变量加载的公文中的语句推行倒闭引起的不当数
  • COUNT_LOCAL_E奥迪Q5RO福睿斯S:server本地执行有关操作时的一无所长数量,与网络、身份验证、授权毫不相关的错误。举个例子,内部存储器不足的意况属于这一体系
  • COUNT_UNKNOWN_E冠道ROCRUISERS:别的未知错误的多少,该列保留供未来应用
  • FIRST_SEEN:对于有个别IP顾客端,第叁遍尝试连接爆发的岁月
  • LAST_SEEN:对于有个别IP客商端,最终三遍尝试连接产生的时日
  • FIRST_ERROR_SEEN:对于某些IP客商端,第三回尝试连接爆发错误的时光
  • LAST_ERROR_SEEN:对于某些IP客商端,最终二回尝试连接产生错误的岁月

6. replication_connection_status表

  • 在施行CHANGE MASTE瑞虎 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字段被分配了三个值,且SESportageVICE_STATE字段被改变为ON了,THREAD_ID字段值与show processlist语句中观看的线程id同样。 * 如若IO线程空闲或正在从主库接收binlog时,线程的SEPRADOVICE_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表记录一条WOENVISIONKECRUISER_ID=0的记录,replication_applier_status_by_coordinator表与mysql.slave_wroker_info表为空(使用十二线程复制,该表中才有记录)。即,即使slave_parallel_workers系统变量大于0,则在试行START SLAVE时这几个表就被填充相应八线程工作线程的新闻

LAST _CONFLICT_FREE_TRANSACTION:

SERVICE_STATE: ON

# status_by_host表

对于replication_applier_status表,不容许试行TRUNCATE TABLE语句。

表中各字段含义如下:

SSL _VERIFY_SERVER_CERTIFICATE: NO

PS:

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

2. replication_applier_status表

本文由四不像生肖图发布于上市公司,转载请注明出处:Mysql主从同步错误,复制状态与变量记录表

关键词:

上一篇:得到千万好评,引领前卫风向
下一篇:没有了