-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Do not remove flood block from indices on nodes undergoing replacement #78942
Conversation
This commit enhances `DiskThresholdMonitor` so that indices that have a flood-stage block will not have the block removed while they reside on a node that is part of a "REPLACE"-type node shutdown. This prevents a situation where a node is blocked due to disk usage, then during the replacement the block is removed while shards are relocating to the target node, indexing occurs, and then the target runs out of space due to the additional documents. Relates to elastic#70338 and elastic#76247
Pinging @elastic/es-core-infra (Team:Core/Infra) |
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.
.collect(Collectors.toSet()); | ||
|
||
// Generate a set of all the indices that exist on either the target or source of a node replacement | ||
final Set<String> indicesOnReplaceSourceOrTarget = nodesIdsPartOfReplacement.stream() |
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 wonder if we should special handle the case where the source is empty (no assigned shards) and allow releasing the block then? That should be safe and could shorten the time until releasing the block in case there are multiple orchestration steps involved.
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 we should leave it as-is for now, since we don't expect to be in the COMPLETE
phase for a replacement for more than ~10ish seconds anyway, and if we determine that it is too long in the future, we can revisit this in subsequent work.
...er/src/test/java/org/elasticsearch/cluster/routing/allocation/DiskThresholdMonitorTests.java
Outdated
Show resolved
Hide resolved
...er/src/test/java/org/elasticsearch/cluster/routing/allocation/DiskThresholdMonitorTests.java
Outdated
Show resolved
Hide resolved
💔 Backport failed
You can use sqren/backport to manually backport by running |
elastic#78942) This commit enhances `DiskThresholdMonitor` so that indices that have a flood-stage block will not have the block removed while they reside on a node that is part of a "REPLACE"-type node shutdown. This prevents a situation where a node is blocked due to disk usage, then during the replacement the block is removed while shards are relocating to the target node, indexing occurs, and then the target runs out of space due to the additional documents. Relates to elastic#70338 and elastic#76247 # Conflicts: # server/src/test/java/org/elasticsearch/cluster/routing/allocation/DiskThresholdMonitorTests.java
#78942) (#79008) This commit enhances `DiskThresholdMonitor` so that indices that have a flood-stage block will not have the block removed while they reside on a node that is part of a "REPLACE"-type node shutdown. This prevents a situation where a node is blocked due to disk usage, then during the replacement the block is removed while shards are relocating to the target node, indexing occurs, and then the target runs out of space due to the additional documents. Relates to #70338 and #76247 # Conflicts: # server/src/test/java/org/elasticsearch/cluster/routing/allocation/DiskThresholdMonitorTests.java
This commit enhances
DiskThresholdMonitor
so that indices that have a flood-stage block will nothave the block removed while they reside on a node that is part of a "REPLACE"-type node shutdown.
This prevents a situation where a node is blocked due to disk usage, then during the replacement the
block is removed while shards are relocating to the target node, indexing occurs, and then the
target runs out of space due to the additional documents.
Relates to #70338 and #76247