MySQL Replication常見錯誤整理

 這篇文章旨在記錄MySQL Replication的常見錯誤，包括自己工作中遇到的與網友在工作中遇到的，方面自己及別人以後進行查詢。每個案例都是通過Last_IO_Errno/Last_IO_Error或者Last_SQL_Errno/Last_SQL_Error給出錯誤關鍵資訊，備忘~~。


        Last_SQL_Errno: 1677
        Last_SQL_Error: Column 1 of table 'test.t' cannot be converted from type 'int' to type 'bigint(20)'
        解決方法：這個案例是從網上找到的，自己動手實驗了一把。從錯誤資訊來看表面上是由於在slave上無法執行一條轉換欄位型別的SQL語句。實際上並不是有這種語句直接引起的，而是間接引起的（之前某些操作導致主從表欄位型別不一致，接下來對這個表進行DML時就會報錯）。它的意思是在對這個表t進行DML操作時，發現主從上表結果不一致，比如這裡是說在主上t的欄位1是int型別，但是從上t的欄位1是bigint型別，所以報錯。那麼為什麼要報錯呢？這是從安全形度考慮，因為如果欄位型別不一致可能會導致資料截斷之類的問題。那麼解決方法呢？通過引數slave_type_conversions進行控制，它有三種取值：
ALL_LOSSY：僅支援有損轉換，什麼叫有損？比如一個值本來是bigint儲存為9999999999999，現在轉換為int型別勢必會要截斷從而導致資料不一致。
ALL_NON_LOSSY：僅支援無損轉換，只能在無損的情況下才能進行轉換
ALL_LOSSY,ALL_NON_LOSSY：有損/無算轉換都支援
空，即不設定這個引數：必須主從的欄位型別一模一樣。
注意： 前面說的這幾中情況都只在binlog_format=ROW的情況下才有效。


        Last_SQL_Errno: 1194
        Last_SQL_Error: Error 'Table 'traincenter' is marked as crashed and should be repaired' on query. Default database: 'basketballman'. Query: 'update traincenter set points='4',pointstime='1361912066'  where uid = '1847482697' limit 1'
        解決方法：myisam表traincenter損壞，直接repair table即可。至於為什麼myisam型別表比innodb更容易損壞，我覺得有兩個原因：1，innodb有double write機制，損壞或者half write的頁可以用它恢復，第二innodb是事務引擎，都有操作都是事務的，而myisam是非事務的，存在寫一半但是操作終止情況。


        Last_IO_Errno: 1236
        Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
        解決方法：主庫上的binlog檔案已經不存在但是在index file中確有相應記錄存在。我這裡發生這個錯誤的原因在於由於複製中斷時間很長，報警出來一直沒人處理，這個中斷時間超過master上binlog超期時間，等恢復複製時需要的binlog已經由於其超期而被刪掉，沒辦法只好重建這個例項了。以大家都要引以為戒。


        Last_IO_Errno: 1593
        Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).
        解決方法：主從配置的server-id一樣，而在主從複製環境中server-id一樣的binlog events都會被過濾掉。具體server-id的含義可以瞭解一下複製原理。這個一般是因為拷貝配置檔案時忘記修改server-id導致，遇到這類問題也比較容易，平時操作謹慎一點即可。


        Last_Errno: 1053
        Last_Error: Query partially completed on the master (error on master: 1053) and was aborted. There is a chance that your master is inconsistent at this point. If you are sure that your master is ok, run this query manually on the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; . Query: 'insert into ...
        解決方法：查詢在master上部分完成，然後終止了。這馬上又能想到是myisam表，結果也正是這樣。由於myisam不支援事務所以可能存在一個查詢完成一部分然後失敗的情況。解決方法一般也就是提示資訊給出的跳過一個binlog event。不過確認跳過之前最好還是查詢一下master上是否真的存在相應的記錄，因為錯誤資訊同時還會給出它認為在master上執行一部分然後終止的查詢語句。


        Last_SQL_Errno: 1666
        Last_SQL_Error: Error executing row event: 'Cannot execute statement: impossible to write to binary log since statement is in row format and BINLOG_FORMAT = STATEMENT.' 
        解決方法：這個案例的背景是做一個ABC結構的複製，B、C中設定的binlog_format=statement，A中的是MIXED，所以當B嘗試重做A過來的relay log，然後記錄binlog（傳給C）時發現relay log的binlog_format與自己設定的binlog_format不一致。我當時就是直接先更改BC的binlog_format=MIXED解決。


        Last_Errno: 1032
        Last_Error: Could not execute Update_rows event on table db.table; Can't find record in 'table', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000064, end_log_pos 158847
        解決方法：這個是在binlog_format=row複製下發生的。原因是因為row格式複製是最嚴格的，所以在mysql看來如果在從庫上找不到要更新的這條記錄，那麼就代表主從資料不一致，因此報錯。另外順便說一句，對於row格式binlog，如果某個更新操作實際上並沒有更新行，這個操作是不會記binlog的，因為row格式的binlog宗旨就是隻記錄發生了改變的行。所以這個解決辦法根據你自己實際應用來定，最好的方法還是重做slave吧，這樣更放心。


        Last_Errno: 28
        Last_Error: Error in Append_block event: write to '/tmp/SQL_LOAD-32343798-72213798-1.data' failed
        解決方法： 首先說錯誤原因：主庫執行load data infile，同步到從庫後load data infile存放的檔案預設是放在/tmp(由引數slave_load_tmpdir控制)，而/tmp空間不夠因此報錯。因此只要將從庫上slave_load_tmpdir設定到一個磁碟空間足夠大的分割槽就行。

zz：http://blog.csdn.net/zbszhangbosen/article/details/8557538

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26855487/viewspace-775827/，如需轉載，請註明出處，否則將追究法律責任。