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.