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
status missed even if backup job succeeds (#3648) #3667
status missed even if backup job succeeds (#3648) #3667
Conversation
Signed-off-by: ti-srebot <ti-srebot@pingcap.com>
@DanielZhangQD please accept the invitation then you can push to the cherry-pick pull requests. |
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
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 7a6478e
|
/merge |
@handlerww: In response to this:
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/ti-community-prow repository. |
Codecov Report
@@ Coverage Diff @@
## release-1.1 #3667 +/- ##
==============================================
Coverage ? 52.09%
==============================================
Files ? 153
Lines ? 14920
Branches ? 0
==============================================
Hits ? 7773
Misses ? 6411
Partials ? 736
Flags with carried forward coverage won't be shown. Click here to find out more. |
cherry-pick #3648 to release-1.1
What problem does this PR solve?
Fix the issue that in some cases some fields, e.g. BACKUPPATH, BACKUPSIZE, COMMITTS, etc. in the status of Backup CR or Restore CR are missed even if the backup or restore job succeed.
Fix #3635
What is changed and how does it work?
Root cause:
Take the Backup CR for example, and the Restore CR has a similar logic.
Currently, two controllers will update the status of Backup CR, one is the backup controller in the tidb-controller-manager Pod, which only updates the conditions slice in the status. The other is the controller in the backup-manager Pod which is the real backup job and will update all the fields in the status.
With the current status update logic, if something wrong with the update API call, the status updater will retrieve the latest Backup resource from the lister and replace the
status
field totally with the old status, so if the backup-manager Pod updates all the fields in the status and then the tidb-controller-manager Pod updates the conditions slice in the status, all the other fields updated by the backup-manager will be lost.So we should update the status based on the latest status instead of the old status.
Code changes
Tests
BackupSchedule
with BRBackup
CRs works as expectedBackup
is updated correctly even if an error occurs during the update:BackupSchedule
with DumplingBackup
CRs works as expectedBackup
is updated correctly even if an error occurs during the update:Restore
with BR and the status of theRestore
is updated correctly even if an error occurs during the update:Restore
with Lightning and the status of theRestore
is updated correctly even if an error occurs during the update:Side effects
Related changes
Release Notes
Please refer to Release Notes Language Style Guide before writing the release note.