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

Do not remove flood block from indices on nodes undergoing replacement #78942

Merged
merged 5 commits into from
Oct 12, 2021

Conversation

dakrone
Copy link
Member

@dakrone dakrone commented Oct 11, 2021

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

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
@dakrone dakrone added v8.0.0 :Core/Infra/Node Lifecycle Node startup, bootstrapping, and shutdown v7.16.0 labels Oct 11, 2021
@elasticmachine elasticmachine added the Team:Core/Infra Meta label for core/infra team label Oct 11, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (Team:Core/Infra)

Copy link
Contributor

@henningandersen henningandersen left a 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()
Copy link
Contributor

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.

Copy link
Member Author

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.

@dakrone dakrone merged commit 31e7cf9 into elastic:master Oct 12, 2021
@dakrone dakrone deleted the dont-unblock-on-node-replace branch October 12, 2021 18:07
@elasticsearchmachine
Copy link
Collaborator

💔 Backport failed

Status Branch Result
7.x Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 78942

dakrone added a commit to dakrone/elasticsearch that referenced this pull request Oct 12, 2021
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
elasticsearchmachine pushed a commit that referenced this pull request Oct 12, 2021
#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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Core/Infra/Node Lifecycle Node startup, bootstrapping, and shutdown >non-issue Team:Core/Infra Meta label for core/infra team v7.16.0 v8.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants