Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.5.25, 10.6.18, 10.11.8, 11.4.2
-
Debian 11 Bullseye on amd64, with the MariaDB-provided Maria/Galera packages.
Description
In a 10.11.8 Galera cluster (Galera 26.4.18), the following causes the cluster to become inconsistent and a node kicked out:
CREATE TABLE `t1` (
|
`id` int(10) unsigned NOT NULL,
|
`other_id` int(10) unsigned NOT NULL,
|
PRIMARY KEY (`id`,`other_id`)
|
) ENGINE=InnoDB
|
PARTITION BY LIST (`id` MOD 2)
|
(PARTITION `p0` VALUES IN (0) ENGINE = InnoDB,
|
PARTITION `p1` VALUES IN (1) ENGINE = InnoDB);
|
|
INSERT INTO t1 VALUES (1, 0);
|
|
CREATE TABLE t2 LIKE t1;
|
|
START TRANSACTION;
|
|
INSERT INTO t2(SELECT * FROM t1 WHERE id = 1);
|
DELETE FROM t1 WHERE id = 1;
|
|
SELECT SLEEP(1);
|
|
COMMIT;
|
The partitioning can be based on either id or other_id, it doesn't seem to matter. It also shouldn't matter what particular values are used in the INSERT.
Without the SLEEP call, the other node hangs forever executing the commit. When I discovered this problem in the real world, the symptom was the inconsistency and not the hang, so I've put the SLEEP in the example. Of course either failure is really bad.
This problem does not occur on 10.11.7 (Galera 26.4.16).
Attachments
Issue Links
- is caused by
-
MDEV-22063 Assertion `0' failed in wsrep::transaction::before_rollback
- Closed
- is duplicated by
-
MDEV-34267 Since version 10.11.8 keep getting Inconsistency HA_ERR_FOUND_DUPP_KEY
- Open
- relates to
-
MDEV-34975 Sometimes IST/event queue starts with lower seqno than previously SST was finished
- Needs Feedback