MySQL 主从复制 ERROR-1032

herohope 2020-03-05

14.166在ty库中删除pritab表的id=11数据
14.165在ty库中更新pritab表的id=11数据,1032故障出现
MySQL 主从复制 ERROR-1032
解决方法:
根据报错信息知道binlog文件(Relay_Master_Log_File: mysql-binlog.000004)和position号 (Exec_Master_Log_Pos: 2569),在主库上,通过mysqlbinlog命令,找到在主库上执行的哪条SQL语句导致的主从报错:
主库:
# cd /data/mysql
# mysqlbinlog --start-position=2569 -vv --base64-output=DECODE-ROWS mysql-binlog.000004 > /tmp/bin.sql

打开/tmp/bin.sql文件

[ mysql]# cat /tmp/bin.sql
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 2569
#200304 22:22:58 server id 14165  end_log_pos 2634 CRC32 0xde44ec95     GTID    last_committed=9        sequence_number=10
SET @@SESSION.GTID_NEXT= ‘ce856f95-5aa9-11ea-87f4-0050569348f5:41‘/*!*/;
# at 2634
#200304 22:22:58 server id 14165  end_log_pos 2704 CRC32 0xbfb628ee     Query   thread_id=14    exec_time=0     error_code=0
SET TIMESTAMP=1583331778/*!*/;
SET @@session.pseudo_thread_id=14/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=45/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 2704
#200304 22:22:58 server id 14165  end_log_pos 2754 CRC32 0x5885fad6     Table_map: `ty`.`pritab` mapped to number 221
# at 2754
#200304 22:22:58 server id 14165  end_log_pos 2813 CRC32 0x60623438     Update_rows: table id 221 flags: STMT_END_F
### UPDATE `ty`.`pritab`
### WHERE
###   @1=11 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘aaaaa‘ /* VARSTRING(300) meta=300 nullable=0 is_null=0 */
### SET
###   @1=11 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘cccc‘ /* VARSTRING(300) meta=300 nullable=0 is_null=0 */
# at 2813
#200304 22:22:58 server id 14165  end_log_pos 2844 CRC32 0x1b019cf1     Xid = 79
COMMIT/*!*/;

可以看到2569事务开始后,能看到GTID_NEXT= ‘ce856f95-5aa9-11ea-87f4-0050569348f5:41‘,如果想跳过该事务错误,可以通过该GTID来实现,当然在正常生产环境下,如果错误不是很多,可以根据begin后面的具体语句来补充slave中缺失的数据

### UPDATE `ty`.`pritab`
### WHERE
###   @1=11 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘aaaaa‘ /* VARSTRING(300) meta=300 nullable=0 is_null=0 */
### SET
###   @1=11 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘cccc‘ /* VARSTRING(300) meta=300 nullable=0 is_null=0 */

可以知道,缺失的数据变是ty.pritab中id=11,name=‘aaaaa‘的数据,变更后未id=11,name=‘cccc‘,回插到从库

insert into ty.pritab values (11,‘cccc‘);

再通过pt-slave-restart跳过错误即可

[ ~]# pt-slave-restart -uroot 
2020-03-04T22:40:01 p=...,u=root ty14166-relay-bin.000011        2474 1032

当然
如果想直接跳过报错的事务,方法如下
先根据上面mysqlbinlog得出的日志,获取到报错起始的GTID号
# at 2569
#200304 22:22:58 server id 14165  end_log_pos 2634 CRC32 0xde44ec95     GTID    last_committed=9        sequence_number=10
SET @@SESSION.GTID_NEXT= ‘ce856f95-5aa9-11ea-87f4-0050569348f5:41‘/*!*/;

直接在从库中操作如下:

stop slave;
SET @@SESSION.GTID_NEXT= ‘ce856f95-5aa9-11ea-87f4-0050569348f5:41‘;
begin;
commit;
SET GTID_NEXT=AUTOMATIC;
start slave;

再查看Slave_IO_Running和Slave_SQL_Running状态都为yes,跳过异常事务

相关推荐