Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
10.0.25, 10.1.32
Description
Had a master, within the same binary log, start generating BINLOG events that had no effect on the slaves. By default for a new session, binlog_format=ROW and tx_isolation='READ COMMITTED'
Creating new slaves, they would see the same problem - BINLOG events that ran did not affect rows or cause an error. The same would occur in a PITR scenario, piping mysqlbinlog to `mysql` with or without --binary-mode.
The simplest statement which did not replicate, was:
mysql <<< "replace into replmon.hb (id, hb) values (1, now())"
If I created a session and, before issuing the above, changed tx_isolation to repeatable with binlog_format=statement, the command would correctly replicate.
I suspect a simple restart would have helped, but the packages were upgraded from 10.0.25 to 10.0.32 in hopes of avoiding the issue again.
It may be a second bug, beyond strange events being created, that slaves did not modify rows or error on these BINLOG commands. I tried 10.0 slaves of course, but had the same experience with 10.2.13 (non-enterprise) in replication or PITR via mysqlbinlog.
Attachments
Issue Links
- duplicates
-
MDEV-17803 Row-based event is not applied when table map id is greater 32 bit int
- Closed
- relates to
-
MDEV-17803 Row-based event is not applied when table map id is greater 32 bit int
- Closed