Marko Mäkelä added a comment - 2018-11-06 11:22 On a related note, an incorrect check for replication-unsafety was originally added in MySQL 5.1.20 in ha_innobase::table_flags() and in 5.1.21 moved to ha_innobase::external_lock() . A few notes: thd_binlog_format(thd) == BINLOG_FORMAT_STMT is wrong, and should be replaced with thd_rpl_stmt_based() or equivalent. Also READ UNCOMMITTED should be unsafe. It is unclear to me why INSERT…ON DUPLICATE KEY UPDATE was considered safe for statement-based replication at any isolation level. The above-mentioned check considers it safe for REPEATABLE READ (which is a misnomer for R/W transactions) and SERIALIZABLE . Consistently with the above, the MySQL 5.7 fix for MySQL Bug#50413 insert on duplicate key update sometimes writes binlog position incorrectly (Oracle internal BUG#11758237) is adding extra locking for REPEATABLE READ and SERIALIZABLE . I would recommend applying the relevant part of Revert-InnoDB-SBR-changes.patch from MDEV-17603 .

Sachin Setiya (Inactive) added a comment - 2019-06-04 08:56 Changed the fix version to 10.1 , 10.0 is no longer supported

Sachin Setiya (Inactive) added a comment - 2019-06-08 07:11 Test Case --source include/master-slave.inc --source include/have_binlog_format_mixed.inc --source include/have_innodb.inc CREATE TABLE t1 (a INT PRIMARY KEY, b INT UNIQUE KEY, c INT) ENGINE = InnoDB; INSERT INTO t1 VALUES (1, 1, 1); BEGIN; INSERT INTO t1 VALUES (2, 1, 2) ON DUPLICATE KEY UPDATE b=VALUES(b), c=VALUES(c); --connection master1 INSERT INTO t1 VALUES(2, 2, 3) ON DUPLICATE KEY UPDATE b=VALUES(b), c=VALUES(c); --connection master COMMIT; SELECT * FROM t1; --sync_slave_with_master SELECT * FROM t1;   --connection master drop table t1; --sync_slave_with_master   --source include/rpl_end.inc

Sachin Setiya (Inactive) added a comment - 2019-06-12 06:18 http://lists.askmonty.org/pipermail/commits/2019-June/013849.html

Marko Mäkelä added a comment - 2019-08-12 16:11 In MariaDB Server 10.2 and later, this fix allows (and the test case requires) us to revise the MDEV-17073 fix. Instead of selectively disabling the problematic change that we inherited from MySQL 5.7, we must remove that problematic change altogether. Thanks to this MDEV-17614 fix, replication will work correctly (or warnings will be issued to the user). In MDEV-17603 , we could allow statement based replication by extending the log format, writing more information. That is a performance optimization.