owner(cdc): asynchronously close the ddl sink

[3AceShowHand]

What problem does this PR solve?

Issue Number: close #4241, #4384

when closing the ddlSink with Kafka as the sink, it would block the owner or processorManager for a period of time, which had a negative impact on all running changefeeds.

• For Kafka, this would happen when all brokers were shut down.

What is changed and how it works?

At the owner side:

• close theddlSink asynchronsly
• for changefeed initialization, introduce changeFeedRunningStatus, at the moment for changeFeedClosed, changeFeedRunning, changeFeedClosing.

changeFeedClose -> changeFeedRunning if initialize the changefeed.

changeFeedRunning -> changefeedClosing if close the changefeed

changeFeedClosing -> changeFeedClosed if the downstream sink fully closed.

without introducing changeFeedClosing, a closing changefeed may be reinitializing at the same time, also may be closing multiple times.

At the processorManager side:

• initialize and close processor's sinkManager in an asynchronous way.
• Like above, introduce processorRunningStatus, at the moment for processorClosed, processorInitializing, processorRunning, processorClosing.

processorClosed -> processorInitializing, if try to initialize the sink
processorInitializing -> processorRunning, if the sinkManager is successfully initialized.
processorRunning -> processorClosing, if try to close the processor.
processorClosing -> processorClosed if the sinkManager is fully closed, not matter success or not.

• TablePipeline should not be created before the status is processorRunning.

Check List

Tests

• Manually test

• create 2 changefeed, 1 for MySQL, 1 for Kafka with open protocol, list changefeed show that two works fine.
• kill -9 the Kafka broker, and wait for 1 minute, logs show that owner receives an error and try to close the Kafka changefeed.
• During the Kafka closing period, which would cost another 1 minute, MySQL Changefeed still works normally.

Code changes

Side effects

Related changes

• Need to cherry-pick to the release branch

Release note

fix the owner may be blocked when closing the changefeed with Kafka sink which has a bad network connection between Kafka brokers.

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has not been approved.

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[codecov-commenter]

Codecov Report

Merging #4249 (7443202) into master (e469fb3) will decrease coverage by 0.4806%.
The diff coverage is 48.9864%.

Flag	Coverage Δ
cdc	59.1842% <46.0869%> (-1.0032%)	⬇️
dm	52.0540% <59.0909%> (-0.0496%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

@@               Coverage Diff                @@
##             master      #4249        +/-   ##
================================================
- Coverage   55.8077%   55.3270%   -0.4807%     
================================================
  Files           495        495                
  Lines         61246      61422       +176     
================================================
- Hits          34180      33983       -197     
- Misses        23614      24038       +424     
+ Partials       3452       3401        -51     

[3AceShowHand]

/run-all-tests

[3AceShowHand]

/run-all-tests

[3AceShowHand]

/run-all-tests

[3AceShowHand]

/run-all-tests

[ti-chi-bot]

@3AceShowHand: PR needs rebase.

Instructions 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 kubernetes/test-infra repository.

[Rustin170506]

It looks like we don't care if the close is successful, so can we just add a close timeout? That way the impact on the owner and processor is minimal?

[3AceShowHand]

It looks like we don't care if the close is successful, so can we just add a close timeout? That way the impact on the owner and processor is minimal?

Such a good idea, I will do this in another new PR. #5186

[3AceShowHand]

closed by #5186