主頁 > 資料庫 > Performance_schema中的主從復制系串列總結

Performance_schema中的主從復制系串列總結

2023-04-28 12:15:09 資料庫

主從半同步復制是目前用得最多的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，作業中需要注意結合這些表的使用更好的排查問題，

 

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/551403.html

標籤：其他

上一篇：[20230425]CBO cost與行遷移關系.txt

下一篇：返回列表

標籤雲
其他(158257) Python(38107) JavaScript(25396) Java(18003) C(15217) 區塊鏈(8260) C＃(7972) AI(7469) 爪哇(7425) MySQL(7152) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5870) 数组(5741) R(5409) Linux(5332) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4564) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2432) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1961) Web開發(1951) HtmlCss(1928) python-3.x(1918) 弹簧靴(1913) C++(1912) xml(1889) PostgreSQL(1874) .NETCore(1855) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • GPU虛擬機創建時間深度優化

    **?桔妹導讀：**GPU虛擬機實體創建速度慢是公有云面臨的普遍問題，由于通常情況下創建虛擬機屬于低頻操作而未引起業界的重視，實際生產中還是存在對GPU實體創建時間有苛刻要求的業務場景。本文將介紹滴滴云在解決該問題時的思路、方法、并展示最終的優化成果。 從公有云服務商那里購買過虛擬主機的資深用戶，一 ......

    uj5u.com 2020-09-10 06:09:13 more
  • 可編程網卡芯片在滴滴云網路的應用實踐

    **?桔妹導讀：**隨著云規模不斷擴大以及業務層面對延遲、帶寬的要求越來越高，采用DPDK 加速網路報文處理的方式在橫向縱向擴展都出現了局限性。可編程芯片成為業界熱點。本文主要講述了可編程網卡芯片在滴滴云網路中的應用實踐，遇到的問題、帶來的收益以及開源社區貢獻。 #1. 資料中心面臨的問題 隨著滴滴 ......

    uj5u.com 2020-09-10 06:10:21 more
  • 滴滴資料通道服務演進之路

    **?桔妹導讀：**滴滴資料通道引擎承載著全公司的資料同步，為下游實時和離線場景提供了必不可少的源資料。隨著任務量的不斷增加，資料通道的整體架構也隨之發生改變。本文介紹了滴滴資料通道的發展歷程，遇到的問題以及今后的規劃。 #1. 背景 資料，對于任何一家互聯網公司來說都是非常重要的資產，公司的大資料 ......

    uj5u.com 2020-09-10 06:11:05 more
  • 滴滴AI Labs斬獲國際機器翻譯大賽中譯英方向世界第三

    **桔妹導讀：**深耕人工智能領域，致力于探索AI讓出行更美好的滴滴AI Labs再次斬獲國際大獎，這次獲獎的專案是什么呢？一起來看看詳細報道吧！ 近日，由國際計算語言學協會ACL（The Association for Computational Linguistics）舉辦的世界最具影響力的機器 ......

    uj5u.com 2020-09-10 06:11:29 more
  • MPP (Massively Parallel Processing)大規模并行處理

    1、什么是mpp？ MPP (Massively Parallel Processing)，即大規模并行處理，在資料庫非共享集群中，每個節點都有獨立的磁盤存盤系統和記憶體系統，業務資料根據資料庫模型和應用特點劃分到各個節點上，每臺資料節點通過專用網路或者商業通用網路互相連接，彼此協同計算，作為整體提供 ......

    uj5u.com 2020-09-10 06:11:41 more
  • 滴滴資料倉庫指標體系建設實踐

    **桔妹導讀：**指標體系是什么？如何使用OSM模型和AARRR模型搭建指標體系？如何統一流程、規范化、工具化管理指標體系？本文會對建設的方法論結合滴滴資料指標體系建設實踐進行解答分析。 #1. 什么是指標體系 ##1.1 指標體系定義 指標體系是將零散單點的具有相互聯系的指標，系統化的組織起來，通 ......

    uj5u.com 2020-09-10 06:12:52 more
  • 單表千萬行資料庫 LIKE 搜索優化手記

    我們經常在資料庫中使用 LIKE 運算子來完成對資料的模糊搜索，LIKE 運算子用于在 WHERE 子句中搜索列中的指定模式。 如果需要查找客戶表中所有姓氏是“張”的資料，可以使用下面的 SQL 陳述句： SELECT * FROM Customer WHERE Name LIKE '張%' 如果需要 ......

    uj5u.com 2020-09-10 06:13:25 more
  • 滴滴Ceph分布式存盤系統優化之鎖優化

    **桔妹導讀：**Ceph是國際知名的開源分布式存盤系統，在工業界和學術界都有著重要的影響。Ceph的架構和演算法設計發表在國際系統領域頂級會議OSDI、SOSP、SC等上。Ceph社區得到Red Hat、SUSE、Intel等大公司的大力支持。Ceph是國際云計算領域應用最廣泛的開源分布式存盤系統， ......

    uj5u.com 2020-09-10 06:14:51 more
  • es~通過ElasticsearchTemplate進行聚合~嵌套聚合

    之前寫過《es~通過ElasticsearchTemplate進行聚合操作》的文章，這一次主要寫一個嵌套的聚合，例如先對sex集合，再對desc聚合，最后再對age求和，共三層嵌套。 Aggregations的部分特性類似于SQL語言中的group by，avg，sum等函式,Aggregation ......

    uj5u.com 2020-09-10 06:14:59 more
  • 爬蟲日志監控 -- Elastc Stack（ELK）部署

    傻瓜式部署，只需替換IP與用戶 導讀： 現ELK四大組件分別為：Elasticsearch（核心）、logstash（處理）、filebeat（采集）、kibana（可視化） 下載均在https://www.elastic.co/cn/downloads/下tar包，各組件版本最好一致，配合fdm會 ......

    uj5u.com 2020-09-10 06:15:05 more
最新发布
  • Performance_schema中的主從復制系串列總結

    主從半同步復制是目前用得最多的MySQL復制方案，日常作業中我們一般通過show slave status陳述句查看當前復制程序中狀態資訊，基本上能滿足大多數場景下的需求。Performance_schema中提供了16個關于復制的監控表（包括組復制、過濾復制等，這里我們先不討論），show slav ......

    uj5u.com 2023-04-28 12:15:09 more
  • [20230425]CBO cost與行遷移關系.txt

    [20230425]CBO cost與行遷移關系.txt--//一般現在很少使用analyze table分析表,如果出現大量行遷移是否考慮看看是否考慮cbo cost成本.--//測驗參考鏈接:--//https://richardfoote.wordpress.com/2023/03/21/cb ......

    uj5u.com 2023-04-28 12:15:04 more
  • day07-優惠券秒殺03

    功能03-優惠券秒殺03 4.功能03-優惠券秒殺 4.6Redisson的分布式鎖 Redis分布式鎖—Redisson+RLock可重入鎖實作篇 4.6.1基于setnx實作的分布式鎖問題 我們在4.5自己實作的分布式鎖，主要使用的是redis的setnx命令，它仍存在如下問題： 4.6.2Re ......

    uj5u.com 2023-04-28 12:11:01 more
  • mysql基礎

    SQL陳述句 SQL陳述句分類 SQL分類： 資料定義語言：簡稱DDL(Data Definition Language)，用來定義資料庫物件：資料庫，表，列等。關鍵字：create，alter，drop等 資料操作語言：簡稱DML(Data Manipulation Language)，用來對資料庫中 ......

    uj5u.com 2023-04-28 12:10:40 more
  • 輕松存盤千億級資料，知憾訓于Doris的DMP系統架構實踐

    1）提升查詢效率



    自動探測 SQL 復雜查詢條件預先合并成一個派生特征的 bitmap，預測和圈人時對復雜條件 SQL 重寫為派生特征。



    2）提升匯入速度



    Spark 直接寫 Doris Tablet 檔案，并掛載到 FE。



    針對大匯入場景與 Doris 團隊共建，提升寫入效... ......

    uj5u.com 2023-04-28 12:10:10 more
  • CloudCanal x OceanBase 資料遷移同步優化

    簡述 CloudCanal 去年支持 OceanBase 資料遷移同步能力后，隨著使用用戶增多以及問題反饋，近期對該能力進行了一輪較大規模的優化。 本篇文章簡要介紹這些優化點，以及未來該能力的演進方向。 優化點 大幅提升同步性能 CloudCanal 目前使用 OceanBase LogProxy ......

    uj5u.com 2023-04-28 12:09:52 more
  • 數堆疊V6.0全新產品矩陣發布，資料底座 EasyMR 煥新升級

    4月20日，袋鼠云成功舉行了以“數實融合，韌性生長”為主題的2023春季生長大會。會上，袋鼠云自主研發的一站式大資料基礎軟體——數堆疊V6.0產品矩陣全新發布。對旗下大資料基礎平臺、大資料開發與治理、資料智能分析與洞察三大模塊的全線產品進行全新升級，并重點發布了企業級資料計算與存盤平臺——自研大資料引 ......

    uj5u.com 2023-04-28 12:09:30 more
  • CloudCanal x OceanBase 資料遷移同步優化

    簡述 CloudCanal 去年支持 OceanBase 資料遷移同步能力后，隨著使用用戶增多以及問題反饋，近期對該能力進行了一輪較大規模的優化。 本篇文章簡要介紹這些優化點，以及未來該能力的演進方向。 優化點 大幅提升同步性能 CloudCanal 目前使用 OceanBase LogProxy ......

    uj5u.com 2023-04-28 12:09:01 more
  • [20230425]CBO cost與行遷移關系.txt

    [20230425]CBO cost與行遷移關系.txt--//一般現在很少使用analyze table分析表,如果出現大量行遷移是否考慮看看是否考慮cbo cost成本.--//測驗參考鏈接:--//https://richardfoote.wordpress.com/2023/03/21/cb ......

    uj5u.com 2023-04-28 12:08:40 more
  • day07-優惠券秒殺03

    功能03-優惠券秒殺03 4.功能03-優惠券秒殺 4.6Redisson的分布式鎖 Redis分布式鎖—Redisson+RLock可重入鎖實作篇 4.6.1基于setnx實作的分布式鎖問題 我們在4.5自己實作的分布式鎖，主要使用的是redis的setnx命令，它仍存在如下問題： 4.6.2Re ......

    uj5u.com 2023-04-28 12:07:54 more

Copyright © 2010-2020 有解無憂