Performance_schema中的主從複製系列表總結

来源:https://www.cnblogs.com/coygfly/archive/2023/04/28/17361132.html
-Advertisement-
Play Games

Hadoop概述 Hadoop是什麼 hadoop是一個由Apache基金會所開發的分散式系統基礎框架 其主要解決，海量數據的存儲和海量數據的的分析計算問題 廣義上，Hadoop通常是指一個更加廣泛的概念——Hadoop生態圈 Hadoop的發展歷史 Hadoop創始人Doug Cutting，為了 ...


主從半同步複製是目前用得最多的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。工作中需要註意結合這些表的使用更好的排查問題。

 


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • ASP.NET Core MVC 從入門到精通之資料庫
    隨著技術的發展，ASP.NET Core MVC也推出了好長時間，經過不斷的版本更新迭代，已經越來越完善，本系列文章主要講解ASP.NET Core MVC開發B/S系統過程中所涉及到的相關內容，適用於初學者，在校畢業生，或其他想從事ASP.NET Core MVC 系統開發的人員。 經過前幾篇文章... ...
  • .NET使用一行命令輕鬆生成EF Core項目框架
    dotnet ef是Entity Framework Core（EF Core）的一個命令行工具，用於管理EF Core應用程式的資料庫和代碼。除了提供管理資料庫的命令之外，dotnet ef還可以生成和管理實體和上下文代碼。本文將介紹如何使用dotnet ef動態生成代碼。 一、環境準備 1、項目 ...
  • C# 位元組數組、各進位字元串數據互轉
    上位機開發過程中，格式轉換是必不可少的重要環節，經常是十進位轉十六進位、十六進位轉`byte`數組又轉換回來來迴轉換，最然進位轉換很基礎同時 C# 也提供了很多直接方便進行格式轉換的方法，但是封裝一個工具類會方便很多，不用每次都手寫代碼邏輯，之前一直都是簡單的自己寫，稍複雜的就用前輩寫好的直接調用，... ...
  • 如何通過C#/VB.NET 代碼調整PDF文檔的頁邊距
    PDF邊距是頁面主要內容區域和頁面邊緣之間的距離。與Word頁邊距不同，PDF文檔的頁邊距很難更改。因為Adobe沒有提供操作頁邊距的直接方法。但是，您可以通過縮放頁面內容來改變頁邊距。本文將介紹如何在不更改頁面大小的情況下使用C#/VB.NET 代碼調整PDF文檔的頁邊距。 增加PDF文檔的頁邊距 ...
  • 外鍵拆分手記
    我習慣性使用OData，它的$expand與層級查詢非常好用，這個功能非常依賴於資料庫的導航屬性，也就是外鍵結構。最近想著把一個單體的系統拆分為多個小系統，首先需要處理外鍵依賴的問題。 多個服務各自有各自的資料庫，資料庫層面並不互通，也就無法使用外鍵約束。 我使用EF Core來描述資料庫的結構，有 ...
  • 聊聊開關和CPU之間故事
    作者：小牛呼嚕嚕 | https://xiaoniuhululu.github.io 大家好，我是呼嚕嚕，在先前的一篇文章電腦中數值和字元串怎麼用二進位表示？中，我們知道了電腦為什麼會採用 0 和 1 組成的二進位，來表示所有的信息，比如機器指令、數字、字元串、聲音、圖片、視頻等等。 我們本篇文 ...
  • 快速上手Linux核心命令（九）：文件備份與壓縮
    (文件備份與壓縮) 這期呢主要說一說Linux中文件備份與壓縮命令，一共6個命令。這6個命令都是平常工作中非常非常常用的。 tar 打包備份 1、簡介 tar 可以將多個文件壓縮打包、壓縮。是工作中經常用到的命令 2、語法格式 tar [參數選項] [文件或目錄] 3、參數說明 | 參數 | 參數說 ...
  • day08-優惠券秒殺04
    功能03-優惠券秒殺04 4.功能03-優惠券秒殺 4.7Redis優化秒殺 4.7.1優化分析 現在來回顧一下優惠券秒殺業務的兩個主要問題： （1）首先是對優惠券的扣減，需要防止庫存超賣現象； （2）其次，需要對每個用戶下單數量進行限制，實現一人一單的功能。 處理秒殺優惠券的業務： 先根據獲取到的 ...
一周排行
    -Advertisement-
    Play Games
  • WPF 已知問題 監聽 WMI 事件導致觸摸失效
    示例項目結構 在 Visual Studio 中創建一個 WinForms 應用程式後，項目結構如下所示： MyWinFormsApp/ │ ├───Properties/ │ └───Settings.settings │ ├───bin/ │ ├───Debug/ │ └───Release/ ...
  • [STAThread]特性
    [STAThread] 特性用於需要與 COM 組件交互的應用程式，尤其是依賴單線程模型（如 Windows Forms 應用程式）的組件。在 STA 模式下，線程擁有自己的消息迴圈，這對於處理用戶界面和某些 COM 組件是必要的。 [STAThread] static void Main(stri ...
  • UWP WinUI3 傳入 AddHandler 的 RoutedEventHandler 類型與事件所需不匹配將拋出參數異常
    在WinForm中使用全局異常捕獲處理 在WinForm應用程式中，全局異常捕獲是確保程式穩定性的關鍵。通過在Program類的Main方法中設置全局異常處理，可以有效地捕獲並處理未預見的異常，從而避免程式崩潰。 註冊全局異常事件 [STAThread] static void Main() { / ...
  • .NET 多版本 WinForm 開源控制項庫 SunnyUI
    前言 給大家推薦一款開源的 Winform 控制項庫，可以幫助我們開發更加美觀、漂亮的 WinForm 界面。 項目介紹 SunnyUI.NET 是一個基於 .NET Framework 4.0+、.NET 6、.NET 7 和 .NET 8 的 WinForm 開源控制項庫，同時也提供了工具類庫、擴展 ...
  • .net core8 使用Swagger（附當前源碼）
    說明 該文章是屬於OverallAuth2.0系列文章，每周更新一篇該系列文章（從0到1完成系統開發）。 該系統文章，我會儘量說的非常詳細，做到不管新手、老手都能看懂。 說明：OverallAuth2.0 是一個簡單、易懂、功能強大的許可權+可視化流程管理系統。 有興趣的朋友，請關註我吧(*^▽^*) ...
  • WPF 什麼時候 VisualTreeHelper.GetDescendantBounds 將返回無窮大
    一、下載安裝 1.下載git 必須先下載並安裝git，再TortoiseGit下載安裝 git安裝參考教程：https://blog.csdn.net/mukes/article/details/115693833 2.TortoiseGit下載與安裝 TortoiseGit，Git客戶端，32/6 ...
  • C# 開源教程帶你輕鬆掌握數據結構與演算法
    前言 在項目開發過程中，理解數據結構和演算法如同掌握蓋房子的秘訣。演算法不僅能幫助我們編寫高效、優質的代碼，還能解決項目中遇到的各種難題。 給大家推薦一個支持C#的開源免費、新手友好的數據結構與演算法入門教程：Hello演算法。 項目介紹 《Hello Algo》是一本開源免費、新手友好的數據結構與演算法入門 ...
  • 第22篇 生成proto文件bat腳本
    1.生成單個Proto.bat內容 @rem Copyright 2016, Google Inc. @rem All rights reserved. @rem @rem Redistribution and use in source and binary forms, with or with ...
  • 記一次 .NET某上位機視覺程式 卡死分析
    一：背景 1. 講故事 前段時間有位朋友找到我，說他的窗體程式在客戶這邊出現了卡死，讓我幫忙看下怎麼回事？dump也生成了，既然有dump了那就上 windbg 分析吧。 二：WinDbg 分析 1. 為什麼會卡死 窗體程式的卡死，入口門檻很低，後續往下分析就不一定了，不管怎麼說先用 !clrsta ...
  • 醫學DICOM文件與PACS系統進行數據傳輸
    前言 人工智慧時代，人臉識別技術已成為安全驗證、身份識別和用戶交互的關鍵工具。 給大家推薦一款.NET 開源提供了強大的人臉識別 API，工具不僅易於集成，還具備高效處理能力。 本文將介紹一款如何利用這些API，為我們的項目添加智能識別的亮點。 項目介紹 GitHub 上擁有 1.2k 星標的 C# ...
所有分類