Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.3(EOL)
-
None
Description
--source include/have_binlog_format_row.inc
|
--source include/master-slave.inc
|
|
SET binlog_row_image = MINIMAL; |
|
CREATE TABLE t1 (pk INT, i INT, PRIMARY KEY(pk)) WITH SYSTEM VERSIONING; |
INSERT INTO t1 VALUES (1,10),(2,20); |
UPDATE t1 SET i = 0; |
|
--sync_slave_with_master
|
|
# Cleanup
|
--connection master
|
DROP TABLE t1; |
--source include/rpl_end.inc |
10.3 ff1af15f6d |
2018-05-22 21:53:35 13 [ERROR] Slave SQL: Could not execute Write_rows_v1 event on table test.t1; Duplicate entry '0' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log master-bin.000001, end_log_pos 1149, Gtid 0-1-3, Internal MariaDB error code: 1062
|
2018-05-22 21:53:35 13 [Warning] Slave: Duplicate entry '0' for key 'PRIMARY' Error_code: 1062
|
2018-05-22 21:53:35 13 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'master-bin.000001' position 815
|
Apparently, the mode doesn't take into account existence of versioned fields and changes to them:
#180522 21:53:35 server id 1 end_log_pos 899 CRC32 0xf5a7edc2 Annotate_rows:
|
#Q> UPDATE t1 SET i = 0
|
#180522 21:53:35 server id 1 end_log_pos 949 CRC32 0x9fd2c0eb Table_map: `test`.`t1` mapped to number 31
|
# at 949
|
# at 1011
|
# at 1049
|
# at 1111
|
#180522 21:53:35 server id 1 end_log_pos 1011 CRC32 0x941e5d6e Update_rows: table id 31
|
#180522 21:53:35 server id 1 end_log_pos 1049 CRC32 0x34378c01 Write_rows: table id 31
|
#180522 21:53:35 server id 1 end_log_pos 1111 CRC32 0x98159fcd Update_rows: table id 31
|
#180522 21:53:35 server id 1 end_log_pos 1149 CRC32 0xe25ad47c Write_rows: table id 31 flags: STMT_END_F
|
### UPDATE `test`.`t1`
|
### WHERE
|
### @1=1
|
### @2=10
|
### @3=1527015215.826138
|
### @4=2147483647.999999
|
### SET
|
### @2=0
|
### INSERT INTO `test`.`t1`
|
### SET
|
### @2=10
|
### UPDATE `test`.`t1`
|
### WHERE
|
### @1=2
|
### @2=20
|
### @3=1527015215.826138
|
### @4=2147483647.999999
|
### SET
|
### @2=0
|
### INSERT INTO `test`.`t1`
|
### SET
|
### @2=20
|
# Number of rows: 4
|
At the first glance, it works better for user-defined invisible fields, although maybe I just haven't got the right test case for them yet.