主從復制1062錯誤的解決方法

   周末的時候，突然收到報警的短信，是一台slave服務器sql_thread不為YES,唉，還能不能愉快的過周末啊。上服務器一看是，是主鍵沖突導致從庫中斷，也是Last_SQL_Errno: 1062錯誤，我們常用的方法是跳過錯誤，比如SET GLOBAL SQL_SLAVE_SKIP_COUNTER =1或者直接slave-skip-errors=1062，這樣確實解決了問題，恢復了復制。但是久而久之主從數據相差就很大了。對於復制正常以后，我們還需要使用數據效驗，用pt-table-checksum校驗數據的完整性，以及pt-table-sync同步數據。

以下是報錯時的截圖：

 

錯誤分析：當發生這樣的錯誤時，可以在master庫上的xxxx庫下對應的表，用desc查看一個表結構，找出主鍵對應的列名，然后把對應的記錄找出來

master的記錄是：

mysql> select * from xxxx.xxxx where id=120383;
+--------+----------+----------+------------+-------------+----------+------------+---------------------+------+------+------+------+------+------+
| id     | log_type | log_user | log_server | log_channel | log_data | log_result | log_time            | f1   | f2   | f3   | f4   | f5   | f6   |
+--------+----------+----------+------------+-------------+----------+------------+---------------------+------+------+------+------+------+------+
| 120383 |        8 |        0 |        411 |           2 |        0 |          0 | 2015-01-10 03:34:00 |      |      |      |      |      |      |
+--------+----------+----------+------------+-------------+----------+------------+---------------------+------+------+------+------+------+------+
1 row in set (0.00 sec)

mysql> 

slave庫上的記錄是：

mysql> select * from xxxx.xxxx where id=120383;
+--------+----------+----------+------------+-------------+----------+------------+---------------------+------+------+------+------+------+------+
| id     | log_type | log_user | log_server | log_channel | log_data | log_result | log_time            | f1   | f2   | f3   | f4   | f5   | f6   |
+--------+----------+----------+------------+-------------+----------+------------+---------------------+------+------+------+------+------+------+
| 120383 |        8 |        0 |        411 |           2 |        0 |          1 | 2015-01-10 03:34:00 |      |      |      |      |      |      |
+--------+----------+----------+------------+-------------+----------+------------+---------------------+------+------+------+------+------+------+
1 row in set (0.00 sec)

mysql> 

可以看到slave的記錄與主庫不一樣，當然以主庫的記錄為准啦，所以要在slave庫上把主鍵沖突的記錄刪除掉，如果一兩條，手動刪除倒沒什么問題，但比較多的時候，手動刪除的效率是灰常慢的，下面寫了個小腳本：

#!/bin/bash
#Delete duplicate records primary key conflict
#Write by xuanzhi 2015-01-12

mysql=/usr/local/mysql-5.1.66-3310/bin/mysql
sock=/data/mysql-slave-3310/mysql.sock
passwd=123456

while true
do
    SQL_THREAD=`$mysql -uroot -p$passwd -S $sock -e 'show slave status\G' | egrep 'Slave_SQL_Running' | awk '{print $2}'`
    LAST_ERROR=`$mysql -uroot -p$passwd -S $sock -e 'show slave status\G' | egrep Last_Errno | awk '{print $2}'`
    duplicate=`$mysql -uroot -p$passwd -S $sock -e 'show slave status\G' | grep Last_Error | awk '/Duplicate entry/{print $5}' | awk -F "'" '{print $2}'`
    DATABASE=`$mysql -uroot -p$passwd -S $sock -e 'show slave status\G' | grep Last_Error | awk '{print $13}' | awk -F "'" '{print $2}'`
    TABLE=`$mysql -uroot -p$passwd -S $sock -e 'show slave status\G' | grep Last_Error | awk -F ":" '{print $4}' | awk -F "(" '{print $1}' | awk '{print $NF}'`

    $mysql -uroot -p$passwd -S $sock -e 'show slave status\G' | grep HA_ERR_FOUND_DUPP_KEY
    if [ $? -eq 1 ]
    then
        if [ "$SQL_THREAD" == No ] && [ "$LAST_ERROR" == 1062 ]
        then
            FILED=`$mysql -uroot -p$passwd -S $sock -Nse "desc $DATABASE.$TABLE" | grep PRI | awk '{print $1}'`
            $mysql -uroot -p$passwd -S $sock -e "delete from $DATABASE.$TABLE where $FILED=$duplicate"
            $mysql -uroot -p$passwd -S $sock -e "start slave sql_thread"
        else
            echo "====================== ok ========================"
            $mysql -uroot -p$passwd -S $sock -e 'show slave status\G' | egrep 'Slave_.*_Running'
            echo "====================== ok ========================"
            break
        fi
    fi
done

如果slave是完全跟上master了，運行該腳本，會循環刪除，但如果從庫還沒跟上主庫，當slave讀取中繼日志，還有主鍵沖突，又會出現主從中斷的，這時可能要結合任務計划crontal來執行刪除操作了（該腳本還有可以優化和完善的地方，如果有更好的想法，請分享下）。

  

參考資料：http://www.cnblogs.com/gomysql/p/3734087.html

 

作者：陸炫志

出處：xuanzhi的博客 http://www.cnblogs.com/xuanzhi201111

您的支持是對博主最大的鼓勵，感謝您的認真閱讀。本文版權歸作者所有，歡迎轉載，但請保留該聲明。