日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問(wèn)題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案
操作解析：MySQL如何查看復(fù)制信息并排查問(wèn)題（下）

“復(fù)制”作為MySQL原生的數(shù)據(jù)同步功能，在MySQL高可用架構(gòu)中起著至關(guān)重要的作用。本文梳理了UCloud在運(yùn)維本公司MySQL高可用產(chǎn)品UDB過(guò)程中遇到的復(fù)制問(wèn)題，并總結(jié)了當(dāng)復(fù)制發(fā)生異常時(shí)，排查復(fù)制異常的方法。

員工經(jīng)過(guò)長(zhǎng)期磨合與沉淀，具備了協(xié)作精神，得以通過(guò)團(tuán)隊(duì)的力量開發(fā)出優(yōu)質(zhì)的產(chǎn)品。創(chuàng)新互聯(lián)公司堅(jiān)持“專注、創(chuàng)新、易用”的產(chǎn)品理念，因?yàn)椤皩Ｗ⑺詫I(yè)、創(chuàng)新互聯(lián)網(wǎng)站所以易用所以簡(jiǎn)單”。公司專注于為企業(yè)提供成都網(wǎng)站建設(shè)、成都做網(wǎng)站、微信公眾號(hào)開發(fā)、電商網(wǎng)站開發(fā)，小程序開發(fā)，軟件定制網(wǎng)站建設(shè)等一站式互聯(lián)網(wǎng)企業(yè)服務(wù)。

本文承接上一篇文章，通過(guò)收集到的相關(guān)復(fù)制信息和錯(cuò)誤信息，針對(duì)幾種常見的復(fù)制錯(cuò)誤進(jìn)行分析。

一、常見復(fù)制錯(cuò)誤原因及分析過(guò)程

在收集到上述復(fù)制相關(guān)信息和錯(cuò)誤信息后，需要根據(jù)實(shí)際的誤信息進(jìn)行分析，這里羅列了幾種常見的復(fù)制錯(cuò)誤，可以通過(guò)部分或者全部在前述章節(jié)收集的相關(guān)信息，分析出復(fù)制錯(cuò)誤發(fā)生原因。

1. 從庫(kù)執(zhí)行語(yǔ)句與主庫(kù)沖突

1.1 錯(cuò)誤原因

從庫(kù)執(zhí)行DML語(yǔ)句或者DDL語(yǔ)句后，主庫(kù)和從庫(kù)會(huì)出現(xiàn)數(shù)據(jù)不一致的情況，從而導(dǎo)致主庫(kù)執(zhí)行的語(yǔ)句在從庫(kù)沒(méi)有辦法正常執(zhí)行。

1.2 錯(cuò)誤信息

由于從庫(kù)執(zhí)行與主庫(kù)沖突的語(yǔ)句而導(dǎo)致復(fù)制錯(cuò)誤，常見錯(cuò)誤信息如下：

  • 創(chuàng)建庫(kù)或者表失敗
    •   
  
  
  
      
   
   
   
   
    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
      2.
  • 插入語(yǔ)句主鍵沖突
    •   
  
  
  
      
   
   
   
   
    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
      2.
  • 刪除語(yǔ)句找不到對(duì)應(yīng)的語(yǔ)句
    •   
  
  
  
      
   
   
   
   
    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
      2.

由于這是比較常見的原因，所有導(dǎo)致主從沖突的操作均會(huì)導(dǎo)致復(fù)制出錯(cuò)，這里不再一一列舉。

1.3 原因分析過(guò)程

這里以“由于數(shù)據(jù)庫(kù)存在而導(dǎo)致創(chuàng)建數(shù)據(jù)庫(kù)出錯(cuò)”為例來(lái)分析原因。

(1) 查看 error log

Error log中顯示的詳細(xì)錯(cuò)誤信息如下：

 
 
 
 
    
  
  
  
  
  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
    2.

顯示在執(zhí)行GTID 0c1b77a7-c113-11e6-9bd6-d4ae52a34783:6時(shí)失敗。錯(cuò)誤原因在于數(shù)據(jù)庫(kù)已經(jīng)存在，無(wú)法創(chuàng)建。

(2) 查看 show slave status

當(dāng)錯(cuò)誤發(fā)生后，查看show slave status顯示的信息時(shí)，會(huì)發(fā)現(xiàn)如下信息：

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

在Executed_Gtid_Set顯示的信息中，除了Master的UUID對(duì)應(yīng)GTID外，還存在另外一個(gè)GTID，我們可以查看從庫(kù)的GTID，執(zhí)行如下語(yǔ)句：

發(fā)現(xiàn)另外的GTID是由從庫(kù)執(zhí)行而產(chǎn)生。

(3) 查看從庫(kù)binlog日志

從庫(kù)binlog日志記錄的是SQL線程復(fù)現(xiàn)的主機(jī)binlog信息或者是從庫(kù)本身執(zhí)行事務(wù)的binlog日志。這些事務(wù)可以通過(guò)server_id或者GTID來(lái)區(qū)分。

這里以創(chuàng)建數(shù)據(jù)庫(kù)失敗為例，在從庫(kù)binlog中，查找3a169e6c-f1d0-11e6-bb30-d4ae52a34783:1對(duì)應(yīng)的事務(wù)，發(fā)現(xiàn)如下信息：

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

(4) 查看從庫(kù)relay log日志

從庫(kù)relay log日志記錄的是IO線程從主庫(kù)接收到的binlog日志信息，我們查看執(zhí)行失敗的GTID對(duì)應(yīng)的事務(wù)信息：

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

(5) 總結(jié)

最終可以確認(rèn)是由于從庫(kù)執(zhí)行了創(chuàng)建數(shù)據(jù)庫(kù)語(yǔ)句后，SQL線程再次執(zhí)行創(chuàng)建數(shù)據(jù)庫(kù)語(yǔ)句時(shí)發(fā)生復(fù)制失敗的情況。

2. 主庫(kù)的binlog丟失

2.1 錯(cuò)誤原因

復(fù)制過(guò)程中，由于從庫(kù)需要讀取的主庫(kù)binlog丟失，從而導(dǎo)致復(fù)制發(fā)生異常。導(dǎo)致主庫(kù)binlog丟失的主要原因如下：

  • 主庫(kù)執(zhí)行reset master命令
  • 主庫(kù)執(zhí)行purge binary/master logs命令
  • 主庫(kù)設(shè)置了expire_logs_days，自動(dòng)刪除了binlog
  • 主庫(kù)的binlog被誤刪除

2.2 錯(cuò)誤信息

如果發(fā)生找不到主機(jī)binlog的情況，從庫(kù)error log會(huì)報(bào)出如下錯(cuò)誤：

 
 
 
 
    
  
  
  
  
  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.

2.3 原因分析過(guò)程

(1) 查看 error log

Error log中顯示的詳細(xì)錯(cuò)誤信息如下：

 
 
 
 
    
  
  
  
  
  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
    2.

錯(cuò)誤信息顯示無(wú)法找到對(duì)應(yīng)的binlog文件。

(2) 查看 binlog 日志

查看主庫(kù)的binlog日志文件列表，可能會(huì)發(fā)現(xiàn)主庫(kù)的binlog變成重新開始記錄：

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

或者需要復(fù)制的binlog已經(jīng)被刪除：

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

(3) 總結(jié)

如果binlog重新開始記錄，通常是由于主庫(kù)執(zhí)行了reset master命令，導(dǎo)致所有的binlog被刪除。

如果binlog仍然在繼續(xù)記錄，只是從庫(kù)需要的binlog被刪除，通常是由于主庫(kù)手動(dòng)執(zhí)行了purge binary logs命令，或者日志的保留時(shí)間超過(guò)了expire_logs_days設(shè)置的時(shí)間。

3. 從庫(kù)沒(méi)有執(zhí)行主庫(kù)復(fù)制的語(yǔ)句

3.1 錯(cuò)誤原因

復(fù)制過(guò)程中，用于主庫(kù)執(zhí)行事務(wù)對(duì)應(yīng)的GTID已經(jīng)存在于從庫(kù)GTID_EXECUTED中，那么從庫(kù)便不會(huì)執(zhí)行這些事務(wù)，從而導(dǎo)致主庫(kù)和從庫(kù)的數(shù)據(jù)不一致。通常有如下情況：

主機(jī)執(zhí)行了reset master(從庫(kù)當(dāng)前讀取主機(jī)的第一個(gè)binlog，并不會(huì)因?yàn)閞eset master而導(dǎo)致找不到文件)重做主從，從庫(kù)沒(méi)有清除從庫(kù)的binlog。

3.2 錯(cuò)誤信息

在從庫(kù)忽略主機(jī)執(zhí)行事務(wù)的過(guò)程中，從庫(kù)復(fù)制不會(huì)報(bào)出任何錯(cuò)誤，所以這種復(fù)制的異常容易被忽略，沒(méi)有辦法及時(shí)發(fā)現(xiàn)。

由于主庫(kù)和從庫(kù)的數(shù)據(jù)庫(kù)不一致，后續(xù)的DML和DDL操作可能會(huì)發(fā)生執(zhí)行失敗的錯(cuò)誤。

3.3 原因分析過(guò)程

這里我們以插入語(yǔ)句找不到對(duì)應(yīng)的表為例。

(1) 查看 error log

Error log中記錄錯(cuò)誤信息：

 
 
 
 
    
  
  
  
  
  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.

(2) 查看show slave status

show slave status顯示的信息全部正常，無(wú)從庫(kù)執(zhí)行事務(wù)的binlog產(chǎn)生。這里不排除從庫(kù)關(guān)閉binlog執(zhí)行drop table操作的可能。

(3) 查看表

分別在主機(jī)和從庫(kù)執(zhí)行命令show create table mydb.mytbl4，發(fā)現(xiàn)從庫(kù)上并不存在mydb.mytbl4。

(4) 解析 binlog 日志

解析主機(jī)binlog日志，查看建表的事務(wù)日志：

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

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

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

這時(shí)我們發(fā)現(xiàn)對(duì)于相同的GTID，從庫(kù)和主機(jī)執(zhí)行的語(yǔ)句不相同。

(5) 總結(jié)

通過(guò)上述分析，我們推斷是從庫(kù)并沒(méi)有執(zhí)行建表語(yǔ)句，進(jìn)而導(dǎo)致主庫(kù)數(shù)據(jù)不一致。

(6) 說(shuō)明

這種情況MySQL-5.7版本會(huì)在復(fù)制時(shí)有更嚴(yán)格校驗(yàn)，如果主機(jī)發(fā)送GTID要少于從庫(kù)的GTID，那么會(huì)報(bào)告出如下的錯(cuò)誤：

 
 
 
 
    
  
  
  
  
  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
    2.

但是，即使在5.7版本，如果啟動(dòng)復(fù)制時(shí)(錯(cuò)誤后重新啟動(dòng))，主庫(kù)執(zhí)行的GTID超過(guò)了從庫(kù)，仍然會(huì)報(bào)出同樣的錯(cuò)誤。

4. 主庫(kù)執(zhí)行了不進(jìn)行復(fù)制的語(yǔ)句

4.1 錯(cuò)誤原因

主庫(kù)上執(zhí)行的操作并不會(huì)寫入binlog，因此這里不考慮主庫(kù)主動(dòng)關(guān)閉binlog的情況。

4.2 錯(cuò)誤信息

由于主庫(kù)和從庫(kù)的數(shù)據(jù)不一致，導(dǎo)致主庫(kù)執(zhí)行的操作復(fù)制到從庫(kù)后，發(fā)生從庫(kù)執(zhí)行失敗的情況。如：

創(chuàng)建FEDERATED引擎的表失敗：

 
 
 
 
    
  
  
  
  
  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. 
  
  
  
  
  2. `idaction` int(10) unsigned NOT NULL AUTO_INCREMENT,
    3.

4.3 原因分析過(guò)程

這里以使用CONNECTION創(chuàng)建FEDERATED引擎的表為例。

(1) 查看error log

Error log中記錄錯(cuò)誤信息：

 
 
 
 
    
  
  
  
  
  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.

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

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

  • 從庫(kù)中不存在名字為s的記錄。

(3) 查看CREATE SERVER文檔說(shuō)明

文檔中記錄的create server語(yǔ)句并不會(huì)記錄到binlog中，所以導(dǎo)致主庫(kù)和從庫(kù)的數(shù)據(jù)不一致，復(fù)制無(wú)法正常進(jìn)行。

(4) 總結(jié)

對(duì)于不記入binlog的操作，需要主庫(kù)和從庫(kù)同時(shí)執(zhí)行，以防發(fā)生主庫(kù)和從庫(kù)不一致的情況。

5. 從庫(kù)重復(fù)執(zhí)行relay log的語(yǔ)句(非GTID，非多線程復(fù)制)

5.1 錯(cuò)誤原因

如果物理機(jī)發(fā)生宕機(jī)或者從庫(kù)發(fā)生意外中斷，那么可能發(fā)生SQL線程已經(jīng)執(zhí)行過(guò)了某一個(gè)relay log中的事務(wù)，但是這個(gè)事務(wù)對(duì)應(yīng)文件和位置信息并沒(méi)有及時(shí)更新到relay_log.info中的情況。在從庫(kù)發(fā)生重啟之后，會(huì)將執(zhí)行過(guò)的事務(wù)再次重新執(zhí)行。

5.2 錯(cuò)誤信息

重復(fù)執(zhí)行的事務(wù)包括任何記錄到relay log中的事務(wù)，可能出現(xiàn)的錯(cuò)誤信息包括：

  • 創(chuàng)建庫(kù)或者表失敗
    •   
  
  
  
      
   
   
   
   
    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
      2.
  • 插入語(yǔ)句主鍵沖突
    •   
  
  
  
      
   
   
   
   
    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
      2.
  • 刪除語(yǔ)句找不到對(duì)應(yīng)的語(yǔ)句
    •   
  
  
  
      
   
   
   
   
    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
      2.

由于各種類型的事務(wù)均可能執(zhí)行，這里不再一一列舉。

5.3 原因分析過(guò)程

這里以插入語(yǔ)句主鍵沖突為例

(1) 查看error log

Error log中記錄以下報(bào)錯(cuò)信息：

 
 
 
 
    
  
  
  
  
  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. 
  
  
  
  
  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. 
  
  
  
  
  3. 2017-04-19T03:02:15.459526Z 4 [Warning] Slave: Duplicate entry '101' for key 'PRIMARY' Error_code: 1062
    4.

可以看到是SQL線程在啟動(dòng)后執(zhí)行第一個(gè)事務(wù)就發(fā)生主鍵沖突的錯(cuò)誤。

(2) 查看show slave status

show slave status顯示的信息全部正常，無(wú)從庫(kù)執(zhí)行事務(wù)的binlog產(chǎn)生。

(3) mydb.k2

表中已經(jīng)存在了這條記錄。

(4) mydb.k2

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

 
 
 
 
    
  
  
  
  
  1. #170419 11:00:22 server id 30001  end_log_pos 403 CRC32 0x0ef99927      Xid = 7395
    2. 
  
  
  
  
  2. COMMIT/*!*/;
    3. 
  
  
  
  
  3. # at 616                  relay log的文件位置
    4. 
  
  
  
  
  4. #170419 11:00:59 server id 30001  end_log_pos 468 CRC32 0xbd3fd6d7      Anonymous_GTID  last_committed=1        sequence_number=2                      對(duì)應(yīng)主機(jī)的事務(wù)執(zhí)行的時(shí)間
    5. 
  
  
  
  
  5. SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
    6. 
  
  
  
  
  6. # at 681
    7. 
  
  
  
  
  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. 
  
  
  
  
  8. SET TIMESTAMP=1492570859/*!*/;
    9. 
  
  
  
  
  9. BEGIN
    10. 
  
  
  
  
  10. /*!*/;
    11. 
  
  
  
  
  11. # at 749
    12. 
  
  
  
  
  12. #170419 11:00:59 server id 30001  end_log_pos 581 CRC32 0x9fd66b9e      Table_map: `mydb`.`k2` mapped to number 114
    13. 
  
  
  
  
  13. # at 794
    14. 
  
  
  
  
  14. #170419 11:00:59 server id 30001  end_log_pos 621 CRC32 0x4151da88      Write_rows: table id 114 flags: STMT_END_F
    15. 
  
  
  
  
  15. 
  
  
  
  
  16. BINLOG '
    17. 
  
  
  
  
  17. 69L2WBMxdQAALQAAAEUCAAAAAHIAAAAAAAEABG15ZGIAAmsyAAEDAACea9af
    18. 
  
  
  
  
  18. 69L2WB4xdQAAKAAAAG0CAAAAAHIAAAAAAAEAAgAB//5lAAAAiNpRQQ==
    19. 
  
  
  
  
  19. '/*!*/;
    20. 
  
  
  
  
  20. ### INSERT INTO `mydb`.`k2`
    21. 
  
  
  
  
  21. ### SET
    22. 
  
  
  
  
  22. ###   @1=101
    23. 
  
  
  
  
  23. # at 834
    24. 
  
  
  
  
  24. #170419 11:00:59 server id 30001  end_log_pos 652 CRC32 0xf876844e      Xid = 7396
    25. 
  
  
  
  
  25. COMMIT/*!*/;
    26.

查看從庫(kù)的binlog：

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

(5) 總結(jié)

通過(guò)分析上述binlog內(nèi)容，relay log中并沒(méi)有記錄相同的insert語(yǔ)句，但從庫(kù)的binlog顯示已經(jīng)執(zhí)行過(guò)該語(yǔ)句，當(dāng)從庫(kù)重啟后，試圖再次執(zhí)行相同的insert語(yǔ)句，從而導(dǎo)致插入語(yǔ)句的主鍵沖突。

(6) 說(shuō)明

如果復(fù)制使用GTID，那么GTID的特性會(huì)使從庫(kù)不執(zhí)行相同的語(yǔ)句。

如果在5.7版本使用多線程復(fù)制，那么mts_recovery會(huì)修復(fù)這個(gè)問(wèn)題。

只有在非多線程復(fù)制、非GTID復(fù)制的情況下才可能出現(xiàn)這個(gè)錯(cuò)誤。

二、總結(jié)

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

當(dāng)然，復(fù)制的錯(cuò)誤是多種多樣的，并不是所有的錯(cuò)誤都可以排查到具體原因。很多復(fù)制錯(cuò)誤是較難或者無(wú)法進(jìn)行排查的，比如主庫(kù)或者從庫(kù)的binlog日志文件已經(jīng)丟失、關(guān)閉binlog后執(zhí)行某些操作導(dǎo)致復(fù)制不一致，又或者某些內(nèi)核BUG導(dǎo)致MySQL的復(fù)制邏輯本身發(fā)生了異常等。

【本文是專欄機(jī)構(gòu)作者“大U的技術(shù)課堂”的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)通過(guò)微信公眾號(hào)(ucloud2012)聯(lián)系作者】

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


新聞名稱：操作解析：MySQL如何查看復(fù)制信息并排查問(wèn)題（下）
轉(zhuǎn)載來(lái)源：http://www.5511xx.com/article/dpscjoo.html