[MDEV-4255] MIXED replication: Unique key updates are not marked unsafe, replication fails Created: 2013-03-08 Updated: 2016-12-02 |
|
| Status: | Stalled |
| Project: | MariaDB Server |
| Component/s: | Replication |
| Affects Version/s: | 10.0.1, 5.5.29, 5.5, 10.0 |
| Fix Version/s: | 10.1 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Elena Stepanova | Assignee: | Sergei Golubchik |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | upstream-wontfix | ||
| Issue Links: |
|
||||
| Description |
|
The problem is reproducible on MySQL 5.5, 5.6 and filed as http://bugs.mysql.com/bug.php?id=68609 An update such as UPDATE t1 SET pk = 5, where pk is a unique key, is not marked as an unsafe statement, so with binlog-format=MIXED it is logged in the statement format. If the update attempts to modify more than one row on a non-transactional table, it will be interrupted due to the duplicate key error and written to the binary log with an error code. However, since the update does not contain an ORDER BY condition, it might happen that it ends up updating a different row on master and slave, which will cause data inconsistency, and eventually a replication failure. There are various ways to achieve this; the test case in 'How to repeat' section simulates a real-life scenario: it executes some SQL on a server, then initializes a slave from a dump and starts replication. This way we get the same data on master and slave, but written in different order. Below is a partial output:
|
| Comments |
| Comment by Elena Stepanova [ 2014-11-09 ] |
|
Raised priority not to emphasize its importance, but to get some motion on this bug. The upstream bug was closed as "won't fix", with the helpful suggestion to use InnoDB and RBR instead of MyISAM and SBR. So, there is no point waiting for the upstream fix any longer. If we also want to leave it as is, please close the report. Otherwise (if we want to fix it some day), please kick it back to minor. |
| Comment by Sergei Golubchik [ 2014-11-15 ] |
|
Ok, so the condition is, as far as I can see, "SBR, non-transactional table, update of a UNIQUE KEY columns" |
| Comment by Elena Stepanova [ 2014-11-15 ] |
|
Well, the initial bug was about MBR (rather than SBR), because with SBR all we can do is issue the warning which is currently missing; it won't protect replication though. But technically yes, it's about SBR. |
| Comment by Sergei Golubchik [ 2014-11-15 ] |
|
knielsen, could you please review this patch? I don't particularly like that it explicitly invokes thd->decide_logging_format() . But there's no way around it, first time logging format is decided in lock_tables(), basically when tables are just opened. At that point we don't know what fields will be updated yet. |
| Comment by Kristian Nielsen [ 2014-11-18 ] |
|
Review done: |
| Comment by Sergei Golubchik [ 2014-11-18 ] |
|
It introduces too many warnings for previously silent queries. We cannot do that in 5.5 or 10.0 anymore. |