mirror of
https://github.com/MariaDB/server.git
synced 2025-04-04 22:35:33 +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>
10 lines
192 B
INI
10 lines
192 B
INI
!include ../my.cnf
|
|
|
|
[mysqld.1]
|
|
wsrep-on=ON
|
|
wsrep-provider=@ENV.WSREP_PROVIDER
|
|
wsrep-cluster-address=gcomm://
|
|
binlog-format=ROW
|
|
wsrep-gtid-domain-id=100
|
|
server-id=10
|
|
innodb-autoinc-lock-mode=2
|