summaryrefslogtreecommitdiff
path: root/mysql-test/suite/rpl/r/rpl_mdev_17614.result
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-17614: After-merge fixMarko Mäkelä2019-08-121-0/+31
| | | | | | | | | | | | | | | | | | MDEV-17614 flags INSERT…ON DUPLICATE KEY UPDATE unsafe for statement-based replication when there are multiple unique indexes. This correctly fixes something whose attempted fix in MySQL 5.7 in mysql/mysql-server@c93b0d9a972cb6f98fd445f2b69d924350f9128a caused lock conflicts. That change was reverted in MySQL 5.7.26 in mysql/mysql-server@066b6fdd433aa6673622341f1a2f0a3a20018043 (with a substantial amount of other changes). In MDEV-17073 we already disabled the unfortunate MySQL change when statement-based replication was not being used. Now, thanks to MDEV-17614, we can actually remove the change altogether. This reverts commit 8a346f31b913daa011085afec2b2d38450c73e00 (MDEV-17073) and mysql/mysql-server@c93b0d9a972cb6f98fd445f2b69d924350f9128a while keeping the test cases.
* MDEV-17614 INSERT on dup key update is replication unsafeSachin2019-08-091-0/+98
Problem:- When mysql executes INSERT ON DUPLICATE KEY INSERT, the storage engine checks if the inserted row would generate a duplicate key error. If yes, it returns the existing row to mysql, mysql updates it and sends it back to the storage engine.When the table has more than one unique or primary key, this statement is sensitive to the order in which the storage engines checks the keys. Depending on this order, the storage engine may determine different rows to mysql, and hence mysql can update different rows.The order that the storage engine checks keys is not deterministic. For example, InnoDB checks keys in an order that depends on the order in which indexes were added to the table. The first added index is checked first. So if master and slave have added indexes in different orders, then slave may go out of sync. Solution:- Make INSERT...ON DUPLICATE KEY UPDATE unsafe while using stmt or mixed format When there is more then one unique key. Although there is two exception. 1. Auto Increment key is not counted because Innodb will get gap lock for failed Insert and concurrent insert will get a next increment value. But if user supplies auto inc value it can be unsafe. 2. Count only unique keys for which insertion is performed. So this patch also addresses the bug id #72921