Skip to content
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

VReplication: Address SwitchTraffic bugs around replication lag and cancel on error #17616

Open
wants to merge 15 commits into
base: main
Choose a base branch
from

Conversation

mattlord
Copy link
Contributor

@mattlord mattlord commented Jan 23, 2025

Description

This PR improves the error handling for cancel failures (see issue). When the context changes are commented out in the PR branch we can see the new error handling in action here when using the manual test in the issue:

❯ vtctldclient MoveTables --workflow commerce2customer --target-keyspace customer switchtraffic
E0123 10:57:24.082537   40795 main.go:60] rpc error: code = Unknown desc = failed to sync up replication between the source and target: rpc error: code = DeadlineExceeded desc = context deadline exceeded

could not revert denied tables / shard access: Code: INTERNAL
keyspace commerce is not locked (no locksInfo)

cancel migration failed, manual cleanup work may be necessary

And with the context changes in place:

❯ vtctldclient MoveTables --workflow commerce2customer --target-keyspace customer switchtraffic
E0123 11:28:24.848992   80414 main.go:60] rpc error: code = Unknown desc = failed to sync up replication between the source and target: rpc error: code = DeadlineExceeded desc = context deadline exceeded

This PR also addresses the inaccuracy of the max_v_replication_transaction_lag value as noted in the issue. After adjusting this calculation, the manual test now fails in the canSwitch() pre-check as expected:

...
vtctldclient MoveTables --workflow commerce2customer --target-keyspace customer switchtraffic
E0123 13:09:33.292425    7651 main.go:60] rpc error: code = Unknown desc = cannot switch traffic for workflow commerce2customer at this time: replication lag 84s is higher than allowed lag 30s

And when monitoring the lag as the test runs you can see it correctly measured when there is little to no lag, you can see it increase as the actual lag increases, and then see it go back down (it is NOT included in the output when the value is 0):

❯ while true; do vtctldclient GetWorkflows customer --compact --include-logs=false | grep max_v_replication_transaction_lag; sleep 1; done
...
      "max_v_replication_transaction_lag": "1",
      "max_v_replication_transaction_lag": "1",
      "max_v_replication_transaction_lag": "2",
      "max_v_replication_transaction_lag": "1",
...
      "max_v_replication_transaction_lag": "84",
      "max_v_replication_transaction_lag": "85",
      "max_v_replication_transaction_lag": "86",
      "max_v_replication_transaction_lag": "87",
      "max_v_replication_transaction_lag": "73",
      "max_v_replication_transaction_lag": "74",
      "max_v_replication_transaction_lag": "75",
...
      "max_v_replication_transaction_lag": "93",
      "max_v_replication_transaction_lag": "94",
      "max_v_replication_transaction_lag": "1",
      "max_v_replication_transaction_lag": "1",
      "max_v_replication_transaction_lag": "1",
      "max_v_replication_transaction_lag": "1",

Note

I think that we should backport this all the way to v19 as you cannot successfully revert a failed traffic switch in v19+ due to the changes in #17340
Of course the real issue was the testing gap, which was also closed in this PR.

Related Issue(s)

Checklist

  • "Backport to:" labels have been added if this change should be back-ported to release branches
  • If this change is to be back-ported to previous releases, a justification is included in the PR description
  • Tests were added or are not required
  • Did the new or modified tests pass consistently locally and on CI?
  • Documentation was added or is not required

Copy link
Contributor

vitess-bot bot commented Jan 23, 2025

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

  • Ensure that the Pull Request has a descriptive title.
  • Ensure there is a link to an issue (except for internal cleanup and flaky test fixes), new features should have an RFC that documents use cases and test cases.

Tests

  • Bug fixes should have at least one unit or end-to-end test, enhancement and new features should have a sufficient number of tests.

Documentation

  • Apply the release notes (needs details) label if users need to know about this change.
  • New features should be documented.
  • There should be some code comments as to why things are implemented the way they are.
  • There should be a comment at the top of each new or modified test to explain what the test does.

New flags

  • Is this flag really necessary?
  • Flag names must be clear and intuitive, use dashes (-), and have a clear help text.

If a workflow is added or modified:

  • Each item in Jobs should be named in order to mark it as required.
  • If the workflow needs to be marked as required, the maintainer team must be notified.

Backward compatibility

  • Protobuf changes should be wire-compatible.
  • Changes to _vt tables and RPCs need to be backward compatible.
  • RPC changes should be compatible with vitess-operator
  • If a flag is removed, then it should also be removed from vitess-operator and arewefastyet, if used there.
  • vtctl command output order should be stable and awk-able.

@vitess-bot vitess-bot bot added NeedsBackportReason If backport labels have been applied to a PR, a justification is required NeedsDescriptionUpdate The description is not clear or comprehensive enough, and needs work NeedsIssue A linked issue is missing for this Pull Request NeedsWebsiteDocsUpdate What it says labels Jan 23, 2025
@github-actions github-actions bot added this to the v22.0.0 milestone Jan 23, 2025
Signed-off-by: Matt Lord <[email protected]>
@mattlord mattlord added Backport to: release-19.0 Needs to be back ported to release-19.0 Backport to: release-20.0 Needs to be backport to release-20.0 Backport to: release-21.0 Needs to be backport to release-21.0 and removed NeedsWebsiteDocsUpdate What it says labels Jan 23, 2025
Copy link

codecov bot commented Jan 23, 2025

Codecov Report

Attention: Patch coverage is 50.00000% with 52 lines in your changes missing coverage. Please review.

Project coverage is 67.63%. Comparing base (99856a2) to head (2253a88).
Report is 7 commits behind head on main.

Files with missing lines Patch % Lines
go/vt/vtctl/workflow/traffic_switcher.go 25.00% 21 Missing ⚠️
go/vt/vtctl/workflow/server.go 42.85% 16 Missing ⚠️
go/vt/vtctl/workflow/workflows.go 81.81% 6 Missing ⚠️
go/vt/vtctl/workflow/stream_migrator.go 54.54% 5 Missing ⚠️
go/vt/vtctl/workflow/switcher.go 0.00% 2 Missing ⚠️
go/vt/vtctl/workflow/switcher_dry_run.go 0.00% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main   #17616      +/-   ##
==========================================
- Coverage   67.69%   67.63%   -0.06%     
==========================================
  Files        1586     1586              
  Lines      255403   255666     +263     
==========================================
+ Hits       172883   172911      +28     
- Misses      82520    82755     +235     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Signed-off-by: Matt Lord <[email protected]>
Signed-off-by: Matt Lord <[email protected]>
Signed-off-by: Matt Lord <[email protected]>
Signed-off-by: Matt Lord <[email protected]>
@mattlord mattlord removed NeedsDescriptionUpdate The description is not clear or comprehensive enough, and needs work NeedsIssue A linked issue is missing for this Pull Request NeedsBackportReason If backport labels have been applied to a PR, a justification is required labels Jan 23, 2025
Comment on lines +1087 to +1091
rmsource, rmtarget := false, true
if backward {
rmsource, rmtarget = true, false
}
Copy link
Contributor Author

@mattlord mattlord Jan 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was another bug in our cancel path that was highlighted by the new test (specifically by trying to query the table after the failed switch).

Signed-off-by: Matt Lord <[email protected]>
@mattlord mattlord marked this pull request as ready for review January 23, 2025 22:28
@mattlord mattlord requested a review from deepthi as a code owner January 23, 2025 22:28
@mattlord mattlord changed the title VReplication: Address SwitchWrites bugs around replication lag and cancel on error VReplication: Address SwitchTraffic bugs around replication lag and cancel on error Jan 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backport to: release-19.0 Needs to be back ported to release-19.0 Backport to: release-20.0 Needs to be backport to release-20.0 Backport to: release-21.0 Needs to be backport to release-21.0 Component: VReplication Type: Bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bug Report: VReplication SwitchTraffic cancel fails due to not having topo locks
3 participants