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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Galera feature: retry applying of write sets at slave nodes #387
base: 11.4
Are you sure you want to change the base?
Galera feature: retry applying of write sets at slave nodes #387
Changes from all commits
e3d0315
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here is a race condition: previously a transaction was committed in node_1 and here node_2 will shutdown. But there is no check for the fate of the replicated INSERT from node_1: it may still be replicating or is currently applying or has already committed in node_2. For deterministic test behavior, the state of the INSERT transaction should be synced here or documented if it does not matter for the test result and can be safely ignored
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, as this test phase is supposed to cause sure applier failure, the node should crash, so no need to shutdown it anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed table names in row0ins.c, but
DBUG_EXECUTE_IF
macros stillmention the test database test. There are now two separate
DBUG_EXECUTE_IF
labels:innodb_insert_fail_once
- for failing INSERT once inside InnoDB, andinnodb_insert_fail_always
- for failing INSERT always inside InnoDB.Synchronization.
There are now 4 synchronization points in the MTR test, two in each of
the 2 test cases:
Test case 1: wait till the insert transaction has been replicated and committed in node_2 (line 25)
Test case 1: wait till the transaction has been replicated and committed in node_2 (line 44)
Test case 2: wait for node_2 to crash (line 54)
Test case 2: wait till node 2 is back in the cluster (line 120)
The test does not work without shutting down the server on node 2 after applier failure.