fix(duplication): dup would get stuck in DS_PREPARE indefinitely once some error occurred during creating follower table
#2144
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
… some error occurred during creating follower table
empiredan
added
component/duplication
acelyc111
previously approved these changes
Nov 14, 2024
acelyc111
approved these changes
Nov 14, 2024
empiredan
changed the title
DS_PREPARE indefinitely once some error occurred during creating follower table
Samunroyu
approved these changes
Nov 15, 2024
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.
Fix #2146.
As is described in issue, once there are some errors occurred during the follower
table is being created, the follower cluster might replied with
ERR_APP_EXISTto the source cluster. Then, the source cluster would continue to send the same
request to create table on the follower cluster again. As such, the dup would get
stuck in the current status, namely
DS_PREPARE, and could not forward to thenext status.
The core idea to solve this problem is that we should make the request that create
table on follower cluster idempotent. The follower cluster should process the repeated
requests correctly. To implement this, an environment variable marking creating status
is added and sent together with the request to the follower cluster. The follower cluster
would choose to commit it to meta data on both remote storage and local memory, or
just ignore it, or reply to source cluster with some error code.