Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
11.4.5
-
None
-
Not for Release Notes
Description
I've encountered an error in replication, if the table has no transaction (aria) and the statement gets abbort due to an duplicate key error.
Assume replication uses "binlog_format=mixed"
Assume some table like this
CREATE TABLE `test` ( |
`a` int(10) unsigned NOT NULL, |
`b` int(10) unsigned NOT NULL, |
UNIQUE KEY `a_b` (`a`,`b`) |
) ENGINE=Aria DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_unicode_ci PAGE_CHECKSUM=1 |
Assume the data to be
| a | b |
|---|---|
| 1 | 1 |
| 1 | 2 |
| 2 | 4 |
| 1 | 5 |
| 1 | 6 |
| 2 | 1 |
| 2 | 2 |
| 2 | 3 |
now issue
UPDATE test SET a=1 WHERE a=2; |
It will stop with an duplicate key error for 2-1. It will/might already changed "2-4" to "1-4". But will not replicate this line to the client.
If you then issue
UPDATE IGNORE test SET a=1 WHERE a=2; |
the line "2-3" will be updated to "1-3" on both servers, but on one server you still have "2-4" on the other "1-4".
Attachments
Issue Links
- is duplicated by
-
MDEV-37807 Replication incomplete on duplicate key
-
- Open
-
- relates to
-
MDEV-4255 MIXED replication: Unique key updates are not marked unsafe, replication fails
-
- Stalled
-