-
Notifications
You must be signed in to change notification settings - Fork 288
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
master(dm): support create a task in stopped
state
#4510
master(dm): support create a task in stopped
state
#4510
Conversation
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
/hold |
/run-dm-integration-tests |
/run-dm-integration-tests |
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.
rest lgtm
/run-dm-integration-tests |
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.
LGTM
} else if stage.Expect == pb.Stage_Paused { | ||
op = pb.TaskOp_Pause | ||
return opErrTypeBeforeOp, w.StartSubTask(&subTaskCfg, stage.Expect, expectValidatorStage, true) | ||
default: |
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.
st
is nil, so OperateSubTask
will fail. In old logic when st
is nil we always call StartSubTask
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.
i left a comment here, this err from operateSubTask is expected, caller should not operate a task that not in subTaskHolder
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.
Oh I see the old logic only handles Stage_Running and Stage_Paused. But I think the logic of deciding if the expected stage is valid should be put inside StartSubTask
and OperateSubTask
, not in operateSubTaskStage
. In other words, if the subtask exists, we simply forward expecte stage to OperateSubTask
, otherwise to StartSubTask
.
It's OK we change it in future.
}, pb.Stage_Stopped, pb.Stage_Stopped, true), IsNil) | ||
task = w.subTaskHolder.findSubTask("testStartTask-in-stopped") | ||
c.Assert(task, NotNil) | ||
c.Assert(task.Result().String(), Matches, ".*worker already closed.*") |
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.
may need discuss with PM, if user creates a stopped task, DM-worker should
reserve some structure in memory and paused them, or do nothing?
For example, can a stopped incremental task that will read binlog.000001 forbid relay log purging binlog.000001
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.
I think the stopped task still have to hold the necessary binlog.
An binlog may relates with multiple tasks. Whatever it's stopped or running , the binlog it needs should not be purged.
Maybe we can offer a feature in future like support query how many tasks relate with this binlog and users can purge it forced.
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.
maybe later, current just do nothing
Co-authored-by: lance6716 <lance6716@gmail.com>
} else if stage.Expect == pb.Stage_Paused { | ||
op = pb.TaskOp_Pause | ||
return opErrTypeBeforeOp, w.StartSubTask(&subTaskCfg, stage.Expect, expectValidatorStage, true) | ||
default: |
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.
Oh I see the old logic only handles Stage_Running and Stage_Paused. But I think the logic of deciding if the expected stage is valid should be put inside StartSubTask
and OperateSubTask
, not in operateSubTaskStage
. In other words, if the subtask exists, we simply forward expecte stage to OperateSubTask
, otherwise to StartSubTask
.
It's OK we change it in future.
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 5594251
|
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 7b21bf7
|
@Ehco1996: Your PR was out of date, I have automatically updated it for you. At the same time I will also trigger all tests for you: /run-all-tests If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes. 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 ti-community-infra/tichi repository. |
What problem does this PR solve?
Issue Number: ref #4484
What is changed and how it works?
for master
openapi.go
intoopenapi_view.go
andopenapi_controaller.go
, more inner logic such as filter,validate, and organze reponse will be add toopenapi_controaller
stopped
stageop_delete
in proto, when worker see this op, it will delete this subtaskop_delete
to update task stagefor worker
stopped
stage when subtask not startedoperateSubTaskStage
logic to match new stageCheck List
Tests
Code changes
Side effects
Related changes
Release note