MDEV-34891 : SST failure occurs when gtid_strict_mode is enabled #468
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 leadin to fac 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. 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.
janlindstrom
force-pushed
the
10.5-MDEV-34891
branch
from
d39cba5 to
302dd58
Compare
temeo
requested changes
Jan 7, 2025
| @@ -324,4 +324,8 @@ ERROR 42000: You have an error in your SQL syntax; check the manual that corresp | |||
| ALTER SEQUENCE IF EXISTS t MINVALUE=1; | |||
| ERROR 42000: This version of MariaDB doesn't yet support 'CACHE without INCREMENT BY 0 in Galera cluster' | |||
| DROP TABLE t; | |||
| connection node_2; | |||
There was a problem hiding this comment.
How these suppressions are related to this PR?
| else | ||
| { | ||
| WSREP_DEBUG("before_prepare failed for %s ret=%s (%d)", | ||
| wsrep_xid_print(&thd->wsrep_xid), strerror(ret), ret); |
There was a problem hiding this comment.
How come does this work? wsrep_xid_print() returns std::string, but logging macros use C-style format specifiers?
Another issue with this debug logging is that the return value of thd->wsrep_cs().before_prepare() is not system error code. If there is some need for debug logging here, better to log
wsrep::to_c_string(thd->wsrep_cs().current_error())
| wsrep::to_c_string(thd->wsrep_cs().state()), | ||
| wsrep::to_c_string(thd->wsrep_cs().mode()), | ||
| wsrep::to_c_string(thd->wsrep_cs().transaction().state()), | ||
| strerror(ret), ret); |
There was a problem hiding this comment.
The return code from thd->wsrep_cs().after_statement() is not a system error code.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 leadin to fac 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.
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.