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。工作中需要註意結合這些表的使用更好的排查問題。
