Details
Description
The following test show how to make a cluster inconsistent with a transaction that uses a savepoint with both innodb and aria storage engines involved:
connection node_1;
|
CREATE TABLE t1 (a INTEGER PRIMARY KEY) engine=innodb;
|
START TRANSACTION;
|
INSERT INTO t1 VALUES (1);
|
SELECT count(*) a from mysql.db;
|
a
|
2
|
SAVEPOINT s1;
|
ERROR 42000: The storage engine for the table doesn't support SAVEPOINT
|
INSERT INTO t1 VALUES (2);
|
COMMIT;
|
connection node_1;
|
SELECT * FROM t1;
|
a
|
1
|
2
|
connection node_2;
|
SELECT * FROM t1;
|
a
|
2
|
Aria does not support SAVEPOINT, so an error is returned and the statement is rolled back.
This statement rollback is incorrectly causes the trx cache to be truncated back to the beginning of the transaction. Ultimately causing an inconsistency, as only the second half of the transaction is replicated to the rest of the cluster.
Attachments
Activity
Field | Original Value | New Value |
---|---|---|
Link | This issue relates to MENT-1727 [ MENT-1727 ] |
Summary | Cluster is inconsistent if savepoint statement is rolled back | Cluster is inconsistent after SAVEPOINT statement is rolled back |
Description |
The following test show how to make a cluster inconsistent with a transaction that uses a savepoint with both innodb and aria storage engines involved:
{code} --connection node_1 CREATE TABLE t1 (a INTEGER PRIMARY KEY) engine=innodb; START TRANSACTION; INSERT INTO t1 VALUES (1); SELECT count(*) a from mysql.db; a 2 SAVEPOINT s1; ERROR 42000: The storage engine for the table doesn't support SAVEPOINT INSERT INTO t1 VALUES (2); COMMIT; connection node_1; SELECT * FROM t1; a 1 2 connection node_2; SELECT * FROM t1; a 2 {code} Aria does not support SAVEPOINT, so an error is returned and the statement is rolled back. This statement rollback is incorrectly causes the trx cache to be truncated back to the beginning of the transaction. Ultimately causing an inconsistency, as only the second half of the transaction is replicated to the rest of the cluster. |
The following test show how to make a cluster inconsistent with a transaction that uses a savepoint with both innodb and aria storage engines involved:
{code} connection node_1; CREATE TABLE t1 (a INTEGER PRIMARY KEY) engine=innodb; START TRANSACTION; INSERT INTO t1 VALUES (1); SELECT count(*) a from mysql.db; a 2 SAVEPOINT s1; ERROR 42000: The storage engine for the table doesn't support SAVEPOINT INSERT INTO t1 VALUES (2); COMMIT; connection node_1; SELECT * FROM t1; a 1 2 connection node_2; SELECT * FROM t1; a 2 {code} Aria does not support SAVEPOINT, so an error is returned and the statement is rolled back. This statement rollback is incorrectly causes the trx cache to be truncated back to the beginning of the transaction. Ultimately causing an inconsistency, as only the second half of the transaction is replicated to the rest of the cluster. |
Status | Open [ 1 ] | In Progress [ 3 ] |
Assignee | Daniele Sciascia [ sciascid ] | Julius Goryavsky [ sysprg ] |
Status | In Progress [ 3 ] | In Review [ 10002 ] |
Status | In Review [ 10002 ] | Stalled [ 10000 ] |
Status | Stalled [ 10000 ] | In Progress [ 3 ] |
Fix Version/s | 10.5.24 [ 29517 ] | |
Fix Version/s | 10.5 [ 23123 ] | |
Resolution | Fixed [ 1 ] | |
Status | In Progress [ 3 ] | Closed [ 6 ] |
Fix Version/s | 10.6.17 [ 29518 ] | |
Fix Version/s | 10.11.7 [ 29519 ] | |
Fix Version/s | 11.0.5 [ 29520 ] | |
Fix Version/s | 11.1.4 [ 29024 ] | |
Fix Version/s | 11.2.3 [ 29521 ] |