Mysql数据库自建,使用,问题排查最佳实践 案例二 主从复制报错类型 plaintext LastSQLErrno: 1062 (从库与主库数据冲突) LastErrno: 1062 LastError: Could not execute Writerows event on table test.t; Duplicate entry ‘4’ for key ‘PRIMARY’, Errorcode: 1062; handler error HAERRFOUNDDUPPKEY; the event’s master log mysqlbin.000014, endlogpos 1505 针对这个报错,我们首先要考虑是不是在从库中误操作导致的。结果发现,我们在从库中进行了一条针对有主键表的SQL语句的插入,导致主库再插入相同 sql 的时候,主从状态出现异常。发生主键冲突的报错。 解决方法:在确保主从数据一致性的前提下,可以在从库进行错误跳过。一般使用 perconatoolkit 中的 ptslaverestart 进行。 在从库完成如下操作: plaintext [root@zs bin] ./ptslaverestart uroot proot123 之后最好在从库中开启 readonly 参数,禁止在从库进行写入操作。 plaintext LastIOErrno: 1593(serverid冲突) LastIOError: 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 –replicatesameserverid option must be used on slave but this does not always make sense; please check the manual before using it) 这个报错出现之后,就能一目了然看到两台机器的 serverid 是一样的。 在搭建主从复制的过程中,我们要确保两台机器的 serverid 是唯一的。这里再强调一下 serverid 的命名规则(服务器 ip 地址的最后一位+本 MySQL 服务的端口号)。 解决方法: 在主从两台机器上设置不同的 serverid。 plaintext LastSQLErrno: 1032(从库少数据,主库更新的时候,从库报错) LastSQLError: Could not execute Updaterows event on table test.t; Can’t find record in ‘t’, Errorcode: 1032; handler error HAERRKEYNOTFOUND; the event’s master log mysqlbin.000014, endlogpos 1708 解决问题的办法: 根据报错信息,我们可以获取到报错日志和position号,然后就能找到主库执行的哪条sql,导致的主从报错。 在主库执行: plaintext /usr/local/mysql/bin/mysqlbinlog –nodefaults v v –outputdecoderows /data/mysql/mysqlbin.000014 grep A 10 1708 > 1.log cat 1.log