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.

[MySQL Reference Manual] 23 Performance Schema结构,manualschema

1.1. 复制的监督

 

亚洲必赢登录 1

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

23 MySQL Performance Schema

23 MySQL Performance Schema.. 1

23.1 性能框架飞快启动… 3

23.2 性能框架配置… 5

23.2.1 性能框架编译时配置… 5

23.2.2 性能框架启动配置… 6

23.2.3 启动时性能框架配置… 8

23.2.3.1 性能架构事件定时… 8

23.2.3.2 性能框架事件过滤… 9

23.2.3.3 事件预过滤… 10

23.2.3.4命名记录点或者消费者的过滤… 12

23.2.3.5 识别哪些已经被记录… 12

23.3 性能框架查询… 13

23.4 性能框架记录点命名约定… 13

23.5 性能框架和景色监控… 15

23.6 性能框架和分子原子性事件… 17

23.7 性能框架statement digests17

23.8 性能框架常用表特性… 19

23.9 性能框架表描述… 19

23.9.1 性能框架表索引… 19

23.9.2 性能框架setup表…
19

23.9.2.1 setup_actors表… 19

23.9.2.2 setup_consumers表… 20

23.9.2.3 setup_instruments表… 20

23.9.2.4 setup_objects表… 21

23.9.2.5 setup_timers表… 22

23.9.3 性能框架实例表… 22

23.9.3.1 cond_instances表… 22

23.9.3.2 file_instances表… 22

23.9.3.3 mutex_instances表… 22

23.9.3.4 Rwlock_instances表… 23

23.9.3.5 socket_instance表… 23

23.9.4 性能框架事件等待表… 25

23.9.4.1 events_waits_current表… 26

23.9.4.2 Events_waits_history表… 28

23.9.4.3 events_waits_history_long 表… 28

23.9.5 性能框架Stage事件表…
28

23.9.5.1 events_stages_current表… 30

23.9.5.2 events_stage_history表… 30

23.9.5.3 events_stage_history_long表… 31

23.9.6 性能框架语句事件表… 31

23.9.7 性能框架事务表… 32

23.9.8 性能框架连接表… 35

23.9.9 性能框架连接属性表… 35

23.9.10 性能框架用户变量表… 35

23.9.11 性能框架复制表… 36

23.9.11.1
replication_connection_configure表…
38

23.9.11.2
replication_connection_status38

23.9.11.3 replication_applier_configure.
39

23.9.11.4
replication_applier_status39

23.9.11.5
replication_applier_status_by_coordinator39

23.9.11.6
replication_applier_statys_by_worker40

23.9.11.7
replication_group_members40

23.9.11.8
replication_group_member_status40

23.9.12 性能框架锁相关表… 41

23.9.12.1 metadata_locks41

23.9.12.2 table_handles42

23.9.13 性能框架连串变量表… 42

23.9.14 性能框架系列状态变量表… 43

23.9.15 性能框架计算表… 43

23.9.16 性能框架其余表… 44

23.10 性能框架选项和变量… 45

23.11 性能框架命令选项… 45

23.12 性能框架连串变量… 45

23.13 性能框架状态变量… 45

23.14 性能框架内存分配模型… 45

23.15 性能框架和…
46

23.16 使用性能框架诊断… 47

23.17 迁移到性能框架体系和状态变量表… 47

 

MySQL Performance Schema用来监督MySQL
Server的运行运行在尾部。性能框架有那个特点:

·         性能框架提供了一种办法检查其中的劳务运行。通过PERFORMANCE_SCHEMA存储引擎和performance_schema完结。性能框架紧要关心于数据性能。和INFORMANCE_SCHEMA不同,INFORMACE_SCHEMA紧要检查元数据。

·         性能框架监控服务事件,事件是劳务要求花时间的别样东西,并且一度被记录如此时间新闻可以被采集。平常一个事变能够是一个函数调用,一个操作系统等待,SQL语句执行的等级比如解析或者排序,或者全部讲话或者一组语句。时间采访提供。时间采集提供了合伙调用文件和表IO,表锁等新闻。

·         性能框架事件的风浪和binlog的风浪,事件调度的轩然大波分化。

·         性能框架事件被指定到某个MySQL服务。性能框架表外人自身是本土服务,他们的改动不会被写入到binary
log,也不会被复制。

·         当前事变,历史事件和事件下结论是可用的,那么就能够规定记录被启动了有些次,用了有些时间。事件新闻能够查阅指定线程的运动依旧指定对象的运动,比如文件和信号量。

·         PERFORMANCE_SCHEMA存储引擎使用代码中的记录点来收集信息。

·         收集的音信被保存在performance_schema数据库中。能够用select查询。

·         性能框架配置可以动态的被涂改,通过改动performance_schema数据库配置数据搜集。

·         Performance_schema上的表是视图或者临时表,不会保留到磁盘中。

·         MySQL援助所有平台的监督。

·         通过在源代码中投入记录点落成数量搜集。没有特定线程使用相关的性能框架。

1.1.1. show  master status

作用:查询master的Binary Log状态。

mysql> show master status

    -> ;

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

| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
Executed_Gtid_Set |

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

| mysql-bin.000007 |     2246 |              |                  |
                  |

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

1 row in set (0.00 sec)

 

本条命令需求super或者replication client权限,否则出现上面的不肯访问错误。

 

mysql> show master status;

ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER,
REPLICATION CLIENT privilege(s) for this operation

 

产品 沃趣科技(science and technology)

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

23.1 性能框架疾速启动

对于性能框架要启用,必须求在MySQL编译的时候配置好。可以通过mysqld的帮带验证。如若性能框架可用输出就会带—performance_schema参数。

要是那个参数没有出现,那么代码在编译时就不帮衬性能框架。

若果性能框架可用,默许是可用的。可以经过安插文件配置:

[mysqld]
performance_schema=ON

当服务启动,发现performance_schema就会估摸早先化性能框架,可以查阅performance_schema变量检查早先化是或不是成功。

mysql> SHOW VARIABLES LIKE ‘performance_schema’;

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

| Variable_name      | Value |

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

| performance_schema | ON    |

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

以此值表示,性能框架已经可用,借使为off表示暴发错误,检查错误日志。

性能框架达成和储存引擎类似。如若引擎可用可以在show
engine查看是还是不是支持PERFORMANCE_SCHEMA存储引擎。

Performance_schema中的数据库可以被剪切为几块,当前岁月,历史事件,统计,对象实例和装置消息。

本来,其实并不是所有的记录点和收集器都是可用。所以性能框架不会采集所有的数据。可以通过以下语句打开装有的积累点和收集器:

mysql> UPDATE setup_instruments SET ENABLED = ‘YES’, TIMED =
‘YES’;

Query OK, 560 rows affected (0.04 sec)

mysql> UPDATE setup_consumers SET ENABLED = ‘YES’;

Query OK, 10 rows affected (0.00 sec)

眼下事件表,可以通过events_waits_current查看当前劳动在做如何。每个线程都有一行。

历史表,表结构和当下事件相同,event_waits_history和event_waits_history_long表包涵了种种线程近年来10个event和每个线程近来10000个events。

一个新的风云被参加,老的轩然大波就会去除。

总结表提供了有着事件的联谊的音讯。这一个表经过分组一两样形式计算事件数量。为了查看那一个记录点呗执行的次数最多或者等待事件最长,通过对表上的count_star或者sum_timer_wait列举办排序:

mysql> SELECT EVENT_NAME, COUNT_STAR

    -> FROM events_waits_summary_global_by_event_name

    -> ORDER BY COUNT_STAR DESC LIMIT 10;

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

| EVENT_NAME                                        | COUNT_STAR |

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

| wait/synch/mutex/mysys/THR_LOCK_malloc            |       6419 |

| wait/io/file/sql/FRM                              |        452 |

| wait/synch/mutex/sql/LOCK_plugin                  |        337 |

| wait/synch/mutex/mysys/THR_LOCK_open              |        187 |

| wait/synch/mutex/mysys/LOCK_alarm                 |        147 |

| wait/synch/mutex/sql/THD::LOCK_thd_data           |        115 |

| wait/io/file/myisam/kfile                         |        102 |

| wait/synch/mutex/sql/LOCK_global_system_variables |         89 |

| wait/synch/mutex/mysys/THR_LOCK::mutex            |         89 |

| wait/synch/mutex/sql/LOCK_open                    |         88 |

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

 

mysql> SELECT EVENT_NAME, SUM_TIMER_WAIT

    -> FROM events_waits_summary_global_by_event_name

    -> ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

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

| EVENT_NAME                             | SUM_TIMER_WAIT |

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

| wait/io/file/sql/MYSQL_LOG             |     1599816582 |

| wait/synch/mutex/mysys/THR_LOCK_malloc |     1530083250 |

| wait/io/file/sql/binlog_index          |     1385291934 |

| wait/io/file/sql/FRM                   |     1292823243 |

| wait/io/file/myisam/kfile              |      411193611 |

| wait/io/file/myisam/dfile              |      322401645 |

| wait/synch/mutex/mysys/LOCK_alarm      |      145126935 |

| wait/io/file/sql/casetest              |      104324715 |

| wait/synch/mutex/sql/LOCK_plugin       |       86027823 |

| wait/io/file/sql/pid                   |       72591750 |

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

如,下面结果THR_LOCK信号量是看好,2个语句分别表示执行的光热和等候事件长度。

实例表,记录了目的类型被记录了。当服务应用了一个记下对象,那么会生出一个风浪。这个表提供了风云名,解释性的注释或者状态。比如file_instances表,记录了文本io操作和她俩相应的文本。

mysql> SELECT * FROM file_instances\G

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

 FILE_NAME: /opt/mysql-log/60500/binlog.000007

EVENT_NAME: wait/io/file/sql/binlog

OPEN_COUNT: 0

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

 FILE_NAME: /opt/mysql/60500/data/mysql/tables_priv.MYI

EVENT_NAME: wait/io/file/myisam/kfile

OPEN_COUNT: 1

*************************** 3. row ***************************

 FILE_NAME: /opt/mysql/60500/data/mysql/columns_priv.MYI

EVENT_NAME: wait/io/file/myisam/kfile

OPEN_COUNT: 1

...

Setup表用来配置和督查特点的,比如setup_timers表:

mysql> SELECT * FROM setup_timers;

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

| NAME        | TIMER_NAME  |

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

| idle        | MICROSECOND |

| wait        | CYCLE       |

| stage       | NANOSECOND  |

| statement   | NANOSECOND  |

| transaction | NANOSECOND  |

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

Setup_instruments列了怎么可以被记录的事件。然后经过改动那几个表开控制是或不是启动这么些记录。

mysql> UPDATE setup_instruments SET ENABLED = 'NO'

    -> WHERE NAME = 'wait/synch/mutex/sql/LOCK_mysql_create_db';

特性框架使用,收集来的风云来更新到performance_schema数据库,数据库作为事件音讯的顾客。Setup_consumers表列出了可用的买主。

支配是或不是性能框架爱抚一个主顾作为事件音讯的对象。可以安装为enabled值。

1.1.2. show  slave hosts

效果:查询已经登记到master上的slave的新闻。

mysql> show slave hosts;

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

| Server_id | Host | Port | Master_id | Slave_UUID
                          |

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

|       103 |      | 3306 |       101 |
a2392929-6dfb-11e7-b294-000c29b1c103 |

|       102 |      | 3306 |       101 |
a2392929-6dfb-11e7-b294-000c29b1c102 |

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

2 rows in set (0.00 sec)

 

Server_id:slave上的MySQL的server_id。

Host:slave的主机名。

Port:slave上的MySQL的端口号。

Master_id:master上的MySQL的server_id。

Slave_UUID:slave上的MySQL的UUID。

 

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
找到日志:

23.2 性能框架配置

1.1.3. show  slave  status

作用:查询slave的状态。

mysql> show slave status\G

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

               Slave_IO_State: Waiting for master to send event
                

  Master_Host: mysql101.coe2coe.me

                  Master_User: repl

                  Master_Port: 3306

                Connect_Retry: 60

              Master_Log_File: mysql-bin.000007

          Read_Master_Log_Pos: 2781

               Relay_Log_File: mysql102-relay-bin.000016

                Relay_Log_Pos: 2994

        Relay_Master_Log_File: mysql-bin.000007

             Slave_IO_Running: Yes

            Slave_SQL_Running: Yes

              Replicate_Do_DB:

          Replicate_Ignore_DB:

           Replicate_Do_Table:

       Replicate_Ignore_Table:

      Replicate_Wild_Do_Table:

  Replicate_Wild_Ignore_Table:
mysql.%,information_schema.%,performance_schema.%,sys.%

                   Last_Errno: 0

                   Last_Error:

                 Skip_Counter: 0

          Exec_Master_Log_Pos: 2781

              Relay_Log_Space: 3370

              Until_Condition: None

               Until_Log_File:

                Until_Log_Pos: 0

           Master_SSL_Allowed: No

           Master_SSL_CA_File:

           Master_SSL_CA_Path:

              Master_SSL_Cert:

            Master_SSL_Cipher:

               Master_SSL_Key:

        Seconds_Behind_Master: 0

Master_SSL_Verify_Server_Cert: No

                Last_IO_Errno: 0

                Last_IO_Error:

               Last_SQL_Errno: 0

               Last_SQL_Error:

  Replicate_Ignore_Server_Ids:

             Master_Server_Id: 101

                  Master_UUID: a2392929-6dfb-11e7-b294-000c29b1c101

             Master_Info_File: /opt/mysql/data/master.info

                    SQL_Delay: 0

          SQL_Remaining_Delay: NULL

      Slave_SQL_Running_State: Slave has read all relay log; waiting
for more updates

           Master_Retry_Count: 86400

                  Master_Bind:

      Last_IO_Error_Timestamp:

     Last_SQL_Error_Timestamp:

               Master_SSL_Crl:

           Master_SSL_Crlpath:

           Retrieved_Gtid_Set:

            Executed_Gtid_Set:

                Auto_Position: 0

         Replicate_Rewrite_DB:

                 Channel_Name:

           Master_TLS_Version:

1 row in set (0.00 sec)

 

 

多少个紧要的条款的意义如下:

Slave_IO_Running: slave上的和master的用来复制的网络连接的IO线程是或不是在运行中,用于收纳来自master的Binary Log,并保留到slave本地的Relay Log中。

Master_Log_File: mysql-bin.000007 读取master上的那些Binary Log文件。

Read_Master_Log_Pos: 2781 读取的master上的Binary Log的位置。

Relay_Log_File: mysql102-relay-bin.000016 本地保存的Relay Log文件。

Relay_Log_Pos: 2994  本地保存的Relay Log的职责。

 

Slave_SQL_Running: slave上的SQL线程是不是在运行中,用于读取slave本地的Relay Log,并实施其中的数据库操作,然后保留到slave本地的Binary Log中。

Relay_Master_Log_File: mysql-bin.000007 正在共同master上的Binary Log文件。

Exec_Master_Log_Pos: 2781 正在同步的地点。

 

Seconds_Behind_Master:slave的SQL线程执行的风云的日子戳和IO线程已封存的轩然大波的日子戳的差值。此值为0意味复制性能卓绝。此值用于描述slave相对于master的延迟的秒数,不过实际上在越发境况下只可以显示出slave的IO线程和SQL线程之间的推移。在slave和master之间的网络通信情状不好时,此值为0,不过slave和master之间可能已经不一起了。

 

 

不知不觉中,performance_schema体系快要接近尾声了,前天将率领大家一齐踏上铺天盖地第六篇的道路(全系共6个篇章),在这一期里,我们将为大家无微不至授课performance_schema中的复制状态与变量计算表。下边,请跟随我们一道初步performance_schema系统的学习之旅吧~

亚洲必赢登录 2

23.2.1 性能框架编译时安顿

为了让性能框架启用必须在编译时被安插,由法定提供的MySQL是支持性能框架的,如果是其他公布方公布的,那么要先检查是或不是协理。

倘假设从源代码公布的,那么在通知的时候要先安装:

shell> cmake . -DWITH_PERFSCHEMA_STORAGE_ENGINE=1

在MySQL 5.7.3随后,也足以支撑启动性能框架,可是不包括所有的记录点,比如:

shell> cmake . -DWITH_PERFSCHEMA_STORAGE_ENGINE=1 \

        -DDISABLE_PSI_STAGE=1 \

        -DDISABLE_PSI_STATEMENT=1

比方您安装MySQL到一个老的安装上,并且没有部署过性能框架,当确保performance_schema数据库包涵了装有的眼前表后,可以接纳mysql_upgrade启动服务。然后重启,有个迹象要尤其留心:

[ERROR] Native table ‘performance_schema’.’events_waits_history’
has the wrong structure
[ERROR] Native table
‘performance_schema’.’events_waits_history_long’has the wrong
structure

通过以下查看mysql是或不是扶助性能框架:

shell> mysqld –verbose –help

  –performance_schema

                      Enable the performance schema.

  –performance_schema_events_waits_history_long_size=#

                      Number of rows in events_waits_history_long.

也可以由此连接到服务之后选择show engine查看是还是不是存在PERFORMANCE_SCHEMA存储引擎。若是在build的时候从不被安顿那么show engines不会突显PERFORMANCE_SCHEMA存储引擎。

1.1.4. start slave

成效:启动slave复制相关线程,包含IO线程和SQL线程,也得以单独启动IO线程或者独立启动SQL线程。

语法:

START SLAVE [thread_types] [until_option] [connection_options]
[channel_option]

 

thread_types:指定要开动的线程类型。

    [thread_type [, thread_type] … ]

 

线程类型包涵IO_THREAD和SQL_THREAD。

 

until_option:指定复制截止地点。

    UNTIL {   {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set

          |   MASTER_LOG_FILE = ‘log_name’, MASTER_LOG_POS =
log_pos

          |   RELAY_LOG_FILE = ‘log_name’, RELAY_LOG_POS = log_pos

          |   SQL_AFTER_MTS_GAPS  }

 

行使Binary Log格局的复制时,指定MASTER_LOG_FILE和MASTER_LOG_POS参数,使用GTID形式的复制时,指定SQL_BEFORE_GTIDS和SQL_AFTER_GTIDS参数。

 

mysql> start slave;

Query OK, 0 rows affected (0.02 sec)

 

01

image.png

23.2.2 性能框架启动配置

一经性能框架是可用的,那么默许是开行的也足以在安插文件中配置:

[mysqld]
performance_schema=ON

假如服务无法在伊始化性能框架的时候分配内部缓存,那么性能框架自己关闭并且安装performance_schema为off,服务在向来不记录点情形下运行。

性能框架可以以命令行参数方式安排。

–performance-schema-instrument=’instrument_name=value

关门所有记录点:

–performance-schema-instrument=’%=OFF’

相比较长的笔录点名会比短的累积点名要优先于短的情势名,不管顺序。

切切实实可以看后边章节:23.2.3.4命名记录点或者消费者的过滤

一个无法别识其余记录点名会被忽视。为了控制消费者,可以接纳以下选项:

–performance-schema-consumer-consumer_name=value

consumer_name是一个主顾名比如events_waits_history,value是以下一个值:

l  OFF,False或者0:不采访那个消费者的事件

l  ON,True或者1:收集消费者的轩然大波

比如消费者名是events_waits_history:

--performance-schema-consumer-events-waits-history=ON

被允许的消费者名可以在setup_consumers表上找到。在表中消费者名字都是下划线,在增选配置的时候,下划线和减号没有不相同。

特性框架提供了重重系统变量可以用来配置:

mysql> SHOW VARIABLES LIKE 'perf%';

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

| Variable_name                                          | Value   |

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

| performance_schema                                     | ON      |

| performance_schema_accounts_size                       | 100     |

| performance_schema_digests_size                        | 200     |

| performance_schema_events_stages_history_long_size     | 10000   |

| performance_schema_events_stages_history_size          | 10      |

| performance_schema_events_statements_history_long_size | 10000   |

| performance_schema_events_statements_history_size      | 10      |

| performance_schema_events_waits_history_long_size      | 10000   |

| performance_schema_events_waits_history_size           | 10      |

| performance_schema_hosts_size                          | 100     |

| performance_schema_max_cond_classes                    | 80      |

| performance_schema_max_cond_instances                  | 1000    |

...

Performance_Schema表示了性能框架是或不是启动,其余参数表示表的大小伙内存分配的值。

可以运用布置文件开设置那一个变量:

[mysqld]

performance_schema

performance_schema_events_waits_history_size=20

performance_schema_events_waits_history_long_size=15000

若是没有点名值,那么默许那一个变量会有一个默许值。在MySQL
5.7.6,性能框架分配内存会根据服务符合扩大伙子裁减,而不是在劳动启动的时候四次性分配完了。所以众多参数并不须求在起步的时候都分配好,愈多内容可以看23.12
性能框架连串变量。

各样机关分配的参数不是在启动时设置或者设置为-1,性能框架决定如何依照以下的参数来设置那个值:

max_connections

open_files_limit

table_definition_cache

table_open_cache

若果要遮盖机关安装的值或者机关范围的值,就在起步的时候设置一个加以的值而不是给-1如此性能框架就会设置一个加以的值。

在运行时,show variables会展现自动安装的值,自动范围设置的会给-1.假若性能框架被禁用,自动安装和机关范围参数都会被装置为-1,并且呈现为-1.

1.1.5. stop slave

效果:甘休slave上的复制相关线程。

语法:

STOP SLAVE [thread_types]

thread_types:

    [thread_type [, thread_type] … ]

 

thread_type: IO_THREAD | SQL_THREAD

 

 

mysql>   stop slave;

Query OK, 0 rows affected (0.00 sec)

 

 

复制音讯总结表

查看这些ID为332的那张表,发现那张表是电动创建的,创制的时候没有点名存储引擎,所以基本都出错了

23.2.3 启动时性能框架配置

1.1.6. reset  slave

功能:清除slave上安装的复制关系。

语法:RESET SLAVE [ALL]

 

reset slave命令将免去slave上的有关master的复制新闻,比如slave保存在master.info文件中的master上的Binary Log文件的职位;还会去除slave本地的Relay Log文件。

reset slave命令并不会去掉mysql.gtid_executed数据表或gtid_purged系统变量;reset slave命令也不会免去关于slave和master的接连参数,比如master的IP地址和端口。

reset slave all除了拔除reset slave清除掉的情节之外,还会去掉slave和master的连日参数。

 

mysql> stop slave;

Query OK, 0 rows affected (0.01 sec)

 

mysql> reset slave all;

Query OK, 0 rows affected (0.00 sec)

 

平凡,DBA或相关数据库运维人士在翻看从库的复制相关的音讯,都习惯性的运用show
slave
status语句查看。也许你会说,我也会用performance_schema下的表查看一些复制报错音讯什么的。可是,你领会show
slave
status语句、mysql系统库下的复制音信记录表、performance_schema系统库下的复制音信记录表之间有啥样分别呢?不知底?别急,本文即将为你详细介绍show
slave
status语句与performance_schema系统库下的复制音讯记录表的区分(mysql系统库下的复制表不同详见后续
“mysql系统库全方位介绍”系列)。

23.2.3.1 性能架构事件定时

事件被采访也就是说记录点被加到了服务源代码中。记录点时间事件,是性质框架怎么着提供一个事件不断多长时间的方案。也能够计划记录点收集定时信息。

性能框架定时器

2个属性框架表提供了定时器音讯:

l  Performance_timers,保存了可用的timers和它们的表征。

l  Setup_timers,表明了怎么着记录点使用了哪个timers。

每个setup_timers使用的计时器躲在performance_timers表中。

mysql> SELECT * FROM performance_timers;

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

| TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD
|

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

| CYCLE       |      2389029850 |                1 |             72 |

| NANOSECOND  |      1000000000 |                1 |            112 |

| MICROSECOND |         1000000 |                1 |            136 |

| MILLISECOND |            1036 |                1 |            168 |

| TICK        |             105 |                1 |           2416 |

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

TIMER_NAME:表示可用timer的名字,CYCLE表示给予cpu计数器

TIMER_FREQUENCY:表示每秒的timer个数。对于cycle timer,频率和cpu事件有关,其余timer是秒的好多分。

TIMER_RESOLUTION:表示每一回扩充的单位

TIMER_OVERHEAD:指定周期获取一个定时要求的小不点儿cycles个数。每个事件都会在早先和竣事的时候调用timer,因而是显得的载荷的2倍。

修改setup_timer表的timer_name:

mysql> UPDATE setup_timers SET TIMER_NAME = ‘MICROSECOND’

    -> WHERE NAME = ‘idle’;

mysql> SELECT * FROM setup_timers;

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

| NAME        | TIMER_NAME  |

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

| idle        | MICROSECOND |

| wait        | CYCLE       |

| stage       | NANOSECOND  |

| statement   | NANOSECOND  |

| transaction | NANOSECOND  |

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

默许性能框架会为每个记录点类型设置timer,也得以修改。

对于记录等待事件的年华,最重点的是在时刻精度上减小负荷,所以采纳cycle
timer最合适。

对于说话或者stage的进行比执行一个简约的等待要大的多,并且须求一个确切的量,并且和电脑无关,所以最好不要选用cycle。默认使用NANOSECOND。固然负荷比cycle要大,不过不根本,因为调用2次计数器的多寡级远远比举行语句我的cpu时间要小。

Cycle提供的精度和cpu有关,假设处理器是1Gh或者更高,cycle可以提供比毫秒还小的快慢。使用cycle计数器比得到一个一天的莫过于事件支出小。

Cycle的缺点:

l  从cycles转化为时间单位是相比较麻烦的。为了更快,那一个转化操作知识很粗糙的乘法计算。

l  处理器cycle,可能会遍,比如台式机进入省电情势,那么cpu
cycle会下降即使cpu cycle有动乱,那么转化就会出错。

l  Cycle 计数器可能是不可相信的依旧不可用的,和电脑或者操作系统有关。

l  一些电脑,乱序执行或者多处理器同步,可能会招致计数器忽高忽低。

特性框架计数器在事变中的表现

积存在性能框架表的当下事件,有3个列表示事件,TIMER_START,TIMER_END表示事件启动和停止,TIMER_WAIT表示事件的年月。

Set_instruments表有ENABLED字段来代表,事件是或不是要收集。TIMED字段表示记录点是不是被时光标记。假如记录点没有启动,那么就不会变卦事件。如若不是timed,那么生成的事件,中TIMER_START,TIME_END,TIMER_WAIT是null。那么在计算表总结最大时间,最时辰间的时候会被忽略。

内部,事件启动的时候,timer以给定的单位保存在事件之中,当要显得的时候,timers被出示为正式的风云单位,不管选了何等timer都会展现为,阿秒。

Setup_timers的修改会立即见效。已经在处理的会动用老的timer。为了不造成不可能预料的结果出现,最好先把总计表使用truncate
table进行重置。

提姆(Tim)er的基线,在劳动启动的时候被开端化。TIMER_START,TIMER_END表示从基线以来的皮秒数。TIMER_WAIT表示占用的飞秒。

1.1.7. reset master

reset master命令将去除在mysql-bin.index文件中列出的保有的Binary Log文件;同时还会清空gtid_purged这些只读的系统变量;同时还会清空mysql.gtid_executed数据表。那个操作使得slave将从初始地方再一次展开与master的同台。

 

mysql> reset master;

Query OK, 0 rows affected, 1 warning (0.04 sec)

 

 

在开班详细介绍每一张复制消息表以前,大家先开销一些篇幅来完全认识一下那些表。

23.2.3.2 性能框架事件过滤

事件是以生产者消费者方式处理的:

l  记录点代码是事件的源,暴发事件被用来采访,setup_instruments表列出了可以被采集的记录点。Setup_instruments表提供了广大event的爆发。

l  性能框架表示事件的目标地。Setup_consumers,列出了所有顾客类型。

预过滤,通过改动性能框架配置完毕,可以通过启用或者剥夺记录点和消费者完结。使用预过滤的目标:

n  减弱负荷。性能框架运行需求费用资源,尽管很少。

n  不拥戴的轩然大波可以不写入消费者中。

n  幸免维护七个项目标事件表。

·           事后过滤,可以应用where语句在询问性能框架的时候过滤。

1.1.8. 接连处境

 

使用性能数据库中的复制相关数据表,可以查看复制相关的性能数据。

 

mysql> use performance_schema;

Database changed

 

复制连接配置表:

mysql> select * from replication_connection_configuration\G

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

                 CHANNEL_NAME: master111

                         HOST: 192.168.197.111

                         PORT: 3306

                         USER: repl

            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: 30.000

                  TLS_VERSION:

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

                 CHANNEL_NAME: master110

                         HOST: 192.168.197.110

                         PORT: 3306

                         USER: repl

            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: 30.000

                  TLS_VERSION:

2 rows in set (0.00 sec)

 

 

 

 

复制连接状态表:

 

mysql> select * from replication_connection_status\G

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

             CHANNEL_NAME: master111

               GROUP_NAME:

              SOURCE_UUID: a2392929-6dfb-11e7-b294-000c29b1c111

                THREAD_ID: 35

            SERVICE_STATE: ON

COUNT_RECEIVED_HEARTBEATS: 36

 LAST_HEARTBEAT_TIMESTAMP: 2017-08-18 12:54:09

 RECEIVED_TRANSACTION_SET: a2392929-6dfb-11e7-b294-000c29b1c111:1-11

        LAST_ERROR_NUMBER: 0

       LAST_ERROR_MESSAGE:

     LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00

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

             CHANNEL_NAME: master110

               GROUP_NAME:

              SOURCE_UUID: a2392929-6dfb-11e7-b294-000c29b1c110

                THREAD_ID: 33

            SERVICE_STATE: ON

COUNT_RECEIVED_HEARTBEATS: 35

 LAST_HEARTBEAT_TIMESTAMP: 2017-08-18 12:54:03

 RECEIVED_TRANSACTION_SET: a2392929-6dfb-11e7-b294-000c29b1c110:1-6

        LAST_ERROR_NUMBER: 0

       LAST_ERROR_MESSAGE:

     LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00

2 rows in set (0.00 sec)

 

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

23.2.3.3 事件预过滤

预过滤有总体性框架形成同时会全局的熏陶所有用户。预过滤能够在劳动者或者消费者的处理阶段上:

·           几个表可以用来配置生产者的预过滤:

§   Setup_instruments表达哪个记录点是可用的,如若那一个表上一个记录点被禁用,不管别的表怎么布局,都不会再发生事件。

§   Setup_objects控制了性能框架特定表和存储进度对象。

§   Threads表示是否各类服务线程都有监控

§   Setup_actors新的后台进度的开首监控状态

·           要布局预过滤在顾客阶段,那么要修改setup_comsumers表。setup_comsumers也会潜移默化事件的发出。假若指定的轩然大波不会发送给任哪儿方,那么性能框架不会发生

修改任意表都会应声影响监控,可是有些不一致:

·         修改某些setup_instruments表只有的劳务启动的时候生效。在运作时修改不会生效。

·         修改setup_actors表,只会影响后台线程。

当修改监控配置,性能框架不会刷新历史表。历史表和眼前表的风浪不会被替换,除非又新的风云。倘若禁用一个记录点的时候,要求拭目以待一段时间,来替换老的事件。也可以用truncate
table清空。

在修改完记录点之后,可能下极度药伤处summary表清理总计音信对于events_statements_summary_by_digest或者内存总计表。Truncate table只会重置值为0,并不会去除行。

  • 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
23.2.3.3.1 记录点预过滤

支配记录点的过滤,是过滤setup_instruments表设置enables字段。修改setup_instruments一大半会即时见效。对于某些记录点,修改只会在服务器启动才会生效。setup_instruments提供了最基本的记录点控制。

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

23.2.3.3.2 对象预过滤

Setup_objects表控制了性能框架部分表和储存进程。修改Setup_objects会即时相应。

mysql> SELECT * FROM setup_objects;

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

| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME | ENABLED | TIMED |

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

OBJECT_TYPE:表示对象类型,比如表或者事件,存储进程等。

OBJECT_SCHEMA和OBJECT_NAME包涵了schema或者目标名的字符串,也足以是通配符

ENABLED列表示对象是否被监督,TIMED列表示是不是收集timing音信。

默许会收集除了mysql,information_schema,performance_schema外所有的的数据库对象。

  • 在实施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时那个表就被填充相应多线程工作线程的音信
23.2.3.3.3 线程预过滤

threads表为种种线程保存了一行数据。每行数据都包括了线程的新闻并且申明是还是不是被监督。对于性能框架监控一个线程必须餍足一下他条件:

·         表sestup_consumers表中的thread_instrumentation必须为yes

·         Threads.instrumented列必须为yes

·         只监控setup_instruments表中的记录点

threads表也验证了各种服务线程是还是不是进行历史事件记录。若是要记录历史事件以下条件都必须为真:

·         对应的主顾配置,setup_consumers表必须为yes。

·         Threads.HISTORY列必须为yes。

·         只监控setup_instruments表中的记录点

对此后台线程,instrumented和history的发端数据,取决于setup_action中的配置。

mysql> SELECT * FROM setup_actors;

+——+——+——+———+———+

| HOST | USER | ROLE | ENABLED | HISTORY |

+——+——+——+———+———+

| %    | %    | %    | YES     | YES     |

+——+——+——+———+———+

thread表的instrumented和history的条条框框如下:

·         假设最佳匹配,enabled=yes,那么instrumented=yes,最佳匹配history=yes,那么threads表的history=yes

·         假若最佳匹配,enabled=no,那么instrumented=no,最佳匹配history=no,那么threads表的history=no

·         假设不可以协作,那么instrumented,history都为no

在mysql 5.7.6 往日,没有enabled字段,只要有同盟,那么instrumented=yes

在mysql5.7.8,此前,没有history字段,线程要不全体方可进入history要不都不能,取决于setup_consumer的配置。

默认,后台的具备线程都是会被记录的,因为setup_actors有一行都是‘%’。

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 中不够的内容如下:

23.2.3.3.4 消费者预过滤

Setup_cunsumers表包涵了有着的消费者。修改这几个表来过滤那个event会被发送。

Setup_consumers表中装置消费者,从高级到低级。主要的规范如下:

·           除非性能框架检查消费者,并且消费者是可用的,不然不会受到新闻。

·           唯有当消费者看重的富有的买主都可用了,才会被检查

·           被依赖的主顾,有温馨的借助消费者。

·           假使一个事件没有目标,那么性能框架不会被暴发。

大局和线程消费者

·           Global_instrumentation是高等消费者,若是global_instrumentation为no,那么具有的的全局记录点都被剥夺。所有其余低级的都不会被检查。当global_instrumentation启动了,才会去反省thread_instrumentation

·           Thread_instrumentation,假若是no,那么这么些级别上边的级别都不会被检查,假诺是yes,性能框架就会爱戴线程指定音讯,并且检查events_xxx_current消费者。

Wait Event消费者

这一个消费者,要求global_instrumentation,thread_instrumention为yes。如若被检查行为如下:

·           Events_waits_current,假如为no,禁用对各类wait
event收集。假设为yes检查history消费者和history_Mysql主从同步错误,复制状态与变量记录表。long消费者。

·           Events_waits_history,假设上级为no不检讨,为yes,收集各类等待事件。

·           Events_waits_history_long,和地点类似

Stage event,statement event和上边类似。

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

23.2.3.4命名记录点或者消费者的过滤

可以对点名记录名或者消费者进行过滤:

mysql> UPDATE setup_instruments

    -> SET ENABLED = ‘NO’

    -> WHERE NAME =
‘wait/synch/mutex/myisammrg/MYRG_INFO::mutex’;

 

mysql> UPDATE setup_consumers

    -> SET ENABLED = ‘NO’ WHERE NAME = ‘events_waits_current’;

指定一组记录点或者消费者:

mysql> UPDATE setup_instruments

    -> SET ENABLED = ‘NO’

    -> WHERE NAME LIKE ‘wait/synch/mutex/%’;

 

mysql> UPDATE setup_consumers

    -> SET ENABLED = ‘NO’ WHERE NAME LIKE ‘%history%’;

PS1:正如系统状态变量被移动到了那一个复制状态表中进行记录(MySQL
5.7.5版以前运用以下状态变量查看):

23.2.3.5 识别哪些已经被记录

经过检查setup_instruments表,你可以得知包涵了怎样记录点被记录:

mysql> SELECT * FROM setup_instruments WHERE NAME LIKE
‘wait/io/file/innodb/%’;

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

| NAME                                 | ENABLED | TIMED |

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

| wait/io/file/innodb/innodb_data_file | YES     | YES   |

| wait/io/file/innodb/innodb_log_file  | YES     | YES   |

| wait/io/file/innodb/innodb_temp_file | YES     | YES   |

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

  • Slave_retried_transactions
  • Slave_last_heartbeat
  • Slave_received_heartbeats
  • Slave_heartbeat_period
  • Slave_running

23.3 性能框架查询

预过滤限制了怎么事件讯息被采访,很多用户都不一致。能够透过select过滤event。

mysql> SELECT THREAD_ID, NUMBER_OF_BYTES

    -> FROM events_waits_history

    -> WHERE EVENT_NAME LIKE ‘wait/io/file/%’

    -> AND NUMBER_OF_BYTES IS NOT NULL;

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

| THREAD_ID | NUMBER_OF_BYTES |

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

|        11 |              66 |

|        11 |              47 |

|        11 |             139 |

|         5 |              24 |

|         5 |             834 |

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

PS2:对于组复制架构,组复制的监督音信散布在如下几张表中

23.4 性能框架记录点命名约定

记录点命名是一串组件然后用‘/’分割:

wait/io/file/myisam/log
wait/io/file/mysys/charset
wait/lock/table/sql/handler
wait/synch/cond/mysys/COND_alarm
wait/synch/cond/sql/BINLOG::update_cond
wait/synch/mutex/mysys/BITMAP_mutex
wait/synch/mutex/sql/LOCK_delete
wait/synch/rwlock/sql/Query_cache_query::lock
stage/sql/closing tables
stage/sql/Sorting result
statement/com/Execute
statement/com/Query
statement/sql/create_table
statement/sql/lock_tables

记录点命名类似于树形结构。从左到右越来越详细,组件的名号以来与计数器类型。

名字由2有些组成:

·           组件名,比如mysiam

·           变量名,一种是全局变量,还有一种是class::value。值class类中的变量。

顶级记录点组件

·           Idle:表示idle事件的记录点。

·           Memory:memory事件记录点

·           Stage:阶段事件记录点

·           Statement:语句事件记录点

·           Transaction:事务事件记录点

·           Wait:等待事件记录点

Idle记录点组件

Idle记录点用于idle事件,具体看:23.9.3.5 socket_instance表

内存记录点组件

众多内存记录点默许是不可用的,能够手动启动,修改setup_instruments表。记录点前缀,memory/performance_schema/表示有些许性能框架之中的内存分配。memory/performance_schema/总是启用的,并且不可以被剥夺。那件记录点被采集在 memory_summary_global_by_event_name表。

Stage记录点组件

Stage代表语句阶段性处理的诸如sorting
result或者sending data。

语句记录点组件

·           Statement/abstract/*: 抽象语句操作记录点。抽象记录点在说话早期选取。

·           Statement/com :是记录点命令操作。并且盛名字对应到com_xxx操作,比如statement/com/Connect 和 statement/com/Init DB对应到COM_CONNECT和COM_INIT_DB命令。

·           Statement/scheduler/event:单个记录点用来跟踪所有事件调度生成的轩然大波。

·           Statement/sp :存储进度执行内部的记录点,比如statement/sp/cfetch
和statement/sp/freturn,用来游标获取和函数再次来到。

·           Statement/sql:sql操作的记录点,比如statement/sql/create_db和statement/sql/select,用于创造数据库和select语句。

等待记录点指令

·           Wait/io,io操作记录点

§   Wait/io/file:文件io操作记录点,对于文本,等待是伺机文件操作文件完结。因为缓存的关联,物理文件io可能在那几个操作上不会执行

§   Wait/io/socket:socket操作记录点,socket记录点有以下命名格式:wait/io/socket/sql/socket_type。服务有一个监听socket用来支撑每个网络协议。那么些记录点协助监听socket是tcpip或者unix
socket文件。socket_type的值为server_tcpip_socket或者server_unix_socket。当监听socket发现一个三番五次,服务把那些一而再转换来独门的线程。那么新的连天线程的socket_type为client_connection。

§   Wait/io/table: 表io操作记录点。包括持久性表或者临时表的行级别访问。对行的影响就是fetch,insert,update,delete。对于视图,是被视图引用的基表。和其余等待不相同,表的io等待报货其余等待。比如表io可能含有,文件io或者内存操作。因而events_waits_current中对于行的等候可能有2行。

·           Wait/lock ,锁操作的记录点

§   Wait/lock/table,表锁记录点操作

§   Wait/lock/metadata/sql/mdl,元数据所操作

·           Wait/synch,同步对象记录点

§   Wait/synch/cond,条件被用来一个线程文告其它一个线程,某些它们等待的东西已经落成。假如一个线程等待一个规则,那么会醒来并且处理。倘诺两个线程等待那么会都新来并且成功它们等待的资源。

§   Wait/synch/mutex,多排他对象用来做客一个资源,防止其余线程访问资源。

§   Wait/synch/rwlock,一个读写锁对象用来锁定特定的变量,幸免其他线程使用。一个共享读所能够八个线程同时得到。一个排他写锁只可以由一个线程获取。

§   Wait/synch/sxlock,共享排他锁是读写锁的rwlock的一种,提供当一个线程写时,其余线程可以非一致性读。Sxlock在mysql 5.7中动用为了优化rwlock的或显示。

  • replication_group_member_stats
  • replication_group_members
  • replication_applier_status
  • replication_connection_status
  • threads

23.5 性能框架和情景监控

可以拔取show status like ‘%perf%’查看性能框架的状态。

特性框架状态变量提供了有关记录点因为内存的原故并未被创立或者加载的音信。根据事态命名有几类:

·           Performance_Schema_xxx_class_lost,表示有微微xxx类型的记录点无法被加载。

·           Performance_schema_xxx_instance_lost,表示有些许xxx类型的记录点不可能被创造。

·           Performance_schema_xxx_handlees_lost,表示有多少xxx类型的记录点无法被打开。

·           Performance_schema_locker_lost,表示有稍许时间都是依然尚未被记录。

譬如说,一个信号量是记录点,但是服务不可能为记录点分配内存。那么会增多performnace_schema_mutex_classes_lost。不过信号量照旧以用于对象同步。不过性能数据就不可能被采集,要是记录点被分配,用来早先化记录点信号量实体。对于单身的信号量比如全局信号量,只有一个实例。有些信号量的实例个数会生成,比如每个连接的信号量。如若服务无法创设一个指定记录点信号量实体,就会追加,performance_schema_mutex_instance_lost。

假设有以下条件:

·           服务启动参数,–performance_schema_max_mutex_classes=200,因而有200个信号量空间。

·           150信号量已经被加载

·           插件plugin_a有40个信号量

·           插件plugin_b有20个信号量

劳务为插件,分配信号量记录点信赖于已经分配了稍稍,比如以下语句:

INSTALL PLUGIN plugin_a

那么服务一度有了150+40个信号量。

UNINSTALL PLUGIN plugin_a;

固然如此插件已经卸载,可是照旧有190个信号量。所有插件代码生成的历史数据或者实惠。可是新的记录点事件不会被分配。

INSTALL PLUGIN plugin_a;

服务意识40个记录点已经被分配,由此新的记录点不会被成立,并且此前分配的里边buffer会被再度行使,信号量如故190个。

INSTALL PLUGIN plugin_b;

以此利用可用信号量已经唯有10个了,新的插件要20个记录点。10个曾经被加载,10个会被撤消或者丢失。Performance_schema_mutex_classes_lost会标记这几个丢失的记录点。

mysql> SHOW STATUS LIKE “perf%mutex_classes_lost”;

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

| Variable_name                         | Value |

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

| Performance_schema_mutex_classes_lost | 10    |

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

1 row in set (0.10 sec)

Plugin_b任然会收集执行部分记录点。

当服务无法创建一个信号量记录点,那么会发出以下景况:

·           不会有新行被插入到setup_instruments表

·           Performance_Schema_mutex_classes_lost增加1

·           Performance_schema_mutex_instance_lost,不会转移。

地点描述的适用于所有记录点,不单单是信号量。

当Performance_Schema_mutex_classes_lost大于0那么有2种情况:

·           为了保存一些内存,你可以启动,Performance_Schema_mutex_classes=N,N小于默认值。默许值是满足加载所有插件的mysql发表。不过有些插件假如不加载可能会少一些。比如你可以不加载默写存储引擎。

·           你加载一个第三方插件,是性质框架的记录点,可是在服务启动的时候,不容许插件记录点内存获取。因为来自第三方,那个引擎的记录点内存并不会被记录在performance_schema_max_mutex_classes.
一经服务不能满意插件记录点的资源,没有浮现的分红越多的 performance_schema_max_mutex_classes,那么久会产出记录点的饥饿。

 

如果performance_schema_max_mutex_classes.太小,没有不当会被写入到错误日志,并且在运行时并未不当。但是performance_schema上的表会丢失事件。performance_schema_max_mutex_classes_lost状态变量只是标志一些事变归因于创设记录点失败被去除。

 

万一记录点没有丢失,那么就会通报性能框架,当在代码中(THD::LOCK_delete)创造了信号量,单个记录点就会被运用。那么就须要多多信号量实体。那些时候,每个线程都有lock_delete,比如有1000个线程,1000个lock_delete信号量记录点实例。

借使服务没有空间存放所有1000个信号量记录点实体,一些信号量会被创制记录点,一些就不会被制造。如果服务功效成立800个,那么此外200个会丢掉,Performance_schema_mutex_instances_lost会增加200个。

Performance_schema_mutex_instances_lost,可能在要早先化的信号量记录点大于配置的Performance_schema_mutex_instances=N那么久会发出。

只要SHOW STATUS LIKE ‘perf%’没有丢失任何事物,那么新能框架数据是足以被看重的。倘若有局地都是了,那么数量是不完整的,并且性能框架不会记录所有。那样Performance_schema_xxx_lost就证实了问题范围。

稍加时候饥饿时方可平衡的,比如你也许不须求文件io的数量,那么可以把所有性能框架参数,和文件io相关的都设置为0,那么久不会把内存分配到和文书有关的类,对象实例或者句柄中。

由此上述内容,我们从完整上可以大体通晓了performance_schema中的复制音信表记录了什么音讯,上面依次详细介绍这几个复制音信表。

23.6 性能框架和成员原子性事件

对此一个表的io事件,经常有2行在events_waits_current,不是一个如:

Row# EVENT_NAME                 TIMER_START TIMER_END
—- ———-                 ———– ———
   1 wait/io/file/myisam/dfile        10001 10002
   2 wait/io/table/sql/handler        10000 NULL

行取得会导致文件读取。比如,表io获取事件在文书io事件之前,但是还尚无达成。那么文件io嵌入在表io事件。

和其余原子性等待事件不一致,表io事件是成员,包蕴其余事件。伊芙nts_waits_current中,表io事件层见迭出有2行:

·           一行是当前表io等待事件

·           一行是别的任何项目标等候事件。

普普通通,其余类其余等候事件不是表io事件。当副事件做到,会从events_waits_current中消失。

1.replication_applier_configuration表

23.7 性能框架statement digests

MySQL服务有能力维护statement digest音讯。Digest进度把一个sql语句转化为标准的格式并且总计一个hash结果。标准化允许相似的说话分组并且计算暴光一些口舌的项目和暴发的频率。

在性质框架,语句digest涉及那几个零件:

·           Setup_comsumers的statement_digset控制了,性能框架怎么样维护digest新闻。

·           语句事件表有列包蕴digest和连锁的值的列:

§   DIGEST_TEXT,标准化的口舌。

§   DIGEST,是digest MD5 hash值。

Digest总括,最大的可用空间1024B。MySQL 5.7.8后那些值能够通过参数,performance_schema_max_digest_length修改。此前使用max_digest_length。

·           语句事件表也有sql_text列包罗了原本的sql语句。语句突显的最大为1024B,可以因而performance_schema_max_sql_text_length字段修改。

·           events_statements_summary_by_digest,提供综合的语句digset音信。

标准一个说话转化,会保留语句结构,删除不须求的音信:

·           对象标识符,比如表或者数据库名会被保存。

·           文本值会被替换成变量。

·           注释会被删除,空格会被调整。

例如如下2个语句:

SELECT * FROM orders WHERE customer_id=10 AND quantity>20

SELECT * FROM orders WHERE customer_id = 20 AND quantity > 100

轮换后会变成:

SELECT * FROM orders WHERE customer_id = ? AND quantity > ?

对此每个标准化的言辞提供一个DIGEST_TEXT和DIGEST一个hash值。语句Digest总括表,提供了讲话的profile新闻,彰显语句运行功效运行次数等。

events_statements_summary_by_digest大小固定的,所以倘使满了,即使在表上没有匹配的,那么所有的说话都会被统计在schema_name和digest为null的笔录里面,当然可以追加digest大小,performance_schema_digests_size,假设没有点名,那么性能框架会友善评估一个值。

performance_schema_max_digest_length系统变量支配digest buffer最大可用字节。然则具体的语句digest的长度往往比buffer长,那是因为根本字和文本值的涉嫌。也就是说digest_text的长度可能超越performance_schema_max_digest_length。

对此应用程序生成了很长的语句,唯有最终不相同,扩展performance_schema_max_digest_length可以让digest得以计算,识别语句。反过来缩小performance_schema_max_digest_length会导致服务捐躯很少的内存来保存语句的digest,不过增添了讲话的相似度,被当成同一个digest。假如长度要求长,那么保存的也要更加多。

可以因此show engine performance_schema
status语句,或者监察之下语句查看sql语句保存使用的内存量。

mysql> SELECT NAME FROM setup_instruments

    -> WHERE NAME LIKE '%.sqltext';

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

| NAME                                                             |

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

| memory/performance_schema/events_statements_history.sqltext      |

| memory/performance_schema/events_statements_current.sqltext      |

| memory/performance_schema/events_statements_history_long.sqltext |

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

 

mysql> SELECT NAME FROM setup_instruments

    -> WHERE NAME LIKE 'memory/performance_schema/%.tokens';

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

| NAME                                                                 |

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

| memory/performance_schema/events_statements_history.tokens           |

| memory/performance_schema/events_statements_current.tokens           |

| memory/performance_schema/events_statements_summary_by_digest.tokens |

| memory/performance_schema/events_statements_history_long.tokens      |

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

该表中记录从库线程延迟复制的配备参数(延迟复制的线程被喻为普通线程,比如CHANNEL_NAME和DESIRED_DELAY字段记录某个复制通道是不是须求实践延迟复制,即使是MGR集群,则记录组复制从节点的推移复制配置参数),该表中的记录在Server运行时可以使用CHANGE
MASTER
TO语句举行改动,大家先来看望表中记录的计算音讯是什么样样子的。

23.8 性能框架常用表特性

Performance_schema数据库是小写的,数据库里面的表名也是小写的。查询要选择小写。

多多表在performance_schema数据库是只读的不可能被涂改。一些setup表的一些列可以被涂改。一些也可以被插入和删除。事务可以被允许清理收集的风浪,所以truncate
table可以用来清理信息。

Truncate table可以在总计表上应用,然则无法再events_statements_summary_by_digest和内存统计表上运用,效果只是把一起列清理为0.

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

23.9 性能框架表描述

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

23.9.1 性能框架表索引

具体看:

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

23.9.2 性能框架setup表

Setup表提供有关当前收集点启用新闻。使用表而不是全局变量提供了更高级其他特性框架配置。比如您可以行使一个sql语句配置八个记录点。

那个setup表示可用的:

·           Setup_actors:怎么着初阶化后台线程

·           Setup_consumers:决定怎么样信息会被发送和储存。

·           Setup_instruments:记录点对象,哪些事件要被采访。

·           Setup_objects:哪些对象要被监控

·           Setup_timers:当前事件定时器。

| CHANNEL_NAME |DESIRED_DELAY |

23.9.2.1 setup_actors表

setup_actors表包蕴了音信决定是或不是监控或者对新的后台线程举办历史数据记录。这些表默许最多100行,能够通过修改参数performance_schema_setup_actors_size修改尺寸。

对此新的后台线程,在setup_actors中,性能框架满足的用户和host。假若一个行负荷enabled,histroy列,对应到threads表上的instrumented和history列。若是找不到卓殊那么instrumented和history列就为no。

对此后台线程, Instrumented和history默许都是yes,setup_actors默许没有范围。

Setup_actors初阶化内容,但是滤任何数据:

mysql> SELECT * FROM setup_actors;

+——+——+——+———+———+

| HOST | USER | ROLE | ENABLED | HISTORY |

+——+——+——+———+———+

| %    | %    | %    | YES     | YES     |

+——+——+——+———+———+

修改setup_actors表只会影响后台线程,不会潜移默化已经存在的线程。为了影响已经存在的threads表,修改instrumented和history列。

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

23.9.2.2 setup_consumers表

Setup_consumers表列了各样品类的消费者:

mysql> SELECT * FROM setup_consumers;

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

| NAME                             | ENABLED |

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

| events_stages_current            | NO      |

| events_stages_history            | NO      |

| events_stages_history_long       | NO      |

| events_statements_current        | YES     |

| events_statements_history        | YES     |

| events_statements_history_long   | NO      |

| events_transactions_current      | NO      |

| events_transactions_history      | NO      |

| events_transactions_history_long | NO      |

| events_waits_current             | NO      |

| events_waits_history             | NO      |

| events_waits_history_long        | NO      |

| global_instrumentation           | YES     |

| thread_instrumentation           | YES     |

| statements_digest                | YES     |

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

Setup_consumers设置形成从高到低的级别。形成依赖,若是高级其他设置了低级别才会有空子被检查。

|| 0 |

23.9.2.3 setup_instruments表

Setup_consumers表列了具有记录点对象:

mysql> SELECT * FROM setup_instruments;

每个记录点被扩展到源代码中,都会在这些表上有一行,即便记录点代码没有被指定。当一个记录点启动了仍然执行了,记录点实例就会被创设会突显在*_instrances表。

修改setup_instruments行会立即影响监控。对于部分记录点,修改只会在下次初叶才会收效。在指定时修改并不会一蹴而就。

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

23.9.2.4 setup_objects表

Setup_objects表控制了哪些对象的特性框架会被监督。这么些目的默许为100行可以透过改动变量来决定,performance_schema_setup_objects_size。

起首化的setup_objects如下:

mysql> SELECT * FROM setup_objects;

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

| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME | ENABLED | TIMED |

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

| EVENT       | mysql              | %           | NO      | NO    |

| EVENT       | performance_schema | %           | NO      | NO    |

| EVENT       | information_schema | %           | NO      | NO    |

| EVENT       | %                  | %           | YES     | YES   |

| FUNCTION    | mysql              | %           | NO      | NO    |

| FUNCTION    | performance_schema | %           | NO      | NO    |

| FUNCTION    | information_schema | %           | NO      | NO    |

| FUNCTION    | %                  | %           | YES     | YES   |

| PROCEDURE   | mysql              | %           | NO      | NO    |

| PROCEDURE   | performance_schema | %           | NO      | NO    |

| PROCEDURE   | information_schema | %           | NO      | NO    |

| PROCEDURE   | %                  | %           | YES     | YES   |

| TABLE       | mysql              | %           | NO      | NO    |

| TABLE       | performance_schema | %           | NO      | NO    |

| TABLE       | information_schema | %           | NO      | NO    |

| TABLE       | %                  | %           | YES     | YES   |

| TRIGGER     | mysql              | %           | NO      | NO    |

| TRIGGER     | performance_schema | %           | NO      | NO    |

| TRIGGER     | information_schema | %           | NO      | NO    |

| TRIGGER     | %                  | %           | YES     | YES   |

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

修改setup_objects表会立刻影响监控。

对于setup_objects,object_type表示监控了哪些对象类型。如果没有匹配的object_schema,object_name。那么就不会有目的没监控。

1row inset ( 0. 00sec)

23.9.2.5 setup_timers表

Setup_times表如下:

mysql> SELECT * FROM setup_timers;

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

| NAME        | TIMER_NAME  |

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

| idle        | MICROSECOND |

| wait        | CYCLE       |

| stage       | NANOSECOND  |

| statement   | NANOSECOND  |

| transaction | NANOSECOND  |

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

Timer_name是,performance_timers中的一行。表示某个事件类型应用了哪些计时器

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

23.9.3 性能框架实例表

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

23.9.3.1 cond_instances表

Cond_instance表列出了富有性能框架可以查看的规范。条件是一路机制,用来通告一个点名的轩然大波早已发出完毕。所以一个线程等待这一个条件的会应声復苏工作。

当一个线程等待的东西已经转移,条件名值表达线程在守候条件名。

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

23.9.3.2 file_instances表

当指定文件io记录点的时候,File_instances表列出了有着性能框架能来看的具有文件。倘若文件在disk不过没有被打开不会油不过生在file_instrances中。当文件在次磁盘中被删去,那么file_instances中也会去除。

| CHANNEL_NAME |DESIRED_DELAY |

23.9.3.3 mutex_instances表

Mutex_instances突显了装有可以被性能框架查看到的信号量。信号量是一道机制用来保证资源。当2个线程运行须求放问相同的资源,2个线程会相互争用,一个线程获取了mutex上的锁,那么别的一个不得不等待上一个完事。

当任务执行获取信号量,称为临界区域,区域内执行都是逐一的,可能有神秘瓶颈问题。

表中有3个字段:

Name:记录点的名字

OBJECT_INSTANCE_BEGIN:被记录的信号量在内存中的地址。

LOCKED_BY_THREAD_ID:拥有mutex的线程id,否则为null。

对于每个记录的信号量,性能框架提供一下新闻:

·         Setup_instruments表列出了笔录点名,以wait/synch/mutex/为前缀。

·         当有代码创制了信号量,那么就有一行被投入到mutex_instrances表中,OBJECT_INSTANCE_BEGIN列是mutex的绝无仅有列。

·         当一个线程视图锁定信号量,events_waits_current表为线程突显一行,表明在等待信号量,通过object_instance_begin。

·         当线程成功锁定了一个信号量:

§  Events_waits_current,突显等待信号量就会做到

§  落成的轩然大波会被添加到历史表中

§  Mutex_instances显示信号量现在属于一个thread

·         当thread unlock一个信号量,mutex_instances突显信号量现在未曾owner,thread_id为null。

·         当信号量对象被灭绝,对应的行也会被删除。

查以下2个表,可以诊断瓶颈或者死锁:

§  Events_waits_current,查看线程等待的信号量。

§  Mutex_instrances,查看其他线程的具有的信号量。

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

23.9.3.4 Rwlock_instances表

Rwlock_instances表列出了装有rwlock的实例。Rwlock是一块机制用来强制在一定规则下,在给定的事件之中能访问片段资源。那个资源被rwlock爱护。访问要不是共享艺术要不是排他情势,若是允许非一致性访问,还是能共享排他形式访问。Sxlock只有在,mysql 5.7事后才能被利用,用来优化并发性。

按照访问的须要,所的乞请要不是,共享,排他,共享排他或者不授权,等待其他线程完结。

表列如下:

·           NAME:记录点名相关的lock

·           OBJECT_INSTANCE_BEGIN:被记录的锁在内存中的地址。

·           WRITE_LOCKED_BY_THREAD_ID:当一个线程有一个rwlock,排他格局,WRITE_LOCKED_BY_THREAD_ID,就是锁定线程的thread_id。

·           READ_LOCKED_BY_COUNT:当线程当前有一个rwlock共享情势,那么read_locked_by_count扩大1。只是个计数,所以找不到不行线程拥有了读锁,然则足以用来查看是还是不是有读锁,有微微读是活动的。

通过实施查询一下表,何以知道瓶颈和死锁:

·           Events_waits_current,查看等待哪些rwlock

·           Rwlock_instrances,查看其余线程是不是具有那些锁。

只得知道那些线程有了write lock不过不晓得哪个线程有read lock。

|group_replication_applier | 0 |

23.9.3.5 socket_instance表

Socket_instancees表提供了一个实时的接连活动快照。每个tcp/ip连接有一行,或者每个unix socket file连接有一行。

mysql> SELECT * FROM socket_instances\G

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

           EVENT_NAME: wait/io/socket/sql/server_unix_socket

OBJECT_INSTANCE_BEGIN: 4316619408

            THREAD_ID: 1

            SOCKET_ID: 16

                   IP:

                 PORT: 0

                STATE: ACTIVE

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

           EVENT_NAME: wait/io/socket/sql/client_connection

OBJECT_INSTANCE_BEGIN: 4316644608

            THREAD_ID: 21

            SOCKET_ID: 39

                   IP: 127.0.0.1

                 PORT: 55233

                STATE: ACTIVE

*************************** 3. row
***************************

           EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

OBJECT_INSTANCE_BEGIN: 4316699040

            THREAD_ID: 1

            SOCKET_ID: 14

                   IP: 0.0.0.0

                 PORT: 50603

                STATE: ACTIVE

socket记录点名字格式,wait/io/socket/sql/socket_type:

1.劳务有一个监听socket,记录点那么socket_type的值为server_tcpip_socket或者server_unix_socket``。

2.      当有一个监听socket发现一个接连,那么服务会转化到一个新的socket来保管,server_type类型为client_connection。

3.      当一个一而再中断,那么行会在socket_instances中删除。

Socket_instances表类如下:

·           EVENT_NAME: wait/io/socket/*,具体的名字来至于setup_instruments表

·           OBJECT_INSTANCE_BEGIN:socket的唯一标记,值为对象在内存中的值。

·           THREAD_ID:内部线程表示。每个socket由线程管理,所以每个socket被映射到一个线程。

·           SOCKET_ID:socket内部的分红的文本句柄

·           IP:客户端ip地址

·           PORT:客户端端口地址

·           STATE:socket状态要不是idle要不是active。要是线程等待client的请求,那么景况就是idle。当socket变成idle,表中的STATE也会成为IDLE,socket的记录点中断。当呼吁出现idle中断,变成ACTIVE。Socket的记录点timing復苏。

IP:PORT组合来表示一个可行的连天。组合值被用来events_waits_xxx表的object_name,来标记连接来至于哪个地方:

·           来至于unix域监听socket,端口是0,ip为‘’

·           对于通过unix域监听的socket,端口是0,ip为‘’

·           对于tcp/ip的监听,端口是服务的端口,默许为3306,ip为0.0.0.0

·           对于经过tcp/ip连接的客户端接口,端口不为0,ip是客户端的ip。

| group_replication_recovery |0|

23.9.4 性能框架事件等待表

事件等待表有3个:

·           Events_waits_current:当前事变等待表

·           Events_waits_history:历史等待历史表,近来的等候事件表

·           Events_waits_history_long:很多风云等待历史的表。

等候历史配置

为了收集等待事件,启动相应的记录点和买主。

mysql> SELECT * FROM setup_instruments

    -> WHERE NAME LIKE ‘wait/io/file/innodb%’;

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

| NAME                                 | ENABLED | TIMED |

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

| wait/io/file/innodb/innodb_data_file | YES     | YES   |

| wait/io/file/innodb/innodb_log_file  | YES     | YES   |

| wait/io/file/innodb/innodb_temp_file | YES     | YES   |

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

mysql> SELECT * FROM setup_instruments WHERE

    -> NAME LIKE ‘wait/io/socket/%’;

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

| NAME                                   | ENABLED | TIMED |

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

| wait/io/socket/sql/server_tcpip_socket | NO      | NO    |

| wait/io/socket/sql/server_unix_socket  | NO      | NO    |

| wait/io/socket/sql/client_connection   | NO      | NO    |

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

修改enabled和timing列:

mysql> UPDATE setup_instruments SET ENABLED = ‘YES’, TIMED =
‘YES’

    -> WHERE NAME LIKE ‘wait/io/socket/sql/%’;

Setup_consumers包罗消费者对应到刚刚的事件表。这一个消费者用来过滤等待事件的募集,默许被剥夺:

mysql> SELECT * FROM setup_consumers WHERE NAME LIKE ‘%waits%’;

+—————————+———+

| NAME                      | ENABLED |

+—————————+———+

| events_waits_current      | NO      |

| events_waits_history      | NO      |

| events_waits_history_long | NO      |

+—————————+———+

启动所有的守候事件:

mysql> UPDATE setup_consumers SET ENABLED = ‘YES’

    -> WHERE NAME LIKE ‘%waits%’;

Setup_timers表包蕴了一条龙name为wait,表示等待事件的定时的单位,默认是cycle:

mysql> SELECT * FROM setup_timers WHERE NAME = ‘wait’;

+——+————+

| NAME | TIMER_NAME |

+——+————+

| wait | CYCLE      |

+——+————+

修改定时单位时间:

mysql> UPDATE setup_timers SET TIMER_NAME = ‘NANOSECOND’

    -> WHERE NAME = ‘wait’;

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

23.9.4.1 events_waits_current表

Events_waits_current表包括了当前的等候时间,每个thread都有一行突显当前thread的等候时间。伊夫nts_waits_current表可以运用truncate table。

Events_waits_current表列:

·         THREAD_ID,EVENT_ID
线程相关的轩然大波和线程当前事件号。那2个字段形成主键来标示一行。

·         END_EVENT_ID
当事件启动,这么些列为null,倘诺时间为止分配一个事件号。

·         EVENT_NAME
变更事件的记录点名。

·         SOURCE
源代码文件名包蕴爆发事件的记录点代码地方。能够支持用来检查源代码。

·         TIMER_START,TIMER_END,TIMER_WAIT
事件的timing音信。时间单位为阿秒。TIMER_START,TIMER_END代表事件的上马和终结。TIMER_WAIT是事件的持续时间。若是事件尚未成功TIMER_END,TIMER_WAIT为null。借使记录点的timed=no那么那3个列都是null。

·         SPINS
对于信号量,是只自旋次数。假如为null,表示代码不应用自旋或者自旋没有被记录。

·        
OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE_OBJECT_INSTANCE_BEGIN
这个列表示对象被启动的职位,依据目标类型分裂含义不相同:
对此联合对象:(cond,mutex,rwlock)

§  OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE为null

§  OBJECT_INSTANCE_BEGIN为一起对象在内存中的地址。

对此文本io对象

§  OBJECT_SCHEMA为null

§  OBJECT_NAME为文件名

§  OBJECT_TYPE为file

§  OBJECT_INSTANCE_BEGIN为内存地址

对于socket对象

§  OBJECT_NAME为IP:PORT

§  OBJECT_INSTANCE_BEGIN为内存地址

对于表io对象

§  OBJECT_SCHEMA是表所在schema的名字

§  OBJECT_NAME表名

§  OBJECT_TYPE为table或者temporary table

§  OBJECT_INSTANCE_BEGIN是内存地址

OBJECT_INSTANCE_BEGIN本身是没有意义的,除非分化的值表示区其余对象。OBJECT_INSTANCE_BEGIN能够用来调节。比如group by这么些字段查看是不是有1000个信号量,造成某些瓶颈。

·         INDEX_NAME
接纳的index名字,primary表示表的主键索引,null表示没有索引

·         NESTING_EVENT_ID
event_id表示丰硕event被嵌套

·         NESTING_EVENT_TYPE
嵌套的轩然大波培训,可能是以下一种,TRANSACTION,STATEMENT,STAGE,WAIT

·         OPERATION
进行操作的类型,lock,read,write中一个。

·         NUMBER_OF_BYTES
读写操作的字节个数。对于表io等待,MySQL 5.7.5从前值为null,之后为行数。倘使值大于1,是批量io操作。MySQL执行join是nested-loop机制。性能框架可以提供行数和每个表执行join准确的岁月。假若一个join查询,执行如下:

SELECT … FROM t1 JOIN t2 ON … JOIN t3 ON …

在join操作的时候表的表行的增添减少(扇出)。如若t3的扇出超乎1,那么大部分行获得操作就出自于那一个表。假诺t1 10行,t2 20行对应到t1一行,t3 30行对应t2 1行。那么一共会有被记录的操作是:

10 + (10 * 20) + (10 * 20 * 30) = 6210

为了裁减被记录操作,可以透过每一趟扫描完成聚合的点子(聚合t1,t2的绝无仅有值)。记录点计数裁减为:

10 + (10 * 20) + (10 * 20) = 410

对于地点的状态选取条件:

§  查询访问的表基本上都是inner join的

§  查询执行不须求表内的单个记录

§  查询执行不要求评估子查询访问了表。

·         FLAGS
保留

2 rows inset (0.00 sec)

23.9.4.2 Events_waits_history表

Events_waits_history表每个线程包涵了近年N条数据。表结构和events_waits_current一行,也能够被truncate table,N是服务启动自动安装的,也得以从参数设置:
performance_schema_events_waits_history_size。

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

23.9.4.3 events_waits_history_long 表

Events_waits_history_long表每个线程包蕴了多年来N条数据。表结构和events_waits_current一行,也得以被truncate table,N是服务启动自动安装的,也足以从参数设置:
performance_schema_events_waits_history_long_size。

亚洲必赢登录 3

23.9.5 性能框架Stage事件表

属性框架stage记录,是语句执行的阶段,比如解析语句,打开表或者实施filesort操作。Stage关联到的了show
processlist中的线程状态。

因为事件等级,等待事件穿插在stage事件,stage事件穿插在语句事件,事务事件。

Stage事件配置

启航stage事件的募集,启动相应的记录点和消费者。

Setup_instruments表包括以stage开首的笔录点名。那些记录点除了说话处理的音信,默许是禁用的:

mysql> SELECT * FROM setup_instruments WHERE NAME RLIKE
‘stage/sql/[a-c]’;

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

| NAME                                               | ENABLED | TIMED |

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

| stage/sql/After create                             | NO      | NO    |

| stage/sql/allocating local table                   | NO      | NO    |

| stage/sql/altering table                           | NO      | NO    |

| stage/sql/committing alter table to storage engine | NO      | NO    |

| stage/sql/Changing master                          | NO      | NO    |

| stage/sql/Checking master version                  | NO      | NO    |

| stage/sql/checking permissions                     | NO      | NO    |

| stage/sql/checking privileges on cached query      | NO      | NO    |

| stage/sql/checking query cache for query           | NO      | NO    |

| stage/sql/cleaning up                              | NO      | NO    |

| stage/sql/closing tables                           | NO      | NO    |

| stage/sql/Connecting to master                     | NO      | NO    |

| stage/sql/converting HEAP to MyISAM                | NO      | NO    |

| stage/sql/Copying to group table                   | NO      | NO    |

| stage/sql/Copying to tmp table                     | NO      | NO    |

| stage/sql/copy to tmp table                        | NO      | NO    |

| stage/sql/Creating sort index                      | NO      | NO    |

| stage/sql/creating table                           | NO      | NO    |

| stage/sql/Creating tmp table                       | NO      | NO    |

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

修改stage事件,修改enabled和timing列:

mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'

    -> WHERE NAME = 'stage/sql/altering table';

Setup_consumers表包罗消费者只提到的事件表名。消费者或者用来过滤收集器stage事件。Stage消费者默许禁用:

mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%stages%';

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

| NAME                       | ENABLED |

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

| events_stages_current      | NO      |

| events_stages_history      | NO      |

| events_stages_history_long | NO      |

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

启航所有的stage事件:

mysql> UPDATE setup_consumers SET ENABLED = 'YES'

    -> WHERE NAME LIKE '%stages%';

Setup_timers包含name=‘stage’,说明stage事件timing:

mysql> SELECT * FROM setup_timers WHERE NAME = 'stage';

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

| NAME  | TIMER_NAME |

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

| stage | NANOSECOND |

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

修改timing值:

mysql> UPDATE setup_timers SET TIMER_NAME = ‘MICROSECOND’

    -> WHERE NAME = ‘stage’;

Stage事件进程音讯

MySQL 5.7.5,性能架构stage事件表包蕴2列,每行提供stage进程标示:

·           WORK_COMPLETED:stage工作单元完结个数。

·           WORK_ESTIMATED:预期的stage工作单元达成个数。

借使没有进程音信,每列都是null。性能框架提供一个器皿来存放这么些进程数据:

·           工作单元,是一个量,随着实践时间的增多变大。

·           WORK_COMPLETED,一个如故几个单元增添一回,依赖于被记录代码

·           WORK_ESTIMATED,可以在stage司改,根据,被记录代码。

对于stage事件的快慢的记录可以达成以下任何表现:

·           没有进程记录点
那么些是最常出现的,因为没有进度数据被提供,WORK_COMPLETED和WORKESTIMATED都为bull

·           没有被绑定记录点
只有WORK_COMPLETED列有含义,WORK_ESTIMATED列没有值,展现为0。
打开events_stages_current表监控回话,监控程序可以告诉有些许work已经被执行,但是不知道如几时候可以了结,因为记录点没有提供。

·           绑定进程记录点
WORK_COMPLETED和WORK_ESTIMATED列都是有含义的。
进程标识符的档次适合于已经定义了成就临界的操作,比如表复制记录点。通过查询events_stages_current表来监督会话,监控程序可以监督所有达成比例的stage,通过测算WORK_COMPLETED / WORK_ESTIMATED的比率。

stage/sql/copy to tmp table演示,进程标识符如何做事。在执行alter table语句,那一个记录点就很有用,并且会实施很长一段时间。

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

23.9.5.1 events_stages_current表

Events_stages_current表蕴涵当前stage事件,每行一个线程线程当前状态监控到的stage事件。

Events_stages_current表可以truncate
table。

表events_stages_current是events_stages_history和events_stages_history_long的基础。

Events_Stages_current列:

·         THREAD_ID,EVENT_ID
线程相关的风云和线程当前事件号。那2个字段形成主键来标示一行。

·         END_EVENT_ID
当事件启动,那几个列为null,假使时光为止分配一个事件号。

·         EVENT_NAME
转变事件的笔录点名。

·         SOURCE
源代码文件名包罗爆发事件的记录点代码地点。可以协助用来检查源代码。

·         TIMER_START,TIMER_END,TIMER_WAIT
事件的timing新闻。时间单位为阿秒。TIMER_START,TIMER_END表示事件的开首和竣事。TIMER_WAIT是事件的持续时间。即使事件尚无马到功成TIMER_END,TIMER_WAIT为null。如果记录点的timed=no那么这3个列都是null。

·         WORK_COMPLETED,WORK_ESTIMATED
这几个列提供了stage进程新闻,对于记录点已经用来生成这几个信息。WORK_COMPLETED表示有稍许干活单元已经被成功,WORK_ESTIMATED表示有些许办事单元估计的stage。

·         NESTING_EVENT_ID
EVENT_ID nested生成的风波。嵌套的event的stage事件日常是语句事件。

·         NESTING_EVENT_TYPE
嵌套事件类型,TRANSACTION,STATEMENT,STAGE,WAIT其中一个。

2. replication_applier_status表

23.9.5.2 events_stage_history表

Events_stages_history为种种线程保留了N个记录,具体可以因此配备参数修改:

performance_schema_events_stages_history_size

该表中著录的是从库当前的貌似工作执行景况(该表也记录组复制架构中的复制状态音讯)

23.9.5.3 events_stage_history_long表

Events_stages_history_long为每个线程保留了N个记录,具体可以透过布署参数修改:

performance_schema_events_stages_history_long_size

  • 此表提供了所有线程binlog重播事务时的平日状态信息。线程回看事务时特定的景色音信保存在replication_applier_status_by_coordinator表(单线程复制时该表为空)和replication_applier_status_by_worker表(单线程复制时表中著录的音讯与八线程复制时的replication_applier_status_by_coordinator表中的记录类似)

23.9.6 性能框架语句事件表

特性框架记录点语句执行。语句事件暴发在高级其余轩然大波,等待事件嵌套在stage事件中,stage事件嵌套在言辞事件中,语句事件嵌套在作业事件中。

讲话事件配置

Setup_instruments表包蕴记录点,以statement前缀的记录点。那几个记录点的默许值可以选取语句:

mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'statement/%';

可以经过以下语句修改:

mysql> UPDATE setup_instruments SET ENABLED = 'NO'

    -> WHERE NAME LIKE 'statement/com/%';

翻开和改动timer:

mysql> SELECT * FROM setup_timers WHERE NAME = ‘statement’;

+———–+————+

| NAME      | TIMER_NAME |

+———–+————+

| statement | NANOSECOND |

+———–+————+

修改timer:

mysql> UPDATE setup_timers SET TIMER_NAME = ‘MICROSECOND’

    -> WHERE NAME = ‘statement’;

 

语句监视

语句监视开始于被呼吁的运动到拥有移动截止。也就是服务碰到客户端的率先个包,到成功重临响应。在MySQL
5.7.2事先,语句只会是尖端其余,比如在储存进程或者子查询不会被分离出来。

最终记录点名和服务命令和sql语句关于:

·           关联到COM_xxx定义在mysql_com.h头文件和在sql/sql_parse.cc中处理,比如COM_PING和COM_QUIT,那么记录点名以statement/com初叶,比如statement/com/ping和statement/com/ping。

·           SQL语句是用文件表示的。那么相关的命令行以statement/sql开端,比如statement/sql/delete和statement/sql/select。

局地记录点名表示特其余错误处理:

·           Statement/com/error,记录了服务收集到的未绑定的消息。无法判定从客户端发送到服务端的指令。

·           Statement/sql/error,记录了sql语句分析错误。用来诊断查询发送到客户端的老大。一个查询分析错误和询问执行错误差距

请求可以通过以下水道获取:

·           一个限令或者语句从客户端获取并发送

·           在replication slave,语句字符串从relay log读取。

·           从event scheduler获取事件。

请求的详细原来是不领会的,并且性能框架从呼吁的各样获取特定的记录点名。

从客户端收集的呼吁:

1.        当服务意识一个新的包在socket级别,一个新的的语句以抽象的笔录点名statement/abstract/new_packet开始。

2.        当服务读取包序号,获取接受的央求类型,性能框架获取记录点名。比如,请求是COM_PING包,那么记录点名会变成statement/com/ping。即使请求是COM_QUERY包,知道是一个sql语句,可是不亮堂具体的品种。那个时候会给一个华而不实的记录点名statement/abstract/query。

3.        假设请求的话语,文本早已读入到分析器。分析未来,那么可相信的口舌类型已经知晓了,如若请求是一个插入语句,性能框架会再度定位记录点名statement/abstract/Query
to statement/sql/insert。

 

对此从复制的relay log上读取语句:

1.        语句在relay log中是以文件存储的。没有网络协议,所以statement/abstract
/new_packet不会被选取,而是利用statement/abstract/realy_log。

2.        当语句被解析,准确的讲话类型被识破。比如insert语句,那么性能框架会再一次寻找记录点名,statement/abstract/Query
to statement/sql/insert。

地方介绍的,只是根据语句的复制,对于基于行的复制,订阅表行处理可以被记录,不过relay
log中的行事件描述语句的并不见面世。

 

对此从事件调度器来的哀求:

事件实施的记录点名为statement/scheduler/event。

事件体重的风浪实施记录点名使用statement/sql/*,不适用其余抽象记录点名。事件是一个仓储进度,并且存储进程是预编译在内存中的。那么在进行时就不会有分析,然而项目在推行时就领悟了。

在事件体内的口舌都是子句。比如一个事件实施了一个insert语句,执行的事件是下边。记录点使用statement/scheduler/event,并且insert是下属,使用statement/sql/insert记录点。

这么不单单是要开动statement/sql/*记录点,还要启动statement/abstract/*记录点。

在头里的5.7版本的,抽象记录点名用此外记录点代替的:

·           Statement/abstract/new_packet之前为statement/com/

·           Statement/abstract/query之前为statement/com/Query

·           Statement/abstract/relay_log之前为statement/rpl/relay_log

大家先来看望表中著录的统计新闻是何许样子的。

23.9.7 性能框架事务表

性能框架事务记录点。在事变级别,等待事件嵌套stage事件,stage事件嵌套语句事件,语句事件嵌套事务事件。

 

工作事件配置

Setup_instruments包涵的transaction的记录点:

mysql> SELECT * FROM setup_instruments WHERE NAME =
‘transaction’;

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

| NAME        | ENABLED | TIMED |

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

| transaction | NO      | NO    |

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

起首收集工作事件:

mysql> UPDATE setup_instruments SET ENABLED = ‘YES’, TIMED =
‘YES’

    -> WHERE NAME = ‘transaction’;

Setup_consumers表包罗transaction的顾客:

mysql> SELECT * FROM setup_consumers WHERE NAME LIKE
‘%transactions%’;

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

| NAME                             | ENABLED |

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

| events_transactions_current      | NO      |

| events_transactions_history      | NO      |

| events_transactions_history_long | NO      |

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

起步消费者:

mysql> UPDATE setup_consumers SET ENABLED = ‘YES’

    -> WHERE NAME LIKE ‘%transactions%’;

设置相关记录点:

mysql> SELECT * FROM setup_timers WHERE NAME = ‘transaction’;

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

| NAME        | TIMER_NAME |

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

| transaction | NANOSECOND |

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

修改timer_name的值:

mysql> UPDATE setup_timers SET TIMER_NAME = ‘MICROSECOND’

    -> WHERE NAME = ‘transaction’;

 

政工绑定

在MySQL Server,使用以下语句突显启动工作:

START TRANSACTION | BEGIN | XA START | XA BEGIN

事情也得以隐式启动,当autocommit系统变量启动。当autocommit禁用,在开行新工作钱要显得的利落下面一个作业。

COMMIT | ROLLBACK | XA COMMIT | XA ROLLBACK

举行DDL语句,事务会隐式提交

性能框架定义的事情绑定和劳动的很相似。事务的启航和表明也和服务的政工状态非凡:

·           对于突显启动的业务,事务events在start transaction后开行。

·           对于隐式启动的政工,事务事件在率先个语句执行的时候启动。

·           对于其余事情,当执行commit,rollback事务甘休。

神秘的不一致点:

·           性能框架中的事务事件,没有完全包蕴语句事件比如START
TRANSACTION,COMMIT,ROLLBACK语句。

·           语句即使运行在非实物引擎,那么连接的作业状态不会潜移默化。

 

事务记录点

3个概念的事情属性:

·           访问方式(read only,read write)

·           隔离级别

·           隐式或者突显

为了削减作业记录点并且有限扶助收集工作数据是成功的,有含义的结果,所有业务都有访问方式,隔离级别,自动提交情势。

工作事件表使用3列来ACCESS_MODE,ISOLATION_LEVEL,AUTOCOMMIT记录。

事务记录点消费可以有很多种艺术收缩,比如依照用户,账号,host,thread启动或者禁用事务减了点。

 

线程和嵌套事件

事务事件的上司事件是初始化事务的风浪。对于突显事务启动,包涵START_TRANSACTION和commit and china,假如是隐式事务,第二个语句启动工作。

来得的终止工作,COMMIT,ROLLBACK,或者DDL语句,隐式的交给业务。

 

作业和仓储进度

事务和储存进程事件涉及如下:

·           存储进度
存储进度操作独立的事务,一个储存进度能够启动一个事情,并且一个政工能够在仓储进程中启动和截至。即使在一个作业中调用,一个存储进程可以语句强制提交业务并且启动一个新的业务。

·           存储函数
积存函数可以限制显示或者隐式的工作提交和回滚。

·           触发器
触发器活动是语句的移动访问相关的表,所以触发器事件的下边事件激活它。

·           调度事件
事件体的言辞调度事件爆发一个新连接。

 

事务和savepoint

Savepoint语句以独立的话语事件被记录。语句事件包含SAVEPOINT,ROLLBACK
TO SAVEPOINT和RELEASE SAVEPOINT语句。

 

事情和谬误 工作中的错误和警戒被记录在讲话事件中,可是不在相关的事情事件。

#
单线程复制和四线程复制时表中的记录一致,如若是多主复制,则每个复制通道记录一行消息

23.9.8 性能框架连接表

性能框架提供了连年的计算音信。当客户端连接,在一个一定的用户名和host下。性能框架为各种账号跟踪连接。

·         Accounts:每个客户端账号的连年总计音信。

·         Hosts:每个客户端hostname 的连接总括音信。

·         Users:每个客户端用户名的连日计算新闻。

账号那里的情趣是用户增加host。连接表有CURRENT_CONNECTIONS和TOTAL_CONNECTIONS列跟踪所有的延续。Accounts表有USER和HOST列跟踪用户和host。Users和hosts表有USER和HOST列,跟踪用户仍然host。

假定客户端名user1,user2从hosta,hostb连接过来。性能框架跟踪连接入选:

·         Accounts会有4条记录,user1/hosta,user1/hostb,user2/hosta,user2/host2.

·         Users表有2条记录,user1,user2

·         Host表有2条记录,hosta,hostb

当客户端连接,连接表中即使不设有这么的用户仍旧host,那么就大增一行否则就修改CURRENT_CONNECTIONS和TOTAL_CONNECTIONS列。

当客户端断开连接,性能框架减少current_connecitons列。

属性框架也计数内部线程和用户会话线程验证错误。对应的user和host为null。

各样连接表都可以truncate:

·         行要是是CURRENT_CONNECTIONS=0的就删除

·         如果>0,TOTAL_CONNECTIONS设置为CURRENT_CONNECTIONS。

·         连接合计表着重于连接表的值会被设为0.

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

23.9.9 性能框架连接属性表

具体看:

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

23.9.10 性能框架用户变量表

具体看:

| CHANNEL_NAME |SERVICE_STATE | REMAINING_DELAY
|COUNT_TRANSACTIONS_RETRIES |

23.9.11 性能框架复制表

MySQL 5.7.2,性能框架提供了关于复制音讯的表。和show slave
status的新闻类似:

·         Show slave status输出可以翻阅进行自我批评,不过不可能用来编程使用。

·         查询结果可以保留到表中,用于分析,设置变量,或者在仓储进程上接纳。

·         复制表提供了更好的确诊音讯,对于八线程slave操作,show slave status使用last_SQL_Errorno和last_sql_error字段报告富有的协调器和办事线程的荒谬。所以唯有如今的一无可取才能看得出。复制表会为各样线程上的失实保存音信不会丢掉。

·         每个工作线程的流行的事体在在复制表是可知的。不过show_slave_status。不可见。

·         开发通晓的属性框架接口可以扩充复制表提供越来越多的新闻。

复制表描述

性能框架提供一下和复制有关的表:

·         关于Slave连接到master的一连信息表:

§  Replication_connection_configuration:配置连接到master的参数。

§  Replication_connection_status:当前连续到master的状态。

·         关于slave事务应用的表

§  replication_applier_configuration:slave中工作应用的配备新闻。

§  replication_applier_status:当前工作应用的图景。

·         关于指定线程应用从master获取工作并施行的新闻:

§  Replication_applier_status_by_coordinator:applier线程状态,从前叫replication_execute_status_by_coordinator。对于有多少个work thread的复制有多个work thread和一个调和线程,对于单线程的那几个表为空。

§  Replication_applier_status_by_worker:工作线程应用状态。同上单线程复制表为空。

·         包涵复制组成员音讯的表:

§  Replication_group_members:提供网络和组成员状态。

§  Replication_group_member_status:提供组成员的统计音讯和涉企的事体。

复制表生命周期

特性框架在以下情状下写入复制表:

·           在履行change master to之前表为空。

·           在实践change master to之后。配置演说可以在表上发现。如果这几个时候从不运动的slave
线程,那么thread_id列为null,serivce_state的情事为off。

·           Start slave之后,没有thread_id字段不为空。线程为空闲或者活动service_status状态为on。线程连接到master
server,假如连接建立有个connecting值。

·           Stop slave之后,thread_id为null,并且service_State列值为off。

·           Stop slave或者thread遇到错误,表音讯会被保存。

·           Replication_applier_Status_by_worker表只有当slave操作在四线程情势下为非空。即使slave_parallel_workers变量大于0,那么start
slave之后,行数和线程个数一样多。

SHOW SLAVE STATUS不再复制表中的新闻

Show slave status的新闻和复制表中的消息分化,因为这一个表紧要是面向GTID的复制。不是按照文件名和位置:

·           以下字段关于文件名和地方的从未有过保留:

Master_Log_File

Read_Master_Log_Pos

Relay_Log_File

Relay_Log_Pos

Relay_Master_Log_File

Exec_Master_Log_Pos

Until_Condition

Until_Log_File

Until_Log_Pos

·           Master_info_file字段没有保留。参照master.info文件。

·           以下字段基于server_id,不是server_uuid,没有被保存:

Master_Server_Id

Replicate_Ignore_Server_Ids

·           Skip_counter列基于事件个数,不是gtid没有被保存。

·           错误列是last_sql_errno,last_sql_error的别名,由此不被封存

Last_Errno

Last_Error

在性质框架中,replication_applier_status_by_coodinator和表replication _applier_status_by_worker中的last_error_number和last_error_message列保存了错误音讯。

·           命令行过滤操作的音讯不被保存:

Replicate_Do_DB

Replicate_Ignore_DB

Replicate_Do_Table

Replicate_Ignore_Table

Replicate_Wild_Do_Table

Replicate_Wild_Ignore_Table

·           Slave_io_State和slave_sql_running_state列没有保存。假使急需可以由此thread_id关联上perocesslist表获取表中的status值。

·           Executed_gtid_set字段可以突显多量的文字。和性能框架表中显示已经被slave应用的业务的GTID。已经被实施的GTID能够因而gtid_executed系统变量获取。

·           Seconds_behind_master和relay_log_spae用来将要被控制的情景不保留。

状态变量移动到了复制表

从mysql 5.7.5,以下境况被活动到了性能框架复制表:

Slave_retried_transactions

Slave_last_heartbeat

Slave_received_heartbeats

Slave_heartbeat_period

Slave_running

这个变量用于单源复制,因为只好反映默许源复制。当有多少个复制源,可以使用性能复制表,汇报每个复制渠道的意况。

多源复制

特性框架表的率先列是channel_name.可以看到各样复制源。

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

23.9.11.1 replication_connection_configure表

表展现了连年到slave服务的接连配置。参数被保存在表中,在change
master执行的时候会被改动。

replication_connection_configuration表包罗以下列:

·           CHANNEL_NAME:复制源名。

·           HOST:master的host名。

·           PORT:master的端口

·           USER:连接用户

·           NETWORK_INTERFACE:slave绑定的network接口。

·           AUTO_POSITION:如若自定定位被采取了就是1,否则是0

·           SSL_ALLOWED, SSL_CA_FILE, SSL_CA_PATH,
SSL_CERTIFICATE, SSL_CIPHER, SSL_KEY,
SSL_VERIFY_SERVER_CERTIFICATE, SSL_CRL_FILE, SSL_CRL_PATH
那几个列呈现了slave连接到master的SSL的参数SSL_ALLOWED的值如下:

§   Yes,如果SSL连接到master被允许。

§   No,假若SSL连接到master不被允许。

§   Ignored,如果SSL被允许,但是slave不支持SSL。

Change master to选项还有其它ssl选项:MASTER_SSL_CA, MASTER_SSL_CAPATH,
MASTER_SSL_CERT, MASTER_SSL_CIPHER, MASTER_SSL_CRL,
MASTER_SSL_CRLPATH, MASTER_SSL_KEY,
MASTER_SSL_VERIFY_SERVER_CERT。

·           CONNECTION_RETRY_INTERVAL:重试的秒数。

·           CONNECTION_RETRY_COUNT:失误连连之后重试的次数。

·           HEARTBEAT_INTERVAL:复制心跳间隔。

|| ON |NULL | 0 |

23.9.11.2 replication_connection_status

表保存了io线程的景色,io线程连接到master服务赢得binary log音信。

Replication_connection_status相关列:

·           CHANNEL_NAME:来源名。

·           GOURP_NAME:保留

·           SOURCE_UUID:master的server_uuid

·           THREAD_ID:io 线程id

·           SERVICE_STATE:服务情形

·           RECEIVED_TRANSACTION_SET:GTID集合反应已经被slave收到的GTID。

·           LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE:错误好和错误音信。

·           LAST_ERROR_TIMESTAMP:错误的风云格式为YYMMDD HH:MM:SS。

·           LAST_HEARTBEAT_TIMESTAMP:近期四遍心跳事件的风浪。

·           COUNT_RECEIVED_HEARTBEATS:收到的心跳次数。

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

23.9.11.3 replication_applier_configure

其一表显示了震慑工作应用的计划参数。参数保存在表可以因此change
master to修改。

Replication_applier_configure表有以下列:

·           CHANNEL_NAME:复制来源名。

·           DIESIRED_DELAY:master到slave的延迟。

1row inset ( 0. 00sec)

23.9.11.4 replication_applier_status

表保存了slave日常事务执行的情况。

replication_aplier_status列名:

·           CHANNEL_NAME:复制来源名。

·           SERVICE_STATE:展现on表示复制渠道活动照旧空闲,要是为off表示应用线程没有活动。

·           REMAINING_DELAY:如果slave等待DESIRED_DELAY直到master应用事件。列显示剩下的秒数。

·           COUNT_TRANSACTIONS_RETRIES:突显了sql thread应用工作错误,导致重试的次数。

# 假如是MGR集群,则该表会记录如下MGR集群新闻

23.9.11.5 replication_applier_status_by_coordinator

对此三十二线程的slave,slave使用多少个工作线程和一个和谐线程,协调线程用来管理工作线程,表突显了协调线程的景色。若是是单线程slave,表为空。

Replication_applier_status_by_coordinator列:

·           CHANNEL_NAME:复制来源名。

·           THREAD_ID:SQL/协调线程id。

·           LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE:最终三次错误号和错误新闻。

·           LAST_ERROR_TIMESTRAMP:时间戳格式为YYMMDD HH:MM:SS。

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

23.9.11.6 replication_applier_statys_by_worker

对于八线程的slave,slave使用多少个工作线程和一个调匀线程,协调线程用来管理工作线程,表突显了和谐线程的图景。假若是单线程slave,表为空。

Replication_applier_status_by_worker:

·           CHANNEL_NAME:复制来源名。

·           WORKER_ID:worker标识符。Stop
slave之后线程id会变成null,workerid会保留。

·           THREAD_ID:线程id

·           SERVICE_STATE:on,表示活动照旧空闲,off代表不设有。

·           表示worker发现的时尚的事务,如果gtid_mode=off列的值为ANONYMOUS。如若为on:

§   即使失掉工作被执行,那么就是空。

§   当有一个政工被实践了列设置成gtid_next。

§   GTID会被封存,知道下一个业务运行完毕。

§   当下一个GTID被其余线程获取,从gtid_next上获得。

·           LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE:最终四遍错误号和错误音信。

·           LAST_ERROR_TIMESTRAMP:时间戳格式为YYMMDD HH:MM:SS。

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

23.9.11.7 replication_group_members

表保存了网络和复制成员组的意况新闻。Replication_group_members列:

·           CHANNEL_NAME:复制来源名。

·           MEMBER_ID:member标示,和uuid一样。

·           MEMBER_HOST:host地址或者主机名。

·           MEMBER_PORT:端口。

·           MEMBER_STATE:

§   OFFLINE:group replication插件已经设置不过没有启动。

§   RECOVERING:服务一度投入到一个group,正在获取数据。

§   ONLINE:成员在全职能状态。

| CHANNEL_NAME |SERVICE_STATE | REMAINING_DELAY
|COUNT_TRANSACTIONS_RETRIES |

23.9.11.8 replication_group_member_status

表保存了replication group成员的意况,replication_group_member_status:

·           CHANNEL_NAME:复制来源名。

·           VIEW_ID:该group的此时此刻的view标示符。

·           MEMBER_ID:member标示,和uuid一样。

·           COUNT_TRANSACTIONS_IN_QUEUE:pending事务的个数。

·           COUNT_TRANSACTIONS_CHECKED:已经被成员声明的业务个数。

·           COUNT_CONFLICTS_DETECTED:抵触发现个数。

·           COUNT_TRANSACTIONS_VALIDATING:事务可以实施检查,不过并未被回收的个数。

·           TRANSACTIONS_COMMITTED_ALL_MEMBERS:固化的group事务集合。

·           LAST_CONFLICT_FREE_TRANSACTION:最终一个从未争论的被声明的事情。

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

23.9.12 性能框架锁相关表

|group_replication_applier | ON |NULL | 0 |

23.9.12.1 metadata_locks

特性框架把元数据锁通过metadata_locks显示。突显一下音信:

·         锁已经被分配

·         锁被呼吁不过尚未被分配。

·         锁请求可是被死锁kill或者锁等待超时而被收回。

那个新闻可以了解元数据锁和对话之间的关联。可以查看等待的锁,也足以查阅已经取得的锁。

Metadata_locks表只读,无法写入。默许是活动大小的,也得以透过启动参数配置高低:performance_schema_max_metadata_locks。

表默许是被剥夺的,拖过设置setup_instruments的/locl/metadata/sql/mdl来启动。

性能框架珍贵内容,使用lock_status表示锁的处境:

·         当元数据锁被呼吁并且马上得到,行的情景的是GRANTED。

·         当元数据锁被呼吁不过并未及时得到,行的景色为pending。

·         当之前请求的元数据锁获取了,行的情形改为granted。

·         当元数据锁被释放,行被删去。

·         当pending的锁请求被死锁发现器裁撤,状态改为victim。

·         当pending的锁超时,状态成为pending to timeout。

·         当分配的锁照旧pending的锁被kill,状态成为killed。

·         当VICTIM,TIMEOUT,KILLED被布告将来行会被去除。

·         PRE_ACQUIRE_NOTIFY,POST_RELEASE_NOTIFY状态,当获得锁依然释放锁时,lock子系统通报所在的蕴藏引擎的状态。

Metadata_locks列:

·         OBJECT_TYPE:可以是那几个值的中间一个.
GLOBAL, SCHEMA, TABLE, FUNCTION, PROCEDURE, TRIGGER (currently unused),
EVENT, COMMIT, USER LEVEL LOCK, TABLESPACE, LOCKING SERVICE。
一经值为USER LEVEL LOCK表示从get_lock()获取锁,倘使是LOCKING SERVICE表示使用lock service获取说。

·         OBJECT_SCHEMA:对象所在的schema

·         OBJECT_NAME:对象名

·         OBJECT_INSTANCE_BEGIN:记录点对象在内存中的地址。

·         LOCK_TYPE:锁的项目,INTENTION_EXCLUSIVE, SHARED,
SHARED_HIGH_PRIO, SHARED_READ, SHARED_WRITE, SHARED_UPGRADABLE,
SHARED_NO_WRITE, SHARED_NO_READ_WRITE, or EXCLUSIVE.

·         LOCK_DURATION:lock持续的为期。可以是这一个值STATEMENT, TRANSACTION,
EXPLICIT. STATEMENT 和TRANSACTION从言语或者业务的初始直到语句或者业务的收尾。

·         LOCK_STATUS:锁的意况,PENDING,
GRANTED, VICTIM, TIMEOUT, KILLED, PRE_ACQUIRE_NOTIFY,
POST_RELEASE_NOTIFY.

·         SOUCE:源代码文件中的文件名和岗位。

·         OWNER_THREAD_ID:请求元数据的线程。

·         OWNER_EVENT_ID:请求锁的轩然大波id。

| group_replication_recovery |OFF | NULL |0|

23.9.12.2 table_handles

通过表table_handles再次来到表锁消息。Table_handle突显了每个打开表的handle的锁新闻。那一个表被打开了,如何被锁定的,是哪些线程锁的。

Table_handles是只读表,不可能修改,表列如下:

·         OBJECT_TYPE:被table handle打开的表。

·         OBJECT_SCHEMA:表所在的schema。

·         OBJECT_NAME:记录点对象名。

·         OBJECT_INSTANCE_BEGIN:记录点对象在内存中的地址。

·         OWNER_THREAD_ID:请求元数据的线程。

·         OWNER_EVENT_ID:请求锁的事件id。

·         INTERNAL_LOCK:SQL级别使用的表锁。值如下: READ, READ WITH SHARED
LOCKS, READ HIGH PRIORITY, READ NO INSERT, WRITE ALLOW WRITE, WRITE
CONCURRENT INSERT, WRITE LOW PRIORITY, WRITE。

·         EXTERNAL_LOCK:存储引擎级别使用的表锁,READ EXTERNAL ,WRITE
EXTERNAL

 

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

23.9.13 性能框架种类变量表

MySQL维护了无数系统变量,系统变量在那一个表是可用的:

·           Global_variables:全局系统变量。即使应用程序只要全局值可以动用这么些表。

·           Session_variables:当前对话的系统变量。还有没有session变量部分的global变量

·           Variables_by_thread:每个会话的序列变量。

那么些会话级其余变量只含有了活动会话的变量。那个表不辅助truncate
table。

Global_variablees和session_variables表有那个列:

·           VARIABLES_NAME:变量名

·           VARIABLES_VALUE:变量的值。

Variables_by_thread的列:

·           Thread_id:线程id

·           VARIABLES_NAME:变量名

·           VARIABLES_VALUE:变量的值。

Variables_by_thread表包罗了后台线程的系统变量新闻。固然不是颇具的线程记录,那么表内有些行会小时。那么些时候Performance_schema_thread_instance_lost状态变量大于0 。

2 rows inset (0.00 sec)

23.9.14 性能框架连串状态变量表

和连串变量表类似,具体看:

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

23.9.15 性能框架计算表

等待事件总括表:

·           Events_waits_summary_global_by_event_name:等待事件根据每个事件开展商谈。

·           Events_waits_summary_by_instance:等待事件依照各种instance举行计算。

·           Events_waits_summary_by_thread_by_event_name:根据线程和事件名合计的表。

Stage统计表:

·           Events_stages_summary_by_thread_by_event_name:stage等待和线程id计算的表。

·           Events_stages_summary_global_by_eevnt_name:stage等待中各样事件名的计算表。

语句总结表:

·           Events_statements_summary_by_digest:每个schema和digest后的计算表。

·          
Events_statements_summary_by_thread_by_event_name:语句事件名和线程的总括表。

·           Events_statements_summary_global_by_event_name:每个语句事件名的总括表。

·           Events_statements_summary_by_program:每个存储程序的总计(存储进度和仓储函数)。

·           Prepared_statements_instances:预备的说话实例和统计音讯。

业务总括表:

·          
Events_transactions_summary_by_account_by_event_name:每个账号发起的风云计算。

·          
Events_transactions_summary_by_host_by_event_name:每个host发起的作业事件计算。

·          
Events_transactions_summary_by_thread_by_event_name:每个线程发起的事务事件计算。

·          
Events_transactions_summary_by_user_by_event_name:每个用户发起的政工事件计算。

·           Events_transactions_summary_global_by_event_name:事务事件名总计。

对象等待总结:

·           Objects_summary_global_by_type:对象合计。

文件IO统计:

·           File_summary_by_event_name:合计拥有文件io事件名。

·           File_summary_by_instance:每个文件实例的说道。

表IO和锁等待计算:

·           Table_io_waits_summary_by_index_usage:每个拥有的表io等待。

·           Table_io_waits_summary_by_table:每个表的io等待。

·           Table_io_waits_summary_by_table:每个表的锁等待。

总是总括:

·           Events_waits_summary_by_account_by_event_name:每个账号发起的等待事件计算。

·           Events_waits_summary_by_user_by_event_name:每个用户发起的等候事件总结。

·           Events_waits_summary_by_host_by_event_name:每个host发起的等候事件合计。

·           Events_stages_summary_by_account_by_event_name:每个账号stage事件总括。

·           Events_stages_summary_by_user_by_event_nam:每个用户发起的stage事件总计。

·           Events_stages_summary_by_ host_by_event_name:每个host发起的stage事件合计。

·           Events_statements_summary_by_digest:每个schema下的拥有digest。

·           Events_statements_summary_account_by_event_name:每个账号发起的讲话事件。

·           Events_statements_summary_by_user_by_event_name:每个用户发起的语句事件。

·           Events_statements_summary_host_by_event_name:每个host发起的言辞事件。

Socket统计:

·           Socket_summary_by_instance:每个实例的socket等待和io合计。

·           Socket_summary_by_event_name:socket等待和io合计。

内存总括:

·           Memory_summary_global_by_event_name:内存操作事件合计。

·           Memory_summary_by_thead_by_event_name:每个线程内存操作合计。

·           Memory_summary_by_account_by_event_name:每个账号内存操作合计。

·           Memory_summary_by_user_by_event_name:每个用户内存操作合计。

·           Memory_summary_by_host_by_event_name:每个host内存操作协议。

状态变量总括:

·           Status_by_account:状态变量账号合计。

·           Status_by_host:状态变量host合计

·           Status_by_user:状态变量用户协商

亚洲必赢登录 4

23.9.16 性能框架其余表

除外下边你的表还有3个表:

·           Host_cache:内部host cache信息。

·           Performance_timers:事件可用定时器。

·           Threads:服务的线程表。

对于replication_applier_status表,不容许实施TRUNCATE
TABLE语句。

23.10 性能框架选项和变量

具体看:

3. replication_applier_status_by_coordinator表

23.11 性能框架命令选项

具体看:

 

该表中著录的是从库使用十六线程复制时,从库的协调器工作情景记录,当从库使用八线程复制时,每个通道下将开创一个协调器和七个办事线程,使用协调器线程来治本那些工作线程。假若从库使用单线程,则此表为空(对应的笔录转移到replication_applier_status_by_worker表中著录),大家先来看看表中记录的计算信息是什么样样子的。

23.12 性能框架种类变量

具体看:

#
单线程主从复制时,该表为空,为多线程主从复制时表中著录协调者线程状态音信,多主复制时每个复制通过记录一行音讯

23.13 性能框架状态变量

具体看:

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

23.14 性能框架内存分配模型

在mysql 5.7.6从前,性能框架使用以下内存分配模型:

·         所有的内存在启动时分配。

·         服务操作的时候不分配内存。

·         服务操作的时候不自由内存。

·         在劳动关闭的时候释放内存。

选取这几个模型,性能框架会分配多量的内存,除非展现的安顿。Mysql
5.7.6事后的分配模型:

·         可以在劳务启动的时候分配。

·         可以在劳务操作的时候额外分配。

·         在劳务操作的时候不自由。

·         在劳务关闭的时候释放内存。

如此可以按照负荷来调整内存使用,不是切实配置。

有一部分性质框架配置参数是活动分配,也得以手动分配:

performance_schema_accounts_size
performance_schema_hosts_size
performance_schema_max_cond_instances
performance_schema_max_file_instances
performance_schema_max_index_stat
performance_schema_max_metadata_locks
performance_schema_max_mutex_instances
performance_schema_max_prepared_statements_instances
performance_schema_max_program_instances
performance_schema_max_rwlock_instances
performance_schema_max_socket_instances
performance_schema_max_table_handles
performance_schema_max_table_instances
performance_schema_max_table_lock_stat
performance_schema_max_thread_instances
performance_schema_users_size

对于电动配置的参数,配置基本如下:

·         假设为-1,默许,参数是半自动配置的。

§  初步对应的内部buffer为空,没有内存。

§  当性能框架初步搜集数据,没存被分配到想要的buffer。buffer大小没有上限,随着负荷上涨回升。

·         如果设置为0:

§  先日内瓦部buffer为空,也不会分配内存。

·         若是设置的N>0:

§  对象的内部buffer为空,并且不分配内存。

§  当数据开始征集,内存开始分配,直到设置的高低。

§  一旦buffer大小到达N,内存就不再分配。性能框架收集的数额会丢掉,对应的状态变量的lost
instance会增添。

为了查看性能框架使用了略微内存,检查记录点。性能框架收集了各种buffer的内存使用新闻。那样可以跟踪每个buffer的内存使用景况。记录点,memory/performance
_schema/。因为这一个buffer是全局的,所以只在memory_summary_global_by_event_
name上显得。查询如下:

SELECT * FROM memory_summary_global_by_event_name WHERE
EVENT_NAME LIKE ‘memory/performance_schema/%’;

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

23.15 性能框架和

具体看:

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

23.16 使用性能框架诊断

性能框架可以让dba来做一些性质调整,比如一个重复出现的属性问题:

1.运转用例

2.使用性能框架表,分析根本的属性问题。分析严重信赖于post过滤。

3.题目区域曾经划出,禁用对应的记录点。比如尽管条分缕析出和文件io不相关,禁用io的记录点。

4.重复 步骤1-3,那样可以减掉苦恼找出真正的题目。

5.明确了性能瓶颈的因由:

§  调整服务参数

§  调整查询。

§  调整数据库结构

§  调整代码。

6.双重步骤1,查看对性能的熏陶。

在性能调优的时候,mutex_instances.locked_by_thread_id,rwlock_instances.
write_locked_by_thread_id列那些人命关天。比如:

1.线程1,在等候一个信号量。

2.得以行使以下语句查看等待的信号量:

SELECT * FROM events_waits_current WHERE THREAD_ID =
thread_1;

3.然后翻看那多少个线程持有着这些信号量:

SELECT * FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN =
mutex_A;

4.查看线程2在做什么样:

SELECT * FROM events_waits_current WHERE THREAD_ID =
thread_2;

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

23.17 迁移到性能框架体系和景色变量表

Information_schema有表包罗了系统和状态变量信息,MySQL 5.7.6自此,性能框架也富含了系统变量和状态变量音讯。性能框架的表会取代information_schema上的表。

在mysql 5.6翻看状态变量和系统变量来自于:

SHOW VARIABLES
SHOW STATUS

 

INFORMATION_SCHEMA.GLOBAL_VARIABLES
INFORMATION_SCHEMA.SESSION_VARIABLES

INFORMATION_SCHEMA.GLOBAL_STATUS
INFORMATION_SCHEMA.SESSION_STATUS

Mysql 5.7.6,性能框架也包涵了系统变量和状态变量:

performance_schema.global_variables
performance_schema.session_variables
performance_schema.variables_by_thread

performance_schema.global_status
performance_schema.session_status
performance_schema.status_by_thread
performance_schema.status_by_account
performance_schema.status_by_host
performance_schema.status_by_user

MySQL 5.7.6增加了show_compatibility_56系统变量,借使为on:

·         当从information_schema中输出,会现出警示。

·         在mysql 5.7.6,使用show的where语句就会警告。MySQL 5.7.8后头就不会。

当变量为off,不启动兼容方式:

·         搜索information_schema表会报错。

·         Show语句输出的多少来至于性能框架表。

·         这些slave_XXX的状态变量不可用:

Slave_heartbeat_period
Slave_last_heartbeat
Slave_received_heartbeats
Slave_retried_transactions
Slave_running

       应该从性质框架的复制相关的表中获取数据。

 

搬迁和权限

访问性能框架中的系统变量和状态变量必要select权限。倘若show_compatibility_56为off,那么show
variables和show status也亟需select权限,如若兼容性关闭,这一个语句输出来至于性能框架的global_variables,session_variables,global_status,
session_status表。

在mysql 5.7.9,那个表在性质矿建中访问不要求select权限。对应的show variables和show status也不须要权限。

随后的发表,information_schema变量表和show_compatibility_56会被剔除,show输出基于性能框架表。

 

 

Reference Manual] 23 Performance
Schema结构,manualschema 23 MySQL Performance Schema 23 MySQL
Performance Schema .. 1 23.1 性能框架快捷启动 … 3 23.2
性能框架…

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

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

1row inset ( 0. 00sec)

# 假若是MGR集群,则该表中会记录类似如下MGR集群新闻

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表

即使从库是单线程,则该表记录一条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线程),大家先来看望表中著录的计算音讯是哪些样子的。

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

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)

# 即使是MGR集群,则该表中会记录类似如下MGR集群音讯

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线程状态暴发变化,该表中的音信就会发出修改(多主复制架构中,从库指向了略微个主库就会记录多少行记录。MGR集群架构中,每个节点有两条记下,但那两条记下并未记录完整的组复制连接配置参数,例如: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)

# 借使是MGR集群,则该表中会记录类似如下MGR集群音讯

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)

# 即使是MGR集群,则该表中会记录类似如下MGR集群音信

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

……

2 rows in set (0.00 sec)

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

亚洲必赢登录 13

对于replication_connection_status表,不容许实施TRUNCATE
TABLE语句。

7. replication_group_member_stats表

该表中著录了MySQL组复制成员的计算音讯。仅在组复制组件运行时表中才会有记录,大家先来探视表中记录的总括新闻是怎样体统的。

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

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

CHANNEL _NAME: group_replication_applier

VIEW_ID: 15287289928409067:1

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

COUNT _TRANSACTIONS_IN_QUEUE: 0

COUNT _TRANSACTIONS_CHECKED: 0

COUNT _CONFLICTS_DETECTED: 0

COUNT _TRANSACTIONS_ROWS_VALIDATING: 0

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

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

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

LAST _CONFLICT_FREE_TRANSACTION:

1 row in set (0.00 sec)

表中各字段含义如下:

  • 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)

对于replication_group_member_stats表,差距意实施TRUNCATE
TABLE语句。

8. replication_group_members表

该表记录组复制架构中,组成员的网络和情景新闻。仅在组复制组件运行时表中才会有记录,大家先来看看表中著录的统计音讯是如何样子的。

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

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

| CHANNEL_NAME |MEMBER_ID | MEMBER_HOST |MEMBER_PORT | MEMBER_STATE
|

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

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

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

1row inset ( 0. 00sec)

表中各字段含义如下:

  • 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

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

02

用户自定义变量记录表

performance_schema提供了一个封存用户定义变量的user_variables_by_thread表(该表也保留由mysql内部连接线程创立的变量)。那几个变量是在一定会话中定义的变量,变量名由@字符开端。

俺们先来探视表中著录的计算音讯是哪些样子的。

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

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

| THREAD_ID |VARIABLE_NAME | VARIABLE_VALUE |

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

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

| 45 |master_heartbeat_period | 5000000000 |

| 45 |master_binlog_checksum | CRC32 |

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

3rows inset ( 0. 01sec)

表中各字段含义如下:

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

user_variables_by_thread表不容许使用TRUNCATE
TABLE语句

03

system variables记录表

MySQL
server维护着众多系统变量,在performance_schema中提供了对全局、当前对话、以及根据线程分组的系列变量音讯记录表:

  • global_variables:全局系统变量。只须求全局系统变量值的应用程序可以从该表中获取
  • session_variables:当前对话的系统变量。只须要取得自己眼前对话的系统变量值可以从该表中赢得(注意,该表中涵盖了无会话级其余全局变量值,且该表不记录已断开连接的系统变量)
  • variables_by_thread:按照线程ID为标识符记录的对话系统变量。想要在时下线程中询问其余指定线程ID的对话级别系统变量时,应用程序可以从该表中收获(注意,该表中仅包含有对话级别的系统变量)

咱俩先来探望表中记录的统计音讯是哪些体统的。

# global_variables表

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

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

| VARIABLE_NAME |VARIABLE_VALUE |

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

|auto_increment_increment | 2 |

| auto_increment_offset |2|

……

5 rows inset (0.01 sec)

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

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

………….

# variables_by_thread表

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

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

|THREAD_ID | VARIABLE_NAME |VARIABLE_VALUE |

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

|45| auto_increment_increment |2|

|45| auto_increment_offset |2|

……

5 rows inset (0.00 sec)

global_variables和session_variables表字段含义如下:

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

variables_by_thread表字段含义如下:

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

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

PS:

  • show_compatibility_56种类变量的值会影响这么些表中的新闻记录
  • 对话变量表(session_variables,variables_by_thread)仅包含活跃会话的信息,已经终止的对话不会记录
  • variables_by_thread表仅包蕴关于前台线程的对话级别系统变量音讯。且只记录拥有会话级其余种类变量,其它,若是在该表中有无法被记录的对话级别系统变量,那么将净增状态变量Performance_schema_thread_instances_lost的值

04

status variables统计表

MySQL
server维护着广大状态变量,提供有关其内部有关操作的新闻。如下一些performance_schema表中著录着状态变量新闻:

  • global_status:全局状态变量。假如只须要全局状态变量值的应用程序可以查询此表,中断的对话状态变量值会被集结在此表中
  • session_status:当前对话的状态变量。假设只希望查询自己对话的富有景况变量值的应用程序可以查询此表(注意:该表包罗没有对话级其他大局状态变量),只记录活跃会话,不记录已中断的对话
  • status_by_thread:根据线程ID作为标识符记录每个活跃会话的状态变量。借使要求在某个会话中询问任何会话的境况变量值可以查询此表(注意:该表不带有只拥有全局级其他状态变量),只记录活跃会话,不记录中断的对话

俺们先来看看表中著录的统计音讯是怎么样样子的。

# global_status表

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

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

| VARIABLE_NAME |VARIABLE_VALUE |

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

|Aborted_clients | 0 |

| Aborted_connects |0|

……

5 rows inset (0.00 sec)

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

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

…………

# status_by_thread 表

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

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

|THREAD_ID | VARIABLE_NAME |VARIABLE_VALUE |

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

|45| Bytes_received |0|

|45| Bytes_sent |2901|

……

5 rows inset (0.00 sec)

global_status和session_status表字段含义如下:

  • VARIABLE_NAME:状态变量名称
  • VARIABLE_VALUE:状态变量值。对于global_status,此列包涵全局状态变量值。对于session_status,此列包蕴当前对话的动静变量值(同时含有无会话级其余全局状态变量值,且只含有活跃会话的图景变量值)。

status_by_thread表包蕴每个活跃线程的情状。字段含义如下:

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

performance_schema允许对那一个状态变量音讯计算表执行TRUNCATE
TABLE语句:

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

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

PS:

  • 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/%’;
  • 对于按帐户,主机名和用户名聚合的状态变量新闻。详见下文。

05

依据帐号、主机、用户总括的状态变量计算表

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

  • status_by_account:依据每个帐户进行联谊的状态变量
  • status_by_host:根据每个主机名进行联谊的状态变量
  • status_by_user:按照每个用户名展开联谊的状态变量

俺们先来探视表中记录的计算音信是如何体统的。

# status_by_account表

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

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

| USER |HOST | VARIABLE_NAME |VARIABLE_VALUE |

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

|admin | localhost |Bytes_received | 6049 |

| admin |localhost | Bytes_sent |305705|

…….

5 rows inset (0.00 sec)

# status_by_host表

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

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

|HOST | VARIABLE_NAME |VARIABLE_VALUE |

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

|localhost | Bytes_received |6113|

|localhost | Bytes_sent |306310|

……

5 rows inset (0.00 sec)

# status_by_user表

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

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

|USER | VARIABLE_NAME |VARIABLE_VALUE |

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

|admin | Bytes_received |6177|

|admin | Bytes_sent |306781|

……

5 rows inset (0.00 sec)

表中各字段含义

  • VARIABLE_NAME:状态变量名称
  • 与VARIABLE_VALUE:状态变量值,要小心:该段值包涵活跃和已终止的对话的状态变量计算值
  • USER:用户名
  • HOST:主机名或IP

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

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

FLUSH
STATUS将会话状态从所有活动会话添加到全局状态变量,然后重置所有移动会话的状态变量值,并在按照account、host、user分类聚合表中重置已断开连接的情事变量值。

PS:

  • 当会话终止时募集的account相关状态变量会添加到全局状态变量表的计数器和accounts表的连锁计数器中。假设account分类关闭了搜集而host和user分类开启了搜集,则会指向主机和用户分类聚合相应的状态变量值,同时将会话状态添加到hosts和users表中的相关计数器中
  • 如果将performance_schema_accounts_size,performance_schema_hosts_size和performance_schema_users_size系统变量分别安装为0,则不会采集帐户,主机和用户分类的总结音信
  • show_compatibility_56种类变量的值会影响那几个表中的统计音讯

06

host_cache表

host_cache表保存连接到server的主机相关音信缓存,其中蕴蓄客户机主机名和IP地址新闻,可以用来制止DNS查找。该表可以采纳SELECT语句进行查询,但需求在server启动此前开启performance_schema参数,否则表记录为空。

我们先来看望表中著录的计算音讯是怎么着子的。

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

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

IP: 192 .168.2.122

HOST: NULL

HOST_VALIDATED: YES

SUM_CONNECT_ERRORS: 0

COUNT_HOST_BLOCKED_ERRORS: 0

COUNT_NAMEINFO_TRANSIENT_ERRORS: 0

COUNT_NAMEINFO_PERMANENT_ERRORS: 1

COUNT_FORMAT_ERRORS: 0

COUNT_ADDRINFO_TRANSIENT_ERRORS: 0

COUNT_ADDRINFO_PERMANENT_ERRORS: 0

COUNT_FCRDNS_ERRORS: 0

COUNT_HOST_ACL_ERRORS: 0

COUNT_NO_AUTH_PLUGIN_ERRORS: 0

COUNT_AUTH_PLUGIN_ERRORS: 0

COUNT_HANDSHAKE_ERRORS: 0

COUNT_PROXY_USER_ERRORS: 0

COUNT_PROXY_USER_ACL_ERRORS: 0

COUNT_AUTHENTICATION_ERRORS: 0

COUNT_SSL_ERRORS: 0

COUNT_MAX_USER_CONNECTIONS_ERRORS: 0

COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS: 0

COUNT_DEFAULT_DATABASE_ERRORS: 0

COUNT_INIT_CONNECT_ERRORS: 0

COUNT_LOCAL_ERRORS: 0

COUNT_UNKNOWN_ERRORS: 0

FIRST_SEEN: 2017 -12-3022 :34:51

LAST_SEEN: 2017 -12-3022 :35:29

FIRST_ERROR_SEEN: 2017 -12-3022 :34:51

LAST_ERROR_SEEN: 2017 -12-3022 :34:51

1 rowinset(0 .00sec)

表中各字段含义如下:

  • 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客户端,最终一次尝试连接暴发错误的时日

FLUSH HOSTS和TRUNCATE TABLE
host_cache具有同等的意义:它们清除主机缓存。host_cache表被清空并清除阻塞任何因为漏洞百出记录数据超过限制而被封堵的主机连接。FLUSH
HOSTS需求RELOAD权限。 TRUNCATE TABLE须求host_cache表的DROP权限。

PS:一经开行选项 skip_name_resolve
设置为ON,则该表不记录任何信息,因为该表的效应就是用来幸免、加速域名解析用于,跳过域名解析作用时则该表记录的新闻用途不大。

– END –回来今日头条,查看愈来愈多

义务编辑:

网站地图xml地图