主从复制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

您的支持是对博主最大的鼓励，感谢您的认真阅读。本文版权归作者所有，欢迎转载，但请保留该声明。