maintainer: make dispatcher operator admission atomic (#6070) - #6085
maintainer: make dispatcher operator admission atomic (#6070)#6085ti-chi-bot wants to merge 1 commit into
Conversation
Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@wk989898 This PR has conflicts, I have hold it. |
|
@ti-chi-bot: ## If you want to know how to resolve it, please read the guide in TiDB Dev Guide. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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. Comment |
This is an automated cherry-pick of #6070
What problem does this PR solve?
Issue Number: close #6069
What is changed and how it works?
This change prevents multiple operators for the same dispatcher from being admitted concurrently.
Previously, AddOperator checked whether an operator already existed under a read lock, released the lock, and registered the new operator later under a write lock. Two concurrent operations, such as an Add and a Move for the same dispatcher, could both pass the initial check. Both operators would then be started and placed in the running queue, even though one overwrote the other in the operator map. This could create the same dispatcher on different TiCDC nodes.
An empty-origin Move is still allowed. If an Add and an empty-origin Move race for the same dispatcher, atomic admission ensures that only one can win. If the Move wins, it proceeds to create the dispatcher only on its destination node.
The barrier handling path is also hardened to accept a dispatcher’s block status only when the reporting node is the dispatcher’s current owner. Statuses from stale or non-owner dispatcher instances are ignored, preventing them from advancing a DDL or sync-point barrier.
Now the stale merge rollback will no longer mistakenly cancel a later installed remove operator.
Check List
Tests
Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note
Summary by CodeRabbit
Bug Fixes