首页 > 其他分享 >Performance_schema中的主从复制系列表总结

Performance_schema中的主从复制系列表总结

时间:2023-04-28 10:37:51浏览次数:47  
标签:status 主从复制 TRANSACTION LAST TIMESTAMP 00 ERROR Performance schema

主从半同步复制是目前用得最多的MySQL复制方案,日常工作中我们一般通过show slave status语句查看当前复制过程中状态信息,基本上能满足大多数场景下的需求。Performance_schema中提供了16个关于复制的监控表(包括组复制、过滤复制等,这里我们先不讨论),show slave status中的大多数信息都来自Performance_schema中的复制系列表,这些表有利于更好的收集主从复制中的状态,报错,配置等信息,并且比show slave status提供了更全面的主从复制的诊断信息。这些表主要可以分为两类,分别为IO进程和SQL进程的信息:

 

 

replication_connection_configuration

这张表主要显示了从库连接到主库的配置参数,包括复制用户、主库地址、端口等,随着change master to命令语句改变。

replication_connection_status

主要包括当前IO线程的状态信息,IO线程相关错误信息,relaylog中上个排队和当前正在排队的事务信息。当因为连接失败等问题导致IO进程停止时,可以通过这张表排查错误信息。

mysql> select * from performance_schema.replication_connection_status\G
*************************** 1. row ***************************
                                      CHANNEL_NAME: 
                                        GROUP_NAME: 
                                       SOURCE_UUID: c8e82820-16c4-11ed-8677-005056b65258
                                         THREAD_ID: 341
                                     SERVICE_STATE: ON
                         COUNT_RECEIVED_HEARTBEATS: 67076
                          LAST_HEARTBEAT_TIMESTAMP: 2023-04-27 15:20:29.393141
                          RECEIVED_TRANSACTION_SET: c8e82820-16c4-11ed-8677-005056b65258:12-37
                                 LAST_ERROR_NUMBER: 0
                                LAST_ERROR_MESSAGE: 
                              LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
                           LAST_QUEUED_TRANSACTION: c8e82820-16c4-11ed-8677-005056b65258:37
 LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 2023-04-26 14:37:27.673466
LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 2023-04-26 14:37:27.673466
     LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP: 2023-04-26 14:40:51.513510
       LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP: 2023-04-26 14:40:51.513521
                              QUEUEING_TRANSACTION: 
    QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
   QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
        QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
1 row in set (0.00 sec)

replication_applier_configuration

这个表包含影响从库回放事务的配置参数,比如REQUIRE_TABLE_PRIMARY_KEY_CHECK(开启主键校验)、DESIRED_DELAY(延迟复制配置)。

replication_applier_status

这个表显示从库SQL线程的状态总信息,现在生产中一般都开启了多线程复制,多线程复制下SQL线程状态主要看replication_applier_status_by_coordinator table 和replication_applier_status_by_worker这两张表。

replication_applier_status_by_coordinator 

对于多线程复制,从库使用了多个复制线程(work thread),并且开启了一个协调线程(coordinator thread)来管理它们。这个表显示了协调线程的状态信息和错误信息,并且包括上一个被协调线程buffer的事务,以及当前协调线程正在buffer的事务。在多线程复制中,首先由协调线程从relaylog中读取并缓存需要执行事务,然后再把事务分配给其中一个复制线程。

mysql> select * from performance_schema.replication_applier_status_by_coordinator\G
*************************** 1. row ***************************
                                         CHANNEL_NAME: 
                                            THREAD_ID: 342
                                        SERVICE_STATE: ON
                                    LAST_ERROR_NUMBER: 0
                                   LAST_ERROR_MESSAGE: 
                                 LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
                           LAST_PROCESSED_TRANSACTION: c8e82820-16c4-11ed-8677-005056b65258:37
 LAST_PROCESSED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 2023-04-26 14:37:27.673466
LAST_PROCESSED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 2023-04-26 14:37:27.673466
    LAST_PROCESSED_TRANSACTION_START_BUFFER_TIMESTAMP: 2023-04-26 14:42:29.097360
      LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP: 2023-04-26 14:42:29.098834
                               PROCESSING_TRANSACTION: 
     PROCESSING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
    PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
        PROCESSING_TRANSACTION_START_BUFFER_TIMESTAMP: 0000-00-00 00:00:00.000000
1 row in set (0.00 sec)

replication_applier_status_by_worker

这个表显示了多线程复制中从库各个回放线程(applier thread)的状态及错误信息,applier thread也称workers。如果从库SQL线程在回放事务中报错,需要查询这个表获取详细的报错信息。如下图所示,下面的报错显示了SQL线程在回放事务过程中由于notest表中的某条记录不存在导致写入失败:

mysql> select * from performance_schema.replication_applier_status_by_worker where last_error_message != ''\G
*************************** 1. row ***************************
                                           CHANNEL_NAME: 
                                              WORKER_ID: 1
                                              THREAD_ID: NULL
                                          SERVICE_STATE: OFF
                                      LAST_ERROR_NUMBER: 1032
                                     LAST_ERROR_MESSAGE: Worker 1 failed executing transaction 'c8e82820-16c4-11ed-8677-005056b65258:38' at master log bin.000012, end_log_pos 3315; Could not execute Update_rows event on table test.notest; Can't find record in 'notest', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log FIRST, end_log_pos 3315
                                   LAST_ERROR_TIMESTAMP: 2023-04-28 09:45:59.684586
                               LAST_APPLIED_TRANSACTION: 
     LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
    LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
         LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000
           LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000
                                   APPLYING_TRANSACTION: c8e82820-16c4-11ed-8677-005056b65258:38
         APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 2023-04-28 09:45:59.673804
        APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 2023-04-28 09:45:59.673804
             APPLYING_TRANSACTION_START_APPLY_TIMESTAMP: 2023-04-28 09:45:59.684183
                 LAST_APPLIED_TRANSACTION_RETRIES_COUNT: 0
   LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER: 0
  LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE: 
LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
                     APPLYING_TRANSACTION_RETRIES_COUNT: 0
       APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER: 0
      APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE: 
    APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
1 row in set (0.00 sec)

mysql.slave_master_info

此外mysql.slave_master_info这个表也需要注意,这个表显示了复制用户的明文密码,因此需要注意两点:

1.不要给复制用户repl授予除了REPLICATION SLAVE以外的权限,防止被获取明文密码后,利用这个用户进行一些高危操作。

2.在给数据库重建主从复制或者新加从库时,如果忘记了复制用户的密码,不需要再重置,可以通过这个表获取。

mysql> select * from mysql.slave_master_info\G
*************************** 1. row ***************************
                Number_of_lines: 33
                Master_log_name: bin.000012
                 Master_log_pos: 197
                           Host: 10.3.111.102
                      User_name: repl
                  User_password: PASSW0RD
                           Port: 3306
                  Connect_retry: 60
                    Enabled_ssl: 0
                         Ssl_ca: 
                     Ssl_capath: 
                       Ssl_cert: 
                     Ssl_cipher: 
                        Ssl_key: 
         Ssl_verify_server_cert: 0
                      Heartbeat: 30
                           Bind: 
             Ignored_server_ids: 0
                           Uuid: c8e82820-16c4-11ed-8677-005056b65258
                    Retry_count: 86400
                        Ssl_crl: 
                    Ssl_crlpath: 
          Enabled_auto_position: 1
                   Channel_name: 
                    Tls_version: 
                Public_key_path: 
                 Get_public_key: 0
              Network_namespace: 
   Master_compression_algorithm: uncompressed
  Master_zstd_compression_level: 3
               Tls_ciphersuites: NULL
Source_connection_auto_failover: 0
                      Gtid_only: 0

 

总结一下,show slave status已经是一个比较全面的监控了,其他用的比较多的performance_schema中的关于复制的表有replication_applier_status_by_worker、The replication_applier_status_by_coordinator、replication_connection_status。工作中需要注意结合这些表的使用更好的排查问题。

 

标签:status,主从复制,TRANSACTION,LAST,TIMESTAMP,00,ERROR,Performance,schema
From: https://www.cnblogs.com/coygfly/p/17361132.html

相关文章

  • redis之持久化方案,主从复制,哨兵高可用,集群原理及搭建,缓存优化
    目录redis之持久化方案,主从复制,哨兵高可用,集群原理及搭建,缓存优化昨日内容回顾今日内容详细1持久化方案1.1RDB1.2aof方案1.3混合持久化2主从复制原理和方案3哨兵高可用4集群原理及搭建4.1集群搭建4.2集群扩容4.3集群缩容5缓存优化5.1redis缓存更新策略5.2缓存穿透击......
  • MySQL主从复制详解
    主从复制原理+实操什么是MySQL主从复制?​MySQL主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL默认采用异步复制方式,这样从节点不用一直访问主服务器来更新自己的数据,数据的更新可以在远程连接上进行,从节点可以复制主数据库中的所有数据库或......
  • MySQL主从复制搭配SharingSphere踩大坑记录
    报错内容:Causedby:java.util.NoSuchElementException:Novaluebound点击查看原始错误代码ErrorstartingApplicationContext.Todisplaytheconditionsreportre-runyourapplicationwith'debug'enabled.2023-04-2616:34:48.270ERROR22584---[......
  • MySQL主从复制Slave_IO_Running为No
    主要记录解决问题的过程,为以后发现类似问题提供解决方法的参考。首先查看从机的mysql日志文件:tail/var/log/mysqld.log日志从上往下看,可以很快看到在中间位置上有一个ERROR的标志,后面写得很清楚,我的主机UUID和从机UUID重复了,而这两个UUID在这里要求必须要不相等的,所以我上面......
  • 10 iozone Examples for Disk I/O Performance Measurement on Linux
    https://www.thegeekstuff.com/2011/05/iozone-examples/ Aswediscussedinour Linuxperformancemonitoringintroduction article,measuringIOsubsystemperformanceisveryimportant.Ifsomeoneiscomplainingthatadatabase(oranyapplication)running......
  • Centos7配置Mysql8主从复制同步数据
    1.首先需要在三台不同主机安装好mysql8,参考:https://www.cnblogs.com/haoxuanchen2014/p/17351034.html主库ip:192.168.2.66从库1ip:192.168.2.67从库2ip:192.168.2.682.配置主库第一步:添加配置文件/etc/my.cnf加多下面两句代码如下(示例):[mysqld]server-id=101 #[必......
  • XML Schema学习
    XMLSchema简介XMLSchena的作用是定义XML文档的划分构建模块。XMLSchema是基于XML的DTD代替者,XMLSchema可描述XML文档的结构。定义可出现在文档中的元素定义可出现在文档中的属性定义那个元素是子元素定义子元素的次序定义子元素的数目定义元素是否为空,或者是否包含文......
  • redis,持久化RDB,AOF,混合(AOF),主从复制原理和方案,哨兵高可用
    内容回顾#悲观乐观锁: django中如何实现 -悲观锁:mysql行锁表锁-乐观锁:真正修改时,加入限制条件django中事务如何开启 -原生sql如何开启事务:begin;commit; -django中如何开事务:atomic()commit()for_update是锁表还是锁行如果查......
  • Unlock the Power of High-Performance Networking with the IPQ9554
    UnlockthePowerofHigh-PerformanceNetworkingwiththeIPQ9554Intoday'sworld,reliableandhigh-speedinternetconnectivityisessentialforeverythingfromonlinegamingandstreamingtoremoteworkandlearning.Whetheryou'reaconsumer......
  • redis高级:持久化方案、主从复制原理和方案、哨兵高可用
    目录一、持久化方案1、什么是持久化2、持久化的实现方式3、RDB4、aof方案5、RDB和AOF的选择6、混合持久化二、主从复制原理和方案1、为什么要用主从复制2、主从复制介绍3、redis主从赋值流程,原理三、哨兵高可用1、什么是高可用2、哨兵实现高可用3、哨兵实现高可用搭建步骤一、持......