-
Notifications
You must be signed in to change notification settings - Fork 485
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
storcon: fix AZ-driven tenant selection in chaos #10443
Conversation
7414 tests run: 7063 passed, 0 failed, 351 skipped (full report)Flaky tests (7)Postgres 17
Code coverage* (full report)
* collected from Rust tests only The comment gets automatically updated with the latest test results
dd431d7 at 2025-01-30T22:25:07.945Z :recycle: |
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, but I don't feel it needs to be that complex.
We can simply do an O(n) shuffle on tenant_id
. After that, pick the first batch_size
victims?
Oh I realized that they also have partial_shuffle that is O(batch_size) |
This reverts commit 2d0aa87.
|
Interesting suggestion, I mainly just wanted to merge the bugfix part of this PR, so I've reduced it to that. I'll try your suggestion in #10600 |
## Problem In #10438 it was pointed out that it would be good to avoid picking tenants in ID order, and also to avoid situations where we might double-select the same tenant. There was an initial swing at this in #10443, where Chi suggested a simpler approach which is done in this PR ## Summary of changes - Split total set of tenants into in and out of home AZ - Consume out of home AZ first, and if necessary shuffle + consume from out of home AZ
## Problem In neondatabase#10438 I had got the function for picking tenants backwards, and it was preferring to move things _away_ from their preferred AZ. ## Summary of changes - Fix condition in `is_attached_outside_preferred_az`
## Problem In neondatabase#10438 it was pointed out that it would be good to avoid picking tenants in ID order, and also to avoid situations where we might double-select the same tenant. There was an initial swing at this in neondatabase#10443, where Chi suggested a simpler approach which is done in this PR ## Summary of changes - Split total set of tenants into in and out of home AZ - Consume out of home AZ first, and if necessary shuffle + consume from out of home AZ
Problem
In #10438 I had got the function for picking tenants backwards, and it was preferring to move things away from their preferred AZ.
Summary of changes
is_attached_outside_preferred_az