fix: alway rejects write while downgrading region#5842
fix: alway rejects write while downgrading region#5842WenyXu merged 2 commits intoGreptimeTeam:mainfrom
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
killme2008
left a comment
There was a problem hiding this comment.
Question: When region downgrading fails due to a flushing timeout or other unexpected behaviors, what happens to this migration? Will it retry or abort?
I hereby agree to the terms of the GreptimeDB CLA.
Refer to a related PR or issue link (optional)
What's changed and what's your intention?
This PR makes the datanode immediately reject write operations while handling downgrade region instructions.
Previous behavior:
A region would only transition to a "downgraded leader" state after discovering its downgrade status through heartbeats, creating a potential timing gap.
New behavior:
Write operations are now immediately rejected when handling downgrade region instructions, and then flushes the memtable data.
With write operations rejected and memtable data flushed, the upgrade candidate process becomes faster since there's no data that would need to be replayed during the upgrade candidate region operation.
This PR also
CLOSE_DOWNGRADED_REGION_TIMEOUTto 10s.PR Checklist
Please convert it to a draft if some of the following conditions are not met.