成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

操作解析：MySQL如何查看復制信息并排查問題（下）

作者：大U的技術課堂
開發 開發工具
“復制”作為MySQL原生的數據同步功能，在MySQL高可用架構中起著至關重要的作用。本文通過收集到的相關復制信息和錯誤信息，針對幾種常見的復制錯誤進行分析。

“復制”作為MySQL原生的數據同步功能，在MySQL高可用架構中起著至關重要的作用。本文梳理了UCloud在運維本公司MySQL高可用產品UDB過程中遇到的復制問題，并總結了當復制發生異常時，排查復制異常的方法。

本文承接上一篇文章，通過收集到的相關復制信息和錯誤信息，針對幾種常見的復制錯誤進行分析。

MySQL

一、常見復制錯誤原因及分析過程

在收集到上述復制相關信息和錯誤信息后，需要根據實際的誤信息進行分析，這里羅列了幾種常見的復制錯誤，可以通過部分或者全部在前述章節收集的相關信息，分析出復制錯誤發生原因。

1. 從庫執行語句與主庫沖突

1.1 錯誤原因

從庫執行DML語句或者DDL語句后，主庫和從庫會出現數據不一致的情況，從而導致主庫執行的語句在從庫沒有辦法正常執行。

1.2 錯誤信息

由于從庫執行與主庫沖突的語句而導致復制錯誤，常見錯誤信息如下：

  • 創建庫或者表失敗
    1. 017-04-18T07:52:40.440723Z 6 [ERROR] Slave SQL for channel '': Worker 0 failed executing transaction '0c1b77a7-c113-11e6-9bd6-d4ae52a34783:2' at master log binlog001.000001, end_log_pos 493; Error 'Can't create database 'mydb4'; database exists' on query. Default database: 'mydb4'. Query: 'create database mydb4', Error_code: 1007 
  • 插入語句主鍵沖突
    1. 2017-04-18T07:57:35.975310Z 10 [ERROR] Slave SQL for channel '': Worker 0 failed executing transaction '0c1b77a7-c113-11e6-9bd6-d4ae52a34783:1' at master log binlog001.000001, end_log_pos 378; Could not execute Write_rows event on table mydb.test; Duplicate entry '10' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log FIRST, end_log_pos 378, Error_code: 1062 
  • 刪除語句找不到對應的語句
    1. [ERROR] Slave SQL for channel '': Worker 0 failed executing transaction '0c1b77a7-c113-11e6-9bd6-d4ae52a34783:1' at master log binlog001.000001, end_log_pos 506; Could not execute Delete_rows event on table mydb.I1; Can't find record in 'I1', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log FIRST, end_log_pos 506, Error_code: 1032 

由于這是比較常見的原因，所有導致主從沖突的操作均會導致復制出錯，這里不再一一列舉。

1.3 原因分析過程

這里以“由于數據庫存在而導致創建數據庫出錯”為例來分析原因。

(1) 查看 error log

Error log中顯示的詳細錯誤信息如下：

  1. 2017-04-18T08:22:26.885713Z 16 [ERROR] Slave SQL for channel '': Worker 0 failed executing transaction '0c1b77a7-c113-11e6-9bd6-d4ae52a34783:6' at master log binlog001.000001, end_log_pos 1710; Error 'Can't create database 'mydb10'; database exists' on query. Default database: 'mydb10'. Query: 'create database mydb10', Error_code: 1007 

顯示在執行GTID 0c1b77a7-c113-11e6-9bd6-d4ae52a34783:6時失敗。錯誤原因在于數據庫已經存在，無法創建。

(2) 查看 show slave status

當錯誤發生后，查看show slave status顯示的信息時，會發現如下信息：

  1. Master_UUID: 0c1b77a7-c113-11e6-9bd6-d4ae52a34783 
  2. Retrieved_Gtid_Set: 0c1b77a7-c113-11e6-9bd6-d4ae52a34783:1-5 
  3. Executed_Gtid_Set: 0c1b77a7-c113-11e6-9bd6-d4ae52a34783:1-5, 
  4. 3a169e6c-f1d0-11e6-bb30-d4ae52a34783:1 

在Executed_Gtid_Set顯示的信息中，除了Master的UUID對應GTID外，還存在另外一個GTID，我們可以查看從庫的GTID，執行如下語句：

發現另外的GTID是由從庫執行而產生。

(3) 查看從庫binlog日志

從庫binlog日志記錄的是SQL線程復現的主機binlog信息或者是從庫本身執行事務的binlog日志。這些事務可以通過server_id或者GTID來區分。

這里以創建數據庫失敗為例，在從庫binlog中，查找3a169e6c-f1d0-11e6-bb30-d4ae52a34783:1對應的事務，發現如下信息：

  1. #170418 16:22:15 server id 30002  end_log_pos 1791 CRC32 0xfa89e69a     GTID    last_committed=6        sequence_number=7 
  2. SET @@SESSION.GTID_NEXT= '3a169e6c-f1d0-11e6-bb30-d4ae52a34783:1'/*!*/; 
  3. # at 1791 
  4. …… 
  5. create database mydb10 

(4) 查看從庫relay log日志

從庫relay log日志記錄的是IO線程從主庫接收到的binlog日志信息，我們查看執行失敗的GTID對應的事務信息：

  1. #170418 16:22:26 server id 30001  end_log_pos 1610 CRC32 0x27c8228f     GTID    last_committed=5        sequence_number=6 
  2. SET @@SESSION.GTID_NEXT= '0c1b77a7-c113-11e6-9bd6-d4ae52a34783:6'/*!*/; 
  3. # at 519 
  4. …… 
  5. create database mydb10 
  6. /*!*/; 

(5) 總結

最終可以確認是由于從庫執行了創建數據庫語句后，SQL線程再次執行創建數據庫語句時發生復制失敗的情況。

2. 主庫的binlog丟失

2.1 錯誤原因

復制過程中，由于從庫需要讀取的主庫binlog丟失，從而導致復制發生異常。導致主庫binlog丟失的主要原因如下：

  • 主庫執行reset master命令
  • 主庫執行purge binary/master logs命令
  • 主庫設置了expire_logs_days，自動刪除了binlog
  • 主庫的binlog被誤刪除

2.2 錯誤信息

如果發生找不到主機binlog的情況，從庫error log會報出如下錯誤：

  1. 2017-04-18T09:01:42.894612Z 17 [ERROR] Slave I/O for channel '': Got fatal error 1236 from master when reading data from binary log: 'could not find ne 

2.3 原因分析過程

(1) 查看 error log

Error log中顯示的詳細錯誤信息如下：

  1. 2017-04-18T09:01:42.894612Z 17 [ERROR] Slave I/O for channel '': Got fatal error 1236 from master when reading data from binary log: 'could not find next log; the first event '' at 4, the last event read from './binlog001.000002' at 154, the last byte read from './binlog001.000002' at 154.', Error_code: 1236 

錯誤信息顯示無法找到對應的binlog文件。

(2) 查看 binlog 日志

查看主庫的binlog日志文件列表，可能會發現主庫的binlog變成重新開始記錄：

  1. -rw-r-----  1 songlei.wang songlei.wang      449 Apr 18 17:01 binlog001.000001 
  2. -rw-r-----  1 songlei.wang songlei.wang       19 Apr 18 17:01 binlog_index001.index 

或者需要復制的binlog已經被刪除：

  1. -rw-r-----  1 songlei.wang songlei.wang      241 Apr 18 17:12 binlog001.000006 
  2. -rw-r-----  1 songlei.wang songlei.wang     1716 Apr 18 17:12 binlog001.000007 
  3. -rw-r-----  1 songlei.wang songlei.wang      194 Apr 18 17:12 binlog001.000008 
  4. -rw-r-----  1 songlei.wang songlei.wang       57 Apr 18 17:12 binlog_index001.index 

(3) 總結

如果binlog重新開始記錄，通常是由于主庫執行了reset master命令，導致所有的binlog被刪除。

如果binlog仍然在繼續記錄，只是從庫需要的binlog被刪除，通常是由于主庫手動執行了purge binary logs命令，或者日志的保留時間超過了expire_logs_days設置的時間。

3. 從庫沒有執行主庫復制的語句

3.1 錯誤原因

復制過程中，用于主庫執行事務對應的GTID已經存在于從庫GTID_EXECUTED中，那么從庫便不會執行這些事務，從而導致主庫和從庫的數據不一致。通常有如下情況：

主機執行了reset master(從庫當前讀取主機的第一個binlog，并不會因為reset master而導致找不到文件)重做主從，從庫沒有清除從庫的binlog。

3.2 錯誤信息

在從庫忽略主機執行事務的過程中，從庫復制不會報出任何錯誤，所以這種復制的異常容易被忽略，沒有辦法及時發現。

由于主庫和從庫的數據庫不一致，后續的DML和DDL操作可能會發生執行失敗的錯誤。

3.3 原因分析過程

這里我們以插入語句找不到對應的表為例。

(1) 查看 error log

Error log中記錄錯誤信息：

  1. 2017-04-18 20:39:01 682 [ERROR] Slave SQL: Error 'Table 'mydb.mytbl2' doesn't exist' on query. Default database: 'mydb'. Query: 'insert into mydb.mytbl4 values (1)', Error_code: 1146 

(2) 查看show slave status

show slave status顯示的信息全部正常，無從庫執行事務的binlog產生。這里不排除從庫關閉binlog執行drop table操作的可能。

(3) 查看表

分別在主機和從庫執行命令show create table mydb.mytbl4，發現從庫上并不存在mydb.mytbl4。

(4) 解析 binlog 日志

解析主機binlog日志，查看建表的事務日志：

  1. #170418 20:50:47 server id 30061  end_log_pos 199 CRC32 0xaaa00818      GTID [commit=yes] 
  2. SET @@SESSION.GTID_NEXT= '1ac5f388-0dea-11e7-b2ec-d4ae52a34783:1'/*!*/; 
  3. # at 199 
  4. #170418 20:50:47 server id 30061  end_log_pos 319 CRC32 0x06f5789f      Query   thread_id=3     exec_time=0     error_code=0 
  5. …… 
  6. create table if not exists mydb.mytbl4 (A int) 

解析從庫的binlog日志，查找是否存在建表的事務日志:

  1. #170418 20:49:49 server id 30061  end_log_pos 199 CRC32 0x3051fade      GTID [commit=yes] 
  2. SET @@SESSION.GTID_NEXT= '1ac5f388-0dea-11e7-b2ec-d4ae52a34783:1'/*!*/; 
  3. # at 199 
  4. #170418 20:49:49 server id 30061  end_log_pos 278 CRC32 0x7156a1c9      Query   thread_id=3     exec_time=40    error_code=0 
  5. …… 
  6. BEGIN 
  7. /*!*/; 
  8. # at 278 
  9. #170418 20:49:49 server id 30061  end_log_pos 385 CRC32 0x25560e04      Query   thread_id=3     exec_time=40    error_code=0 
  10. use `mydb`/*!*/; 
  11. SET TIMESTAMP=1492519789/*!*/; 
  12. insert into mydb.mytbl values (1) 
  13. /*!*/; 
  14. …… 

這時我們發現對于相同的GTID，從庫和主機執行的語句不相同。

(5) 總結

通過上述分析，我們推斷是從庫并沒有執行建表語句，進而導致主庫數據不一致。

(6) 說明

這種情況MySQL-5.7版本會在復制時有更嚴格校驗，如果主機發送GTID要少于從庫的GTID，那么會報告出如下的錯誤：

  1. Got fatal error 1236 from master when reading data from binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID. This may indicate that the end of the binary log was truncated or that the last binary log file was lost, e.g., after a power or disk failure when sync_binlog != 1. The master may or may not have rolled back transactions that were already replica', Error_code: 1236 

但是，即使在5.7版本，如果啟動復制時(錯誤后重新啟動)，主庫執行的GTID超過了從庫，仍然會報出同樣的錯誤。

4. 主庫執行了不進行復制的語句

4.1 錯誤原因

主庫上執行的操作并不會寫入binlog，因此這里不考慮主庫主動關閉binlog的情況。

4.2 錯誤信息

由于主庫和從庫的數據不一致，導致主庫執行的操作復制到從庫后，發生從庫執行失敗的情況。如：

創建FEDERATED引擎的表失?。?/p> 

  1. 2017-01-24T08:04:31.682038Z 3 [ERROR] Slave SQL for channel '': Worker 0 failed executing transaction '887ca716-e202-11e6-8a82-52540086ae59:7' at master log mysql-bin.000004, end_log_pos 906; Error 'server name: 's' doesn't exist!' on query. Default database: 'mydb'. Query: 'CREATE TABLE `mytbl` ( 
  2. `idaction` int(10) unsigned NOT NULL AUTO_INCREMENT, 

4.3 原因分析過程

這里以使用CONNECTION創建FEDERATED引擎的表為例。

(1) 查看error log

Error log中記錄錯誤信息：

  1. 2017-01-24T08:04:31.682038Z 3 [ERROR] Slave SQL for channel '': Worker 0 failed executing transaction '887ca716-e202-11e6-8a82-52540086ae59:7' at master log mysql-bin.000004, end_log_pos 906; Error 'server name: 's' doesn't exist!' on query. 

(2) 查看主庫和從庫的server表

  • 主庫中server表中存在名字為s的記錄。

  • 從庫中不存在名字為s的記錄。

(3) 查看CREATE SERVER文檔說明

文檔中記錄的create server語句并不會記錄到binlog中，所以導致主庫和從庫的數據不一致，復制無法正常進行。

(4) 總結

對于不記入binlog的操作，需要主庫和從庫同時執行，以防發生主庫和從庫不一致的情況。

5. 從庫重復執行relay log的語句(非GTID，非多線程復制)

5.1 錯誤原因

如果物理機發生宕機或者從庫發生意外中斷，那么可能發生SQL線程已經執行過了某一個relay log中的事務，但是這個事務對應文件和位置信息并沒有及時更新到relay_log.info中的情況。在從庫發生重啟之后，會將執行過的事務再次重新執行。

5.2 錯誤信息

重復執行的事務包括任何記錄到relay log中的事務，可能出現的錯誤信息包括：

  • 創建庫或者表失敗
    1. 2017-04-18T07:52:40.440723Z 6 [ERROR] Slave SQL for channel '': Worker 0 failed executing transaction '0c1b77a7-c113-11e6-9bd6-d4ae52a34783:2' at master log binlog001.000001, end_log_pos 493; Error 'Can't create database 'mydb4'; database exists' on query. Default database: 'mydb4'. Query: 'create database mydb4', Error_code: 1007 
  • 插入語句主鍵沖突
    1. 2017-04-18T07:57:35.975310Z 10 [ERROR] Slave SQL for channel '': Worker 0 failed executing transaction '0c1b77a7-c113-11e6-9bd6-d4ae52a34783:1' at master log binlog001.000001, end_log_pos 378; Could not execute Write_rows event on table mydb.test; Duplicate entry '10' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log FIRST, end_log_pos 378, Error_code: 1062 
  • 刪除語句找不到對應的語句
    1. [ERROR] Slave SQL for channel '': Worker 0 failed executing transaction '0c1b77a7-c113-11e6-9bd6-d4ae52a34783:1' at master log binlog001.000001, end_log_pos 506; Could not execute Delete_rows event on table mydb.I1; Can't find record in 'I1', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log FIRST, end_log_pos 506, Error_code: 1032 

由于各種類型的事務均可能執行，這里不再一一列舉。

5.3 原因分析過程

這里以插入語句主鍵沖突為例

(1) 查看error log

Error log中記錄以下報錯信息：

  1. 2017-04-19T03:02:15.448429Z 4 [Note] Slave SQL thread for channel '' initialized, starting replication in log 'binlog001.000001' at position 403, relay log './relaylog002.000002' position: 616 
  2. 2017-04-19T03:02:15.459468Z 4 [ERROR] Slave SQL for channel '': Could not execute Write_rows event on table mydb.k2; Duplicate entry '101' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log binlog001.000001, end_log_pos 621, Error_code: 1062 
  3. 2017-04-19T03:02:15.459526Z 4 [Warning] Slave: Duplicate entry '101' for key 'PRIMARY' Error_code: 1062 

可以看到是SQL線程在啟動后執行第一個事務就發生主鍵沖突的錯誤。

(2) 查看show slave status

show slave status顯示的信息全部正常，無從庫執行事務的binlog產生。

(3) mydb.k2

表中已經存在了這條記錄。

(4) mydb.k2

查看從庫的relay log，從復制的起始位置./relaylog002.000002：616查看：

  1. #170419 11:00:22 server id 30001  end_log_pos 403 CRC32 0x0ef99927      Xid = 7395 
  2. COMMIT/*!*/; 
  3. # at 616                  relay log的文件位置 
  4. #170419 11:00:59 server id 30001  end_log_pos 468 CRC32 0xbd3fd6d7      Anonymous_GTID  last_committed=1        sequence_number=2                      對應主機的事務執行的時間 
  5. SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; 
  6. # at 681 
  7. #170419 11:00:59 server id 30001  end_log_pos 536 CRC32 0x484841bd      Query   thread_id=553   exec_time=0     error_code=0 
  8. SET TIMESTAMP=1492570859/*!*/; 
  9. BEGIN 
  10. /*!*/; 
  11. # at 749 
  12. #170419 11:00:59 server id 30001  end_log_pos 581 CRC32 0x9fd66b9e      Table_map: `mydb`.`k2` mapped to number 114 
  13. # at 794 
  14. #170419 11:00:59 server id 30001  end_log_pos 621 CRC32 0x4151da88      Write_rows: table id 114 flags: STMT_END_F 
  15.  
  16. BINLOG ' 
  17. 69L2WBMxdQAALQAAAEUCAAAAAHIAAAAAAAEABG15ZGIAAmsyAAEDAACea9af 
  18. 69L2WB4xdQAAKAAAAG0CAAAAAHIAAAAAAAEAAgAB//5lAAAAiNpRQQ== 
  19. '/*!*/; 
  20. ### INSERT INTO `mydb`.`k2` 
  21. ### SET 
  22. ###   @1=101 
  23. # at 834 
  24. #170419 11:00:59 server id 30001  end_log_pos 652 CRC32 0xf876844e      Xid = 7396 
  25. COMMIT/*!*/; 

查看從庫的binlog：

  1. #170419 11:00:59 server id 30001  end_log_pos 463 CRC32 0x6ede3a0d      Anonymous_GTID  last_committed=1        sequence_number=2 
  2. SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; 
  3. # at 463 
  4. #170419 11:00:59 server id 30001  end_log_pos 526 CRC32 0x5fac2d32      Query   thread_id=553   exec_time=0     error_code=0 
  5. SET TIMESTAMP=1492570859/*!*/; 
  6. BEGIN 
  7. /*!*/; 
  8. # at 526 
  9. #170419 11:00:59 server id 30001  end_log_pos 571 CRC32 0xb51f8ec9      Table_map: `mydb`.`k2` mapped to number 108 
  10. # at 571 
  11. #170419 11:00:59 server id 30001  end_log_pos 611 CRC32 0xfa578a3f      Write_rows: table id 108 flags: STMT_END_F 
  12.  
  13. BINLOG ' 
  14. 69L2WBMxdQAALQAAADsCAAAAAGwAAAAAAAEABG15ZGIAAmsyAAEDAADJjh+1 
  15. 69L2WB4xdQAAKAAAAGMCAAAAAGwAAAAAAAEAAgAB//5lAAAAP4pX+g== 
  16. '/*!*/; 
  17. ### INSERT INTO `mydb`.`k2` 
  18. ### SET 
  19. ###   @1=101 
  20. # at 611 
  21. #170419 11:00:59 server id 30001  end_log_pos 642 CRC32 0xc3a619a0      Xid = 12 
  22. COMMIT/*!*/; 

(5) 總結

通過分析上述binlog內容，relay log中并沒有記錄相同的insert語句，但從庫的binlog顯示已經執行過該語句，當從庫重啟后，試圖再次執行相同的insert語句，從而導致插入語句的主鍵沖突。

(6) 說明

如果復制使用GTID，那么GTID的特性會使從庫不執行相同的語句。

如果在5.7版本使用多線程復制，那么mts_recovery會修復這個問題。

只有在非多線程復制、非GTID復制的情況下才可能出現這個錯誤。

二、總結

如果復制發生了錯誤，通過收集上述復制相關信息和錯誤相關信息，分析這些信息中與正常復制異常的地方，便可為排查復制錯誤提供更多的信息。

當然，復制的錯誤是多種多樣的，并不是所有的錯誤都可以排查到具體原因。很多復制錯誤是較難或者無法進行排查的，比如主庫或者從庫的binlog日志文件已經丟失、關閉binlog后執行某些操作導致復制不一致，又或者某些內核BUG導致MySQL的復制邏輯本身發生了異常等。

【本文是51CTO專欄機構作者“大U的技術課堂”的原創文章，轉載請通過微信公眾號(ucloud2012)聯系作者】

 戳這里，看該作者更多好文

責任編輯：趙寧寧 來源： 51CTO專欄
MySQL復制線程
相關推薦

2017-06-09 20:10:44

MySQL復制線程

2021-12-26 00:10:39

二分法排查版本

2011-03-28 10:03:46

Btrace

2022-01-26 19:42:05

MySQL亂碼排查

2023-03-02 08:53:57

排查問題效率經驗

2019-05-24 14:15:30

Linux硬件信息命令

2022-02-08 16:17:41

MySQL主從復制數據庫

2018-12-10 10:30:40

阿里Linux命令

2009-02-16 20:16:52

Linux網卡硬件查看

2021-06-28 08:00:00

Python開發編程語言

2018-11-06 12:12:00

MySQL內存排查

2017-08-18 22:40:33

線上線程備份

2021-05-28 10:10:05

LinuxCPU機器學習

2010-05-06 15:29:53

Oracle數據復制

2010-05-14 18:26:39

MySQL 復制設置

2024-11-21 16:47:55

2017-10-18 15:07:21

MySQL執行死鎖

2010-03-08 11:21:40

Linux用戶操作記錄

2013-03-27 10:32:22

2024-10-10 15:32:51

點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 国产在线观看一区二区三区 | 黄色一级电影免费观看 | 色在线免费视频 | 韩国久久精品 | 日韩一二区 | 国产精品免费福利 | 国产有码 | 日韩在线精品强乱中文字幕 | 国产美女黄色片 | 国产一区不卡 | 国产精品久久一区 | 国产精品国产精品 | av色站 | 亚洲美乳中文字幕 | 久久久亚洲一区 | 亚洲精品久久久久久一区二区 | 99热视| 国产午夜精品久久 | 国产精品国产三级国产aⅴ原创 | 成人在线精品视频 | 精品久久久久久久久久久 | 亚洲精品不卡 | 色婷婷精品国产一区二区三区 | 成人免费精品视频 | 中文字幕在线一区 | 一区二区三区四区国产 | av黄色在线| 我我色综合 | 粉嫩国产精品一区二区在线观看 | 久久日韩粉嫩一区二区三区 | 精品欧美一区二区久久久伦 | 日韩天堂av | 亚洲欧美bt | 日一日操一操 | 91黄色免费看 | 日韩人体视频 | 午夜精品一区二区三区在线 | 中文字幕av在线一二三区 | 男女激情网站免费 | 狠狠干天天干 | 国产a视频|