mirror of
https://github.com/MariaDB/server.git
synced 2025-04-09 16:55:34 +02:00
b167730499
Problem was that initial GTID was set on wsrep_before_prepare out-of-order. In practice GTID was set to same as previous executed transaction GTID. In recovery valid GTID was found from prepared transaction and this transaction is committed leading to fact that same GTID was executed twice. This is fixed by setting invalid GTID at wsrep_before_prepare and later in wsrep_before_commit actual correct GTID is set and this setting is done while we are in commit monitor i.e. assigment is done in order of replication. In recovery if prepared transaction is found we check its GTID, if it is invalid transaction will be rolled back and if it is valid it will be committed. Initialize gtid seqno from recovered seqno when bootstrapping a new cluster. Added two test cases for both mariabackup and rsync SST methods to show that GTIDs remain consistent on cluster and that all expected rows are in the table. Added tests for wsrep GTID recovery with binlog on and off. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
18 lines
445 B
Text
18 lines
445 B
Text
CREATE TABLE t1 (f1 INT PRIMARY KEY) ENGINE=InnoDB;
|
|
# Case 1: Server goes through graceful shutdown and is restarted
|
|
connection default;
|
|
INSERT INTO t1 VALUES (1);
|
|
Expect 100-10-2
|
|
SELECT WSREP_LAST_SEEN_GTID();
|
|
WSREP_LAST_SEEN_GTID()
|
|
100-10-2
|
|
Performing --wsrep-recover ...
|
|
Using --wsrep-start-position when starting mysqld ...
|
|
Expect 100-10-2
|
|
SELECT WSREP_LAST_SEEN_GTID();
|
|
WSREP_LAST_SEEN_GTID()
|
|
100-10-2
|
|
SELECT * FROM t1;
|
|
f1
|
|
1
|
|
DROP TABLE t1;
|