219_mysql_复制技术_检查复制信息_performance_schema库_show slave status
九 通过performance_schema库检查复制信息
Performance_schema下面 replication开头的表提供了复制机制的配置和状态信息
| Replication_applier_configuration | 记录从库延迟复制的配置参数 | 
| Replication_applier_status | 记录从库的普通事务执行状态(复制组中的复制状态信息) | 
| Replication_applier_status_by_coordinator | 使用多线程复制, 记录coordinator线程的工作状态 | 
| Replication_applier_status_by_worker | 单线程则记录一条worker_id=0; 如果多线程记录 worker线程状态 | 
| Replication_connection_configuration | 记录从库用于连接到主库的配置信息 | 
| Replication_connection_status | 记录从库I/O线程的连接状态信息 | 
| Replication_group_member_stats | 记录复制组成员的事务状态信息 | 
| Replication_group_members | 记录组复制成员的网络和状态信息 | 
上诉表记录的生命周期
| Change master to 之前 | 空表 | 
| Change master to 之后 | Replication_applier_configuration和replication_connection_configuration可以看到配置信息 由于没有thread启动, 表中 thread_id 为null, service_state 为off | 
| Start slave 之后 | 相应的复制线程开始运行,会更新相关状态; thread_id会被分配(thread表中查看,与 show processlist 中ID 有不同, 对应 thread表中PROCESSLIST_ID ) | 
| Stop slave之后 | 所有的复制I/O, coordinator线程 WORKER线程表中, thread_id字段均为NULL,service_state字段为OFF 停止后 这些记录不会清理, 重启时获取其状态信息用于排错 | 
| RESET SLAVE | 所有复制记录的配置和状态信息清理(磁盘)包括mysql.slave_master_info & mysql.slave_relay_log_info 但未清理内存,show slave status仍然会看到相关信息,如果彻底清理 reset slave all | 
9.1 performance_schema & Show slave status 之间的差异
1 Performance_schema 表中复制信息基于GTID(serverUUID, 而不是server id非binlog)所以 show slave status 中引用binlog的信息不会有
Show slave status 有;但performance_schema下面表不记录
1.1
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
1.2  master_info_file 记录主从配置保存方式 performance_schema不记录;默认是 master.info, 如果table级 mysql.slave_master_info
1.3 基于server id :master_server_id;Replicate_Ignore_Server_Ids
1.4  skip_counter 字段基于事件而不是 GTID基数 
1.5  last_errno & last_error  是 last_sql_errno & last_sql_error字段别名
1.6 过滤复制字段不记录:  Replicate_Ignore_DB; Replicate_Do_Table Replicate_Ignore_Table,Replicate_Wild_Do_Table,Replicate_Wild_Ignore_Table
1.7 slave_io_state & slave_io_running 不记录
SELECT state as io_thread_state , id as process_id,  pr.thread_id from `performance_schema`.replication_connection_status as pr  join information_schema.`PROCESSLIST` as ip on pr.thread_id = sys.ps_thread_id(ip.id)
Sys.ps_thread_id() 传入一个process id 返回一个 thread id  
1.8 seconds_behind_master和 relay_log_space 不记录
2 performance_schema库中的复制信息详解
2.1 replication_applier_configuration 表 记录从库延迟复制的配置参数,延迟复制的线程被称为普通线程;
select * from replication_applier_configuration 
CHANNEL_NAME:   # 链路名称:用来在多链路复制时区分不同的链路,默认空字符串  对应 Channel_name
DESIRED_DELAY  #主从延迟:用来设置复制过程中设置的主从延迟,默认为0不延迟 # 对应SQL_Delay 
2.2 replication_applier_status 表 记录当前从库的普通事务执行状态(也记录组复制架构中的复制状态信息)
| replication_applier_status 字段 | 含义 | 对应 show slave status | 
| CHANNEL_NAME | 显示复制渠道名称 | Channel_Name | 
| SERVICE_STATE | On: 从库处于活跃/空置状态 Off: 从库处于非活跃状态 | 无 | 
| REMAINING_DELAY | 主有变化,还剩多少时间到从; | SQL_Remaining_Delay | 
| COUNT_TRANSACTIONS_RETRIES | 从库SQL线程无法应用事务而进行重试的次数 | 无 | 
2.3 replication_applier_status_by_coordinator表 slave多线程时Coordinator线程工作状态
| replication_applier_status_by_coordinator 字段 | 含义 | 对应 show slave status | 
| CHANNEL_NAME | 显示复制渠道名称 | Channel_Name | 
| THREAD_ID | 该通道下,slave coordinator线程ID | 
 | 
| SERVICE_STATE | On: 从库处于活跃/空置状态 Off: 从库处于非活跃状态 | Slave_sql_running | 
| LAST_ERROR_NUMBER LAST_ERROR_MESSAGE | Slave coordinator线程发生错误而停止的最新错误编号; reset master&slave 该值会被重置 0 无错误, message 为空 非0, 输出错误信息 | LAST_SQL_Errno LAST_SQL_Error | 
| LAST_ERROR_TIMESTAMP | 发生错误时间:YYMMDD HH:MM:SS | Last_SQL_Error_Timestamp | 
2.4 replication_applier_status_by_worker表 slave多线程时 sql/worker线程工作状态
- 如果多线程复制 slave_replication_workes=N 指定N个数量的worker线程(1开始编号),
- 如果是MGR集群会有N个 group_application_applier 和1个 group_replication_recovery
| replication_applier_status_by_worker字段 | 含义 | 对应 show slave status | 
| CHANNEL_NAME | 显示复制渠道名称 | Channel_Name | 
| THREAD_ID | 该通道下,slave worker线程ID | 
 | 
| SERVICE_STATE | On: 从库 worker线程处于活跃/空置状态 Off: 从库 worker线程处于非活跃状态 | Slave_sql_running | 
| LAST_SEEN_TRAN_SACTION | Worker线程正在执行的事务号,GTID 如果 gtid_mode off 该字段为ANONYMOUS 如果空闲 为空串 如果执行过事务后空闲 为最后一次的GTID 如果发生错误/最后一次GTID 会被coordinator捕获,该通道下SQL线程都会被暂停 | 
 | 
| LAST_ERROR_NUMBER LAST_ERROR_MESSAGE | Slave coordinator线程发生错误而停止的最新错误编号; reset master&slave 该值会被重置 0 无错误, message 为空 非0, 输出错误信息 | 单线程会显示 LAST_SQL_Errno LAST_SQL_Error 多线程不显示,显示coordinator的错误编号&信息 | 
| LAST_ERROR_TIMESTAMP | 发生错误时间:YYMMDD HH:MM:SS | Last_SQL_Error_Timestamp | 
2.5 replication_connection_configuration表 记录slave连接master配置参数-change master to时更新 使用频率较低
| replication_connection_configuration | 含义 | Change Master to | 
| CHANNEL_NAME | 显示复制渠道名称 | Channel_Name | 
| HOST/PORT/USER | Ip主机名/端口/用户名 | MASTER_HOST; MASTER_PORT; MASTER_USER; | 
| NETWORK_INTERFACE | Master实例网卡名称 | MASTER_BIND | 
| Auto_position | 是否开启自动定位 1 开启; 0 关闭 | MASTER_AUTO_POSITION | 
| SSL_ALLOWED | 是否开启SSL连接,YES/NO | MASTER_SSL | 
| SSL_CA_FILE; SSL_CA_PATH 等 | Master使用CA证书和秘钥 | MASTER_SSL_CA; MASTER_SSL_CPATH; | 
| Connection_retry_interval | 主从丢连接后 隔多少秒重试一次 | MASTER_CONNECTION_RETRY | 
| CONNECTION_RETRY_COUNT | 重试连接主库次数 | MASTER_RETRY_COUNT | 
| HEARTBEAT_INTERVAL | Slave连master的IO线程的心跳包的间隔时间, 单位S | MASTER_HEARTBEAT_PERIOD | 
2.6 replication_connection_status 表记录slave I/O线程的连接状态信息, 也记录组复制中其它节点连接信息
| replication_connection_status | 含义 | Change Master to | 
| CHANNEL_NAME | 显示复制渠道名称 | Channel_Name | 
| GROUP_NAME | 如果是组复制,显示所属组名字 | 无 | 
| SOURCE UUID | Slave连接 master 的 server_uuid | MASTER_UUID | 
| THREAD_ID | I/O 线程ID | 无 | 
| SERVICE_STATE | On: 从库 I/O线程处于活跃/空置状态 Off: 从库 I/O线程处于非活跃状态 CONNECTING I/O尝试连接master | SLAVE_IO_RUNNING | 
| RECEIVED_TRANSACTION_SET | Slave 接收到Master对应的GTID SET | Retrieved_Gtid_Set | 
| LAST_ERROR_NUMBER LAST_ERROR_MESSAGE | Slave coordinator线程发生错误而停止的最新错误编号; reset master&slave 该值会被重置 0 无错误, message 为空 非0, 输出错误信息 | LAST_SQL_Errno LAST_SQL_Error | 
| LAST_ERROR_TIMESTAMP | 发生错误时间:YYMMDD HH:MM:SS | Last_SQL_Error_Timestamp | 
| LAST_ HEARTBEAT _TIMESTAMP | Slave I/O线程最后一次收到master心跳信号的时间 YYMMDD HH:MM:SS | 无 | 
| COUNT_REVEIVED_HEARTBEATS | Slave收到 master的总次数 | 无 | 
2.7 replication_group_member_stats 表记录组复制成员的事务状态统计信息,仅在组复制中有效
| Channel_name | 组成员所在组使用的复制通道:group_replication_applier | 
| View_ID | 组成员所在组的当前试图标识符 | 
| Member_ID | 组成员server的UUID, 全局唯一 | 
| COUNT_TRANSACTIONS_IN_QUEUE | 队列中等待冲突检查的事务数(全局事务认证) | 
| COUNT_TRANSACTIONS_CHECKED | 表示已通过冲突检查的事务数(全局事务认证) | 
| COUNT_TRANSACTIONS_ROW_VAILDATING | 冲突检测数据库当前的大小 | 
| TRANSACTIONS_COMMITED_ALL_MEMBERS | 显示当前所有成员成功提交的事务 | 
| LAST_CONFLICT_FREE_TRANSACTION | 显示最后一次无冲突检查的事务表示符(最后一次没有冲突的GTID) | 
2.8 replication_group_members 表 组复制成员的网络和状态信息
| Channel_Name | 组成员所在组使用的复制通道:group_replication_applier | 
| MEMBER_ID | 显示当前组成员server的UUID,全局唯一 | 
| MEMBER_HOST | 组复制中组成员的网络地址(主机名/IP) | 
| MEMBER_PORT | 组复制中组成员的监听端口, | 
| MEMBER_STATE | 组复制中组成员的状态 Offline:组复制成员已经安装组复制插件,但未启动 RECOVERING: 组复制成员已经加入复制组,正在从组中接收数据,正在加入集群 Online: 组复制成员处于正常运行状态 | 
十 通过其它方式检查复制信息
10.1 Show slave status 语句输出详解
Slave_IO_State:  显示IO线程正在做什么
Master_Host: 192.168.1.100
Master_User: mysync
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.001822
Read_Master_Log_Pos: 290072815
Relay_Log_File: mysqld-relay-bin.005201
Relay_Log_Pos: 256529594
Relay_Master_Log_File: mysql-bin.001821
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: 
Last_Errno: 0
Last_Error: 
Skip_Counter: 0
Exec_Master_Log_Pos: 256529431
Relay_Log_Space: 709504534
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: 2923
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: 1
Master_UUID: 13ee75bb-99e2-11e6-be4d-b499baa80e6e
Master_Info_File: /home/data/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Reading event from the relay log
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
Slave_IO_state
1) waiting for master update: 这是connecting to master状态之前的状态
2) connecting to master: I/O线程正尝试连接到master
3) checking master version: 在与master建立连接后,会出现该状态。该状态出现的时间非常短暂。
4) registering slave on master:在与master建立连接后,会出现该状态。该状态出现的时间非常短暂。  
5) requesting binlog dump: 在与master建立连接后,会出现该状态。在这个状态下,I/O线程向master发送请求,请求binlog,位置从指定的binglog 名字和binglog的position位置开始
6) waiting to reconnect after a failed binlog dump request:如果因为连接断开,导致binglog的请求失败,I/O线程会进入睡眠状态。然后定期尝试重连。尝试重连的时间间隔,可以使用命令"change master to master_connect_trt=X;"改变。
7) reconnecting after a failed binglog dump request: I/O进程正在尝试连接master
8) waiting for master to send event: 说明,已经成功连接到master,正等待二进制日志时间的到达。如果master 空闲,这个状态会持续很长时间。如果等待的时间超过了slave_net_timeout(单位是秒)的值,会出现连接超时。在这种状态下,I/O线程会人为连接失败,并开始尝试重连
9) queueing master event to the relay log: 此时,I/O线程已经读取了一个event,并复制到了relay log 中。这样SQL 线程可以执行此event
10) waiting to reconnect after a failed master event read: 读取时出现的错误(因为连接断开)。在尝试重连之前,I/O线程进入sleep状态,sleep的时间是master_connect_try的值(默认是60秒)
11) reconnecting after a failed master event read: I/O线程正尝试重连master。如果连接建立,状态会变成"waiting for master to send event"
12) waiting for the slave sql thread to free enough relay log space: 这是因为设置了relay_log_space_limit,并且relay log的大小已经整张到了最大值。I/O线程正在等待SQL线程通过删除一些relay log,来释放relay log的空间
13) waiting for slave mutex on exit: I/O线程停止时会出现的状态,出现的时间非常短
| 1. Slave_IO_State | 这里显示了当前slave I/O线程的状态(slave连接到master的状态)。状态信息和使用show processlist | grep "system user"(会显示两条信息,一条slave I/O线程的,一条是slave SQL线程的)显示的内容一样。 | 
 | 
| 2. Master_Host | mysql主库的ip地址 | Change master to 语句中 MASTER_HOST选项 | 
| 3. Master_User | master上面的一个用户。用来负责主从复制的用户,创建主从复制的时候建立的(具有reolication slave权限) | Change master to 语句中 MASTER_USER选项 | 
| 4. Master_Port | master服务器的端口 | Change master to 语句中 MASTER_PORT选项 | 
| 5. Connect_Retry | 连接中断后,重新尝试连接的时间间隔。默认值是60秒 | Change master to master_connect_retry 设置 Slave_net_timeout = 60s 控制超时 | 
| #与master相关的日志的信息 | 
 | 
 | 
| 6. Master_Log_File | 当前I/O线程正在读取的主服务器二进制日志文件的名称 | Change master to 中的 master_log_file 来指定 | 
| 7. Read_Master_Log_Pos | 当前I/O线程正在读取的二进制日志的位置 | Change master to 语句中 master_log_pos 来指定 | 
| #与relay log相关的信息 | 
 | 
 | 
| 8. Relay_Log_File | 当前slave SQL线程正在读取并执行的relay log的文件名 | Change master to relay_log_file 来指定文件名 | 
| 9. Relay_Log_Pos | 当前slave SQL线程正在读取并执行的relay log文件中的位置;(Relay_Log_File下的Relay_Log_Pos其实一一对应着Relay_Master_Log_File的Exec_Master_Log_Pos。) | Change master to xxx relay_log_pos 指定 | 
| 10. Relay_Master_Log_File | Slave sql线程重放对应 master binlog 文件名 | 
 | 
| #slave I/O和SQL线程的状态(重要) | 
 | 
 | 
| 11. Slave_IO_Running | I/O线程是否被启动并成功地连接到主服务器上 | 三种状态 No: 从库I/O线程没有运行, 对应内部mysql_slave_not_run Connecting: I/O运行 但未连接到master 对应内部 mysql_slave_run_not_connect状态 Yes: I/O线程运行且连接到主库,mysql_slave_run_connect | 
| 12. Slave_SQL_Running | SQL线程是否被启动 | Yes / No 两种状态 | 
| 13. Replicate_Do_DB | 
 | 
 | 
| Replicate_Ignore_DB Replicate_Do_Table Replicate_Ignore_Table Replicate_Wild_Do_Table Replicate_Wild_Ignore_Table | 这些参数都是为了用来指明哪些库或表在复制的时候不要同步到从库,但是这些参数用的时候要小心,因为 当跨库使用的时候 可能会出现问题。 
 一般情况下 ,限制的时候都用Replicate_Wild_Ignore_Table这个参数 | 
 | 
| 14. Last_Errno Last_Error | slave的SQL线程读取日志参数的的错误数量和错误消息。错误数量为0并且消息为空字符串表示没有错误。 如果Last_Error值不是空值,它也会在从属服务器的错误日志中作为消息显示。 | 执行 reset master 和 reset slave 会重置这两列 | 
| 15. Skip_Counter | SQL_SLAVE_SKIP_COUNTER的值,用于设置跳过sql执行步数 | 系统变量 sql_slave_skip_counter当前的设置值 | 
| 16. Exec_Master_Log_Pos | slave SQL线程当前执行的事件,对应在master相应的二进制日志中的position | 结合Relay_Master_Log_File理解,而且在Relay_Master_Log_File这个值等于Master_Log_File值的时候,Exec_Master_Log_Pos是不可能超过Read_Master_Log_Pos的 | 
| 17. Relay_Log_Space | 所有原有的中继日志结合起来的总大小。 | 
 | 
| 18. Until_Condition: Until_Log_File: Until_Log_Pos: 0 | 在START SLAVE语句的UNTIL子句中指定的值 | Until_Condition具有以下值: 1) None 没有指定UNTIL子句,则没有值 2) Master从属服务器正在读取,直到达到主服务器的二进制日志的给定位置为止 3) Relay从属服务器正在读取,直到达到其中继日志的给定位置为止,则值为 Until_Log_File和Until_Log_Pos用于指示日志文件名和位置值。日志文件名和位置值定义了SQL线程在哪个点中止执行 4) sql_before_gtids :SQL线程执行事务直到GTID SET 中列出的第一个事务为止 5) sql_after_gtids :直到最后一个事务为止 6) sql_after_mts_gaps: 直到中继日志找不到更多日志组间隙为止 | 
| 19. Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Master_SSL_Verify_Server_Cert: No Master_SSL_Crl: Master_SSL_Crlpath: | 这些字段显示了被从属服务器使用加密相关的参数。这些参数用于连接主服务器 | Master_SSL_Allowed具有以下值: 
 1) 如果允许对主服务器进行SSL连接,则值为Yes 2) 如果不允许对主服务器进行SSL连接,则值为No 3) 如果允许SSL连接,但是从属服务器没有让SSL支持被启用,则值为Ignored。 与SSL有关的字段的值对应于–master-ca,–master-capath,–master-cert,–master-cipher和–master-key选项的值。 | 
| 20. seconds_Behind_Master | 这个值是时间戳的差值。是slave当前的时间戳和master记录该事件时的时间戳的差值 | 单位 S | 
| 21. Last_IO_Errno: Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: | 最后一次I/O线程或者SQL线程的错误号和错误消息 | 多线程复制, last_sql_error 对应performance_schema.repliacation_applier_status_by_coordinator 中last_error_message列 | 
| 22. Replicate_Ignore_Server_Ids | 主从复制,从库忽略的主库服务器Id号。就是不以这些服务器Id为主库 | 使用多源复制时候,忽略哪些主库, Replicate_ignore_server_ids: 3,6,9 | 
| 23. Master_Server_Id Master_UUID Master_Info_File | 分别表示主库服务器id号, 主库服务器的UUID号, 从库中保存主库服务器相关的目录位置 | Master_info_file 用于保存I/O线程信息 master.info文件位置, File类型:一个路径 Table 类型:mysql.slave_master_info 表 | 
| 24. SQL_Delay | 一个非负整数,表示秒数,Slave滞后多少秒于master | 
 | 
| 25. SQL_Remaining_Delay | 当 Slave_SQL_Running_State 等待,直到MASTER_DELAY秒后,Master执行的事件,此字段包含一个整数,表示有多少秒左右的延迟。在其他时候,这个字段是NULL | 延迟从库时候使用,防止逻辑删除 | 
| 26. Slave_SQL_Running_State | SQL线程运行状态; 与slave_io_state类似,显示 Show processlist语句中 SQL线程状态的副本信息 
 | SQL线程运行状态: 
 1) Reading event from the relay log 线程已经从中继日志读取一个事件,可以对事件进行处理了 2) Has read all relay log; waiting for the slave I/O thread to update it 线程已经处理了中继日志文件中的所有事件,现在正等待I/O线程将新事件写入中继日志 3) Waiting for slave mutex on exit 线程停止时发生的一个很简单的状态 | 
| 27. Master_Retry_Count | 连接主库失败最多的重试次数 | 默认是 24 * 3600 = 86400次 master_retry_count指定 | 
| 28. Master_Bind | slave从库在多网络接口的情况下使用,以确定用哪一个slave网络接口连接到master | Change master to 中 master_bind 指定网卡名称 | 
| 29. Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp | 最后一次I/O线程或者SQL线程错误时的时间戳 | 格式 YYMMDD HH:MM:SS | 
| #GTID模式相关 | 
 | 
 | 
| 30. Retrieved_Gtid_Set | Slave收到的所有事物对应的GTID<IO线程> | 该字段的 GTID SET 中最大的GTID值与中继日志最大的GTID值相对应, 执行 reset slave & change master to 会导致中继日志被清除 | 
| 31.Executed_Gtid_Set | Slave 在自己的binlog 中写入的 GTID SET (执行过的GTID<SQL线程>) | 
 | 
| 32 auto_position | 如果开启自动定位则为1 ,否则为0 | 
 | 
| 33 replicate_rewrite_db | 主库上的db名在从库重放是被指定到另一个db名下 | Change replication replicate_rewrite_db=((db1,db2),(db3,db4)) Db1 写入db3, db2 写入db4 | 
| 34 channle_name | 默认的复制通道名称,如果没有多源复制,该字段为空 | 
 | 
| 35 Master_TLS_Version | Master上 TLS版本 | 5.7.10新增的选项 | 
10.2 show master status
| File | master库当前正在使用binlog文件名 | 
| Position | Master 当前使用binlog的位置 | 
| Binlog_do_bd | 主库当前生效的复制规律参数,只有该选项指定的库列表中的库写入数据时, 才会被记录到binlog中 | 
| Binlog_ignore_db | 主库当前生效的复制过滤参数, 该参数指定的库列表中的库发生数据写入,不会被记录到binlog中 | 
| Executed_gtid_set | 启用GTID时, executed_gtid_set 显示主库上数据当前的GTID set , 与系统变量 gtid_executed值 以及 show slave status的语句输出的 Executed_gtid_set字段相同 | 
10.3 show slave hosts 语句 显示当前主库所连接的从库列表
| Server_id | 从库的server_id 全局唯一 | 
| Host | 从库的主机名,可使用IP地址 | 
| User/ Passwrod/ | 从库连接主库的用户名/密码/端口号 | 
| Master_id | 表当前从库从哪个主库进行复制 | 
| Slave_UUID | 全局唯一UUID,启动自动生成, auto.cnf下保存 | 
- 点赞
- 收藏
- 关注作者
 
             
           
评论(0)