Short-circuit rebalancing when disabled#40942
Conversation
Today if `cluster.routing.rebalance.enable: none` then rebalancing is disabled, but we still execute `balanceByWeights()` and perform some rather expensive calculations before discovering that we cannot rebalance any shards. In a large cluster this can make cluster state updates occur rather slowly. With this change we check earlier whether rebalancing is globally disabled and, if so, avoid the rebalancing process entirely.
|
Pinging @elastic/es-distributed |
.../org/elasticsearch/cluster/routing/allocation/decider/EnableAllocationShortCircuitTests.java
Outdated
Show resolved
Hide resolved
.../org/elasticsearch/cluster/routing/allocation/decider/EnableAllocationShortCircuitTests.java
Outdated
Show resolved
Hide resolved
.../org/elasticsearch/cluster/routing/allocation/decider/EnableAllocationShortCircuitTests.java
Outdated
Show resolved
Hide resolved
henningandersen
left a comment
There was a problem hiding this comment.
Looking good, I added a few smaller things to address.
| } | ||
|
|
||
| for (IndexMetaData indexMetaData : allocation.metaData()) { | ||
| if (INDEX_ROUTING_REBALANCE_ENABLE_SETTING.exists(indexMetaData.getSettings())) { |
There was a problem hiding this comment.
Would it make sense to also be able to short circuit if that setting is set to Rebalance.NONE?
There was a problem hiding this comment.
Ok, I added this in 0c5c04b. I don't think this is a common configuration, so it'd be ok either way.
|
|
||
| ClusterState clusterState = ClusterState.builder(ClusterName.CLUSTER_NAME_SETTING.get(Settings.EMPTY)) | ||
| .nodes(DiscoveryNodes.builder().add(newNode("node1"))).build(); | ||
|
|
There was a problem hiding this comment.
I think it makes sense to also add some indices in this test case?
There was a problem hiding this comment.
Sort of, although then we have to allocate their shards or else the ClusterRebalanceAllocationDecider steps in and prevents rebalancing. I expanded the tests to do this.
|
@elasticmachine run elasticsearch-ci/2 |
henningandersen
left a comment
There was a problem hiding this comment.
LGTM.
Thanks @DaveCTurner
Today if `cluster.routing.rebalance.enable: none` then rebalancing is disabled, but we still execute `balanceByWeights()` and perform some rather expensive calculations before discovering that we cannot rebalance any shards. In a large cluster this can make cluster state updates occur rather slowly. With this change we check earlier whether rebalancing is globally disabled and, if so, avoid the rebalancing process entirely.
Today if `cluster.routing.rebalance.enable: none` then rebalancing is disabled, but we still execute `balanceByWeights()` and perform some rather expensive calculations before discovering that we cannot rebalance any shards. In a large cluster this can make cluster state updates occur rather slowly. With this change we check earlier whether rebalancing is globally disabled and, if so, avoid the rebalancing process entirely.
Today if `cluster.routing.rebalance.enable: none` then rebalancing is disabled, but we still execute `balanceByWeights()` and perform some rather expensive calculations before discovering that we cannot rebalance any shards. In a large cluster this can make cluster state updates occur rather slowly. With this change we check earlier whether rebalancing is globally disabled and, if so, avoid the rebalancing process entirely.
This reverts commit b53488e.
This reverts commit 4544b29.
This reverts commit f78e6ef.
Today if `cluster.routing.rebalance.enable: none` then rebalancing is disabled, but we still execute `balanceByWeights()` and perform some rather expensive calculations before discovering that we cannot rebalance any shards. In a large cluster this can make cluster state updates occur rather slowly. With this change we check earlier whether rebalancing is globally disabled and, if so, avoid the rebalancing process entirely. Relates elastic#40942 which was reverted because of egregiously faulty tests.
…e-unsafe-publication * elastic/master: Update contributing docs to reflect JDK 11 (elastic#40955) Docs: Simplifying setup by using module configuration variant syntax (elastic#40879) Unmute CreateIndexIT testCreateAndDeleteIndexConcurrently CI failures (elastic#40960) Revert "Short-circuit rebalancing when disabled (elastic#40942)" Mute EnableAllocationShortCircuitTests SQL: Refactor args verification of In & conditionals (elastic#40916) Avoid sharing source directories as it breaks intellij (elastic#40877) Short-circuit rebalancing when disabled (elastic#40942) SQL: Prefer resultSets over exceptions in metadata (elastic#40641) Mute ClusterPrivilegeTests.testThatSnapshotAndRestore Fix Race in AsyncTwoPhaseIndexerTests.testStateMachine (elastic#40947) Relax Overly Strict Assertion in TransportShardBulkAction (elastic#40940)
Today if `cluster.routing.rebalance.enable: none` then rebalancing is disabled, but we still execute `balanceByWeights()` and perform some rather expensive calculations before discovering that we cannot rebalance any shards. In a large cluster this can make cluster state updates occur rather slowly. With this change we check earlier whether rebalancing is globally disabled and, if so, avoid the rebalancing process entirely. Relates #40942 which was reverted because of egregiously faulty tests.
Today if `cluster.routing.rebalance.enable: none` then rebalancing is disabled, but we still execute `balanceByWeights()` and perform some rather expensive calculations before discovering that we cannot rebalance any shards. In a large cluster this can make cluster state updates occur rather slowly. With this change we check earlier whether rebalancing is globally disabled and, if so, avoid the rebalancing process entirely. Relates #40942 which was reverted because of egregiously faulty tests.
Today if `cluster.routing.rebalance.enable: none` then rebalancing is disabled, but we still execute `balanceByWeights()` and perform some rather expensive calculations before discovering that we cannot rebalance any shards. In a large cluster this can make cluster state updates occur rather slowly. With this change we check earlier whether rebalancing is globally disabled and, if so, avoid the rebalancing process entirely. Relates #40942 which was reverted because of egregiously faulty tests.
Today if `cluster.routing.rebalance.enable: none` then rebalancing is disabled, but we still execute `balanceByWeights()` and perform some rather expensive calculations before discovering that we cannot rebalance any shards. In a large cluster this can make cluster state updates occur rather slowly. With this change we check earlier whether rebalancing is globally disabled and, if so, avoid the rebalancing process entirely. Relates #40942 which was reverted because of egregiously faulty tests.
Today if `cluster.routing.rebalance.enable: none` then rebalancing is disabled, but we still execute `balanceByWeights()` and perform some rather expensive calculations before discovering that we cannot rebalance any shards. In a large cluster this can make cluster state updates occur rather slowly. With this change we check earlier whether rebalancing is globally disabled and, if so, avoid the rebalancing process entirely.
Today if `cluster.routing.rebalance.enable: none` then rebalancing is disabled, but we still execute `balanceByWeights()` and perform some rather expensive calculations before discovering that we cannot rebalance any shards. In a large cluster this can make cluster state updates occur rather slowly. With this change we check earlier whether rebalancing is globally disabled and, if so, avoid the rebalancing process entirely. Relates elastic#40942 which was reverted because of egregiously faulty tests.
Today if
cluster.routing.rebalance.enable: nonethen rebalancing is disabled,but we still execute
balanceByWeights()and perform some rather expensivecalculations before discovering that we cannot rebalance any shards. In a large
cluster this can make cluster state updates occur rather slowly. With this
change we check earlier whether rebalancing is globally disabled and, if so,
avoid the rebalancing process entirely.