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

如果从库是单线程,则该表记录一条WORKER_ID=0的SQL线程的状态。如果从库是多线程,则该表记录系统参数slave_parallel_workers指定个数的工作线程状态(WORKER_ID从1开始编号),此时协调器/SQL线程状态记录在replication_applier_status_by_coordinator表,每一个通道都有自己独立的工作线程和协调器线程(每个通道的工作线程个数由slave_parallel_workers参数变量指定,如果是MGR集群时,则该表中记录的工作线程记录为slave_parallel_workers个group_replication_applier线程+1个group_replication_recovery线程),我们先来看看表中记录的统计信息是什么样子的。

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

CHANNEL _NAME: group_replication_recovery

image.png

  • CHANNEL_NAME:组成员所在组所使用的复制通道名称,通道名称为:group_replication_applier
  • VIEW_ID:组成员所在组的当前视图标识符
  • MEMBER_ID:显示当前组成员server的UUID,组成员实例的UUID相同。组中的每个节点具有不同的值(因为是使用的组成员实例的UUID,该UUID随机生成,保证全局唯一)且唯一
  • COUNT_TRANSACTIONS_IN_QUEUE:表示当前队列中等待冲突检查的事务数(等待全局事务认证的事务数),一旦冲突检测通过,他们将排队等待应用
  • COUNT_TRANSACTIONS_CHECKED:表示已通过冲突检查机制检查的事务数(已通过全局事务认证的事务数,从节点加入组复制时开始计算)
  • COUNT_CONFLICTS_DETECTED:表示未通过冲突检测机制检查的事务数(在全局事务认证时未通过的事务数)
  • COUNT_TRANSACTIONS_ROWS_VALIDATING:表示冲突检测数据库的当前大小(用于存放每个经过验证的事务的数据库),可用于认证新事务,但尚未被垃圾回收的可用行数
  • TRANSACTIONS_COMMITTED_ALL_MEMBERS:显示已在当前视图中的所有成员上成功提交的事务(类似所有成员实例的gtid_executed集合的交集),该值固定时间间隔更新(所以并不实时)
  • LAST_CONFLICT_FREE_TRANSACTION:显示最后一次无冲突校验检查的事务标识符(最后一个没有冲突的事务的GTID)

图片 1

2 rows inset (0.00 sec)

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.

variables_by_thread表字段含义如下:

去主库查找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
找到日志:

user_variables_by_thread表不允许使用TRUNCATE
TABLE语句

查看这个ID为332的这张表,发现这张表是自动创建的,创建的时候没有指定存储引擎,所以主从都出错了

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

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

# 如果是MGR集群,则该表中会记录类似如下MGR集群信息

  • 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

图片 2

COUNT_NAMEINFO_PERMANENT_ERRORS: 1

| CHANNEL_NAME |SERVICE_STATE | REMAINING_DELAY
|COUNT_TRANSACTIONS_RETRIES |

performance_schema记录系统变量的这些表不支持TRUNCATE
TABLE语句

+—————————+————————————–+————-+————-+————–+

|Aborted_clients | 0 |

+————–+———–+—————+——————-+——————–+———————-+

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

|45| Bytes_received |0|

1row inset ( 0. 00sec)

该表中记录从库用于连接到主库的配置参数,该表中存储的配置信息在执行change
master语句时会被修改

这些复制表中记录的信息生命周期如下(生命周期即指的是这些表中的信息什么时候写入,什么时候会被修改,什么时候会被清理等):

  • 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…你懂的)

对于replication_applier_status_by_coordinator表,不允许执行TRUNCATE
TABLE语句。

host_cache表

FLUSH
STATUS语句会把所有活跃会话的状态变量值聚合到全局状态变量值中,然后重置所有活跃会话的状态变量值,并在account,host和user状态变量对应的统计表中重置已断开连接的状态变量聚合值。

+————–+———–+———–+—————+———————–+——————-+——————–+———————-+

+—————————-+—————-+

5. replication_connection_configuration表

+—————————-+—————+—————–+—————————-+

| group_replication_recovery |OFF | NULL |0|

  • THREAD_ID:定义变量的会话的线程标识符(ID)
  • VARIABLE_NAME:定义的变量名称,在该表中去掉了@字符的形式显式
  • VARIABLE_VALUE:定义的变量值

5 rows inset (0.00 sec)

  • VARIABLE_NAME:状态变量名称
  • VARIABLE_VALUE:状态变量值。对于global_status,此列包含全局状态变量值。对于session_status,此列包含当前会话的状态变量值(同时包含无会话级别的全局状态变量值,且只包含活跃会话的状态变量值)。

1row inset ( 0. 00sec)

5 rows inset (0.00 sec)

COUNT_AUTHENTICATION_ERRORS: 0

PS:

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

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

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

图片 3

CHANNEL_NAME:

| CHANNEL_NAME |DESIRED_DELAY |

2 rows inset (0.00 sec)

# 如果是MGR集群,则该表中会记录类似如下MGR集群信息

  • 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_ERRORS:该字段记录的连接错误数量被认为是“正在阻塞中”的连接数(此时你可能需要关注下max_connect_errors系统变量值,一旦该列值超过该变量的值,则后续的连接将直接被拒绝)。只对协议握手错误进行计数,并且仅对通过验证的主机(HOST_VALIDATED
    = YES)进行计数
  • COUNT_HOST_BLOCKED_ERRORS:由于SUM_CONNECT_ERRORS超出了max_connect_errors系统变量的值而被阻塞的连接数
  • COUNT_NAMEINFO_TRANSIENT_ERRORS:从IP到主机名称的DNS解析期间的短暂错误的数量,例如第一次解析失败,第二次解析成功
  • COUNT_NAMEINFO_PERMANENT_ERRORS:从IP到主机名称DNS解析期间的永久性错误的数量,解析DNS直到不再尝试重新解析的错误
  • COUNT_FORMAT_ERRORS:主机名格式错误的数量。
    对于主机名(DNS中的主机名),MySQL不会在mysql.user表中重试执行与主机列匹配操作,例如:1.2.example.com(主机名部分是数字是错误的格式)。但是如果直接使用IP地址时则前缀是数字的不会被识别为错误格式,会使用IP格式匹配而不是DNS格式
  • COUNT_ADDRINFO_TRANSIENT_ERRORS:从主机名称到IP反向DNS解析过程中的短暂错误数量
  • COUNT_ADDRINFO_PERMANENT_ERRORS:从主机名称到IP反向DNS解析期间的永久性错误的数量
  • COUNT_FCRDNS_ERRORS:DNS反向解析发生错误的数量。当IP-主机名称-IP的解析发生了解析的结果IP与发起请求的客户端原始IP不匹配时,就产后了这个错误
  • COUNT_HOST_ACL_ERRORS:某个主机没有有权限的用户可登录server时,从这个主机尝试登录server会发生这个错误。在这种情况下,server返回ER_HOST_NOT_PRIVILEGED错误
  • COUNT_NO_AUTH_PLUGIN_ERRORS:由于请求的身份验证插件不可用而导致的错误数量。例如:某个身份验证插件并未加载,那么这个插件被请求时就会发生这个错误
  • COUNT_AUTH_PLUGIN_ERRORS:身份认证插件报告的错误数。验证插件可以报告不同的错误代码,以指出故障的根本原因。根据错误类型,相应地增加对应错误类型的错误计数列值(COUNT_AUTHENTICATION_ERRORS、COUNT_AUTH_PLUGIN_ERRORS、COUNT_HANDSHAKE_ERRORS),未知的插件错误在COUNT_AUTH_PLUGIN_ERRORS列中计数
  • COUNT_HANDSHAKE_ERRORS:在握手协议级别检测到的错误数
  • COUNT_PROXY_USER_ERRORS:代理用户A在代理不存在的另一用户B时检测到的错误数
  • COUNT_PROXY_USER_ACL_ERRORS:当代理用户A被代理给另一个存在但是对于A没有PROXY权限的用户B时,检测到的错误数量
  • COUNT_AUTHENTICATION_ERRORS:认证失败造成的错误次数
  • COUNT_SSL_ERRORS:由于SSL问题导致的错误数量
  • COUNT_MAX_USER_CONNECTIONS_ERRORS:超出每个用户连接配额造成的错误数
  • COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS:超出每用户连接每小时配额造成的错误数量
  • COUNT_DEFAULT_DATABASE_ERRORS:与默认数据库相关的错误数。例如:数据库不存在或用户没有权限访问
  • COUNT_INIT_CONNECT_ERRORS:由init_connect系统变量加载的文件中的语句执行失败引起的错误数
  • COUNT_LOCAL_ERRORS:server本地执行相关操作时的错误数量,与网络、身份验证、授权无关的错误。例如,内存不足的情况属于这一类别
  • COUNT_UNKNOWN_ERRORS:其他未知错误的数量,该列保留供将来使用
  • FIRST_SEEN:对于某个IP客户端,第一次尝试连接发生的时间
  • LAST_SEEN:对于某个IP客户端,最后一次尝试连接发生的时间
  • FIRST_ERROR_SEEN:对于某个IP客户端,第一次尝试连接发生错误的时间
  • LAST_ERROR_SEEN:对于某个IP客户端,最后一次尝试连接发生错误的时间

……

global_variables和session_variables表字段含义如下:

+———–+————————-+————————————–+

COUNT_MAX_USER_CONNECTIONS_ERRORS: 0

………….

+————–+—————+—————–+—————————-+

| 45 |master_binlog_checksum | CRC32 |

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

# global_variables表

# status_by_thread 表

HEARTBEAT_INTERVAL: 5.000

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

图片 4

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

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

……

  • 在执行CHANGE MASTER 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字段被分配了一个值,且SERVICE_STATE字段被修改为ON了,THREAD_ID字段值与show
    processlist语句中看到的线程id相同。 *
    如果IO线程空闲或正在从主库接收binlog时,线程的SERVICE_STATE值会一直为ON,THREAD_ID线程记录线程ID值,如果IO线程正在尝试连接主库但还没有成功建立连接时,THREAD_ID记录CONNECTING值,THREAD_ID字段记录线程ID,如果IO线程与主库的连接断开,或者主动停止IO线程,则SERVICE_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表记录一条WORKER_ID=0的记录,replication_applier_status_by_coordinator表与mysql.slave_wroker_info表为空(使用多线程复制,该表中才有记录)。即,如果slave_parallel_workers系统变量大于0,则在执行START
    SLAVE时这些表就被填充相应多线程工作线程的信息

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

表中各字段含义

status variables统计表

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 中缺少的内容如下:

3. replication_applier_status_by_coordinator表

04

| CHANNEL_NAME |SERVICE_STATE | REMAINING_DELAY
|COUNT_TRANSACTIONS_RETRIES |

表中各字段含义如下:

SERVICE_STATE: ON

THREAD_ID: NULL

+———–+————————-+—————-+

SSL_ALLOWED: NO

用户自定义变量记录表

| USER |HOST | VARIABLE_NAME |VARIABLE_VALUE |

2. replication_applier_status表

| VARIABLE_NAME |VARIABLE_VALUE |

06

该表中记录的是从库当前的一般事务执行状态(该表也记录组复制架构中的复制状态信息)

我们先来看看表中记录的统计信息是什么样子的。

+———–+—————————————–+—————-+

IT从业多年,历任运维工程师,高级运维工程师,运维经理,数据库工程师,曾参与版本发布系统,轻量级监控系统,运维管理平台,数据库管理平台的设计与编写,熟悉MySQL的体系结构时,InnoDB存储引擎,喜好专研开源技术,追求完美。

+—————————-+—————+

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

+————–+———–+—————+——————-+——————–+———————-+

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

SSL _CRL_FILE:

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

1 row in set (0.00 sec)

SSL_KEY:

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

LAST _CONFLICT_FREE_TRANSACTION:

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

……

  • 当会话终止时收集的account相关状态变量会添加到全局状态变量表的计数器和accounts表的相关计数器中。如果account分类关闭了收集而host和user分类开启了收集,则会针对主机和用户分类聚合相应的状态变量值,同时将会话状态添加到hosts和users表中的相关计数器中
  • 如果将performance_schema_accounts_size,performance_schema_hosts_size和performance_schema_users_size系统变量分别设置为0,则不会收集帐户,主机和用户分类的统计信息
  • show_compatibility_56系统变量的值会影响这些表中的统计信息

COUNT _RECEIVED_HEARTBEATS: 136

RECEIVED _TRANSACTION_SET:

  • CHANNEL_NAME:组复制架构中使用的通道名称,通道名称为:group_replication_applier
  • MEMBER_ID:组复制架构中,组成员的ID,与组成员实例的server UUID相同
  • MEMBER_HOST:组复制架构中,组成员的网络地址(主机名或IP地址,与成员实例的hostname或report_host系统变量的值相同)
  • MEMBER_PORT:组复制架构中,组成员的侦听端口,与组成员实例的port或report_port系统变量的值相同
  • MEMBER_STATE:组复制架构中,组成员的状态 有效状态如下: *
    OFFLINE:组复制成员已经安装组复制插件,但未启动 *
    RECOVERING:组复制成员已经加入到组复制架构中,正在从组中接收数据,即正在加入集群 *
    ONLINE:组复制成员处于正常运行状态 *
    PS:组复制架构中,如果组成员的组复制状态发生错误,无法正常从组中接收数据是,可能会变成ERROR状态。如果发生网络故障或者其他成员宕机,那么剩余存活的孤立节点的状态可能会变为UNREACHABLE

HOST_VALIDATED: YES

+—————————-+—————+—————–+—————————-+

COUNT_HANDSHAKE_ERRORS: 0

system variables记录表

COUNT _TRANSACTIONS_ROWS_VALIDATING: 0

# global_status表

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

|admin | Bytes_sent |306781|

1row inset ( 0. 00sec)

# 如果是单主或多主复制,则该表中会为每个复制通道记录一条类似如下信息

  • Slave_retried_transactions
  • Slave_last_heartbeat
  • Slave_received_heartbeats
  • Slave_heartbeat_period
  • Slave_running

+————–+—————+

MySQL
server维护着许多系统变量,在performance_schema中提供了对全局、当前会话、以及按照线程分组的系统变量信息记录表:

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

#
多线程和单线程主从复制时表中记录相同,如果是多主复制,则每个复制通道在表中个记录一行信息

  • status_by_account:终止的会话在account聚合表中的状态变量值将被聚合到用户和主机聚合表中的状态变量计数器中,然后重置帐户聚合表中的状态变量值
  • status_by_host:终止的会话对应的状态变量被重置
  • status_by_user:终止的会话对应的状态变量被重置

COUNT_DEFAULT_DATABASE_ERRORS: 0

……

我们先来看看表中记录的统计信息是什么样子的。

COUNT_NO_AUTH_PLUGIN_ERRORS: 0

……

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

| 45 |master_heartbeat_period | 5000000000 |

| group_replication_recovery |0|

SOURCE_UUID: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa

|admin | Bytes_received |6177|

+—————————+———–+—————+——————-+——————–+———————-+

……

LAST _ERROR_NUMBER: 0

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

AUTO_POSITION: 1

CHANNEL _NAME: group_replication_applier

05

|THREAD_ID | VARIABLE_NAME |VARIABLE_VALUE |

FLUSH HOSTS和TRUNCATE TABLE
host_cache具有相同的效果:它们清除主机缓存。host_cache表被清空并解除阻塞任何因为错误记录数量超过限制而被阻塞的主机连接。FLUSH
HOSTS需要RELOAD权限。 TRUNCATE TABLE需要host_cache表的DROP权限。

COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS: 0

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

+———–+————————-+————————————–+

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

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

1 rowinset(0 .00sec)

8. replication_group_members表

PORT: 3306

|group_replication_applier | ON |NULL | 0 |

IP: 192 .168.2.122

不知不觉中,performance_schema系列快要接近尾声了,今天将带领大家一起踏上系列第六篇的征程(全系共6个篇章),在这一期里,我们将为大家全面讲解performance_schema中的复制状态与变量统计表。下面,请跟随我们一起开始performance_schema系统的学习之旅吧~

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

COUNT_FORMAT_ERRORS: 0

1row inset ( 0. 00sec)

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

COUNT_INIT_CONNECT_ERRORS: 0

SSL _VERIFY_SERVER_CERTIFICATE: NO

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

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

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

COUNT_HOST_BLOCKED_ERRORS: 0

图片 5

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

COUNT_HOST_ACL_ERRORS: 0

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

performance_schema提供了一个保存用户定义变量的user_variables_by_thread表(该表也保存由mysql内部连接线程创建的变量)。这些变量是在特定会话中定义的变量,变量名由@字符开头。

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

图片 6

# status_by_host表

LAST _ERROR_MESSAGE:

SSL _CA_PATH:

HOST: <NULL>

该表中记录了MySQL组复制成员的统计信息。仅在组复制组件运行时表中才会有记录,我们先来看看表中记录的统计信息是什么样子的。

1.replication_applier_configuration表

# 单线程主从复制时表中记录的内容如下

|localhost | Bytes_sent |306310|

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

NETWORK_INTERFACE:

|HOST | VARIABLE_NAME |VARIABLE_VALUE |

+——-+———–+————————-+—————-+

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

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

host_cache表保存连接到server的主机相关信息缓存,其中包含客户机主机名和IP地址信息,可以用于避免DNS查找。该表可以使用SELECT语句进行查询,但需要在server启动之前开启performance_schema参数,否则表记录为空。

VIEW_ID: 15287289928409067:1

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

该表中记录的是从库使用多线程复制时,从库的协调器工作状态记录,当从库使用多线程复制时,每个通道下将创建一个协调器和多个工作线程,使用协调器线程来管理这些工作线程。如果从库使用单线程,则此表为空(对应的记录转移到replication_applier_status_by_worker表中记录),我们先来看看表中记录的统计信息是什么样子的。

COUNT_SSL_ERRORS: 0

图片 7

…………

+————–+—————+

| VARIABLE_NAME |VARIABLE_VALUE |

5 rows inset (0.00 sec)

COUNT_ADDRINFO_TRANSIENT_ERRORS: 0

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

表中各字段含义如下:

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

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

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

图片 8

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

按照帐号、主机名、用户名为分组对状态变量进行分类数据,例如:按照帐号表统计的表分组列为host和user列,聚合列当然就是状态变量本身(该功能是MySQL
5.7版本新增的),有如下几张表:

注意:对于replication_connection_configuration表,不允许执行TRUNCATE
TABLE语句。

+————–+—————+

复制信息统计表

COUNT_ADDRINFO_PERMANENT_ERRORS: 0

该表中记录的是从库IO线程的连接状态信息(也记录组复制架构中其他节点的连接信息,组复制架构中一个节点加入集群之前的数据需要使用异步复制通道进行数据同步,组复制的异步复制通道信息在show
slave
status中不可见),我们先来看看表中记录的统计信息是什么样子的。

发表评论

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