1. Python技术站首页
  2. 数据库
  3. MySQL

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

• MySQL
yizhihongxing

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

 

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

 

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。工作中需要注意结合这些表的使用更好的排查问题。

 

原文链接：https://www.cnblogs.com/coygfly/p/17361132.html

本站文章如无特殊说明，均为本站原创，如若转载，请注明出处：Performance_schema中的主从复制系列表总结 - Python技术站

赞 (0)
0 0 打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023年4月27日
下一篇 2023年4月30日

相关文章

  • MySQL启动失败之MySQL服务无法启动的原因及解决

    MySQL启动失败之MySQL服务无法启动的原因及解决 问题描述 在启动MySQL服务时，可能会遇到MySQL无法启动的情况，表现为服务启动失败、MySQL进程启动失败等。这个问题可能会影响用户的正常使用，因此需要进行解决。 可能的原因 MySQL服务无法启动的原因有很多，根据实际情况，可以从以下几个方面进行解决： 1. MySQL配置文件错误 MySQL配…

    MySQL 2023年5月18日
    00

  • Win10安装mysql8.0.15 winx64及连接服务器过程中遇到的问题

    下面为你提供 Win10 安装 MySQL 8.0.15 Winx64 及连接服务器过程中遇到的问题的完整攻略。 安装 MySQL 8.0.15 Winx64 打开 MySQL 官网，下载 Windows (x86, 64-bit), MSI Installer 版本的 MySQL 8.0.15。 下载完成后，直接双击下载文件，一路点击即可完成 MySQL …

    MySQL 2023年5月18日
    00

  • mysql服务启动不了解决方案

    这里提供一份基于Ubuntu 18.04操作系统的MySQL服务无法启动的解决方案攻略，可以尝试按照以下步骤解决问题。 1. 检查MySQL服务是否正在运行 首先，我们需要检查MySQL服务是否正在运行。可以通过运行以下命令来检查它： sudo systemctl status mysql 如果看到以下输出，说明MySQL正在运行： ● mysql.serv…

    MySQL 2023年5月18日
    00

  • MySQL无法读表错误的解决方法（MySQL 1018 error）

    MySQL无法读表错误指的是在使用MySQL时，查询或操作某个表时出现异常，无法正常进行操作。这个错误通常会伴随着一个error code: 1018。 这个错误通常有多种原因，包括权限问题、表的损坏等等。下面我们将详细讲解MySQL无法读表错误的解决方法。 1. 确认权限问题 首先，我们要确认一下是否是权限问题导致的错误。在MySQL中，如果当前用户没有足…

    MySQL 2023年5月18日
    00

  • mysql提示Can’t connect to MySQL server on localhost (10061)完美解决方法

    针对这个问题，“mysql提示Can’t connect to MySQL server on localhost (10061)”出现后，我们可以尝试以下几个步骤来解决问题。 1、检查MySQL服务是否开启 首先，我们需要确认MySQL服务是否已经开启。可以通过以下方式检查服务状态： sudo systemctl status mysql 如果服务已经开启…

    MySQL 2023年5月18日
    00

  • MySQL细数发生索引失效的情况

    MySQL细数发生索引失效的情况 前言 在MySQL中，为了加速查询操作，我们通常会通过创建索引来提高查询效率。但是，如果我们不小心创建索引或者索引过期、被删除等情况时，会导致索引失效，查询效率降低，甚至直接影响业务运行。如何防止索引失效？需要从什么方面入手呢？本文将详细讲解MySQL中的索引失效原因和解决方案。 为什么会发生索引失效？ 1. 不到万不得已就…

    MySQL 2023年5月19日
    00

  • 实验六 存储过程

    实验六 存储过程 第1关：增加供应商相关列sqty use demo; #代码开始 #在S表中增加一列供应零件总数量（sqty），默认值为0。 altertable s add sqty intdefault0; #代码结束 desc s; 第2关：定义、调用简单存储过程 use demo; #代码开始 #1、定义简单存储过程：计算所有供应商供应零件总数量并…

    MySQL 2023年5月10日
    00

  • SQL注入是什么？SQL注入原理及预防方法

    SQL注入是一种针对Web应用程序的攻击方法，攻击者通过注入恶意的SQL语句来获取或修改数据库中的数据。攻击者可以利用各种SQL注入技术来执行操作，包括数据盗取、数据修改和数据删除等。 SQL注入是利用了应用程序对用户输入数据的不充分验证，把恶意的SQL代码注入到应用程序的查询语句中，通过这种方式来控制或者破坏数据库的行为 SQL注入攻击是Web应用程序最常…

    MySQL 2023年3月10日
    00
合作推广
合作推广
分享本页
返回顶部