-
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
Revert fast refresh using search shards #115019
Revert fast refresh using search shards #115019
Conversation
As this induces ES-8275 and makes fleet time outs for some APIs. Relates ES-9573
@@ -103,7 +105,10 @@ static boolean shouldLoadRandomAccessFiltersEagerly(IndexSettings settings) { | |||
boolean loadFiltersEagerlySetting = settings.getValue(INDEX_LOAD_RANDOM_ACCESS_FILTERS_EAGERLY_SETTING); | |||
boolean isStateless = DiscoveryNode.isStateless(settings.getNodeSettings()); | |||
if (isStateless) { | |||
return loadFiltersEagerlySetting && DiscoveryNode.hasRole(settings.getNodeSettings(), DiscoveryNodeRole.SEARCH_ROLE); | |||
return loadFiltersEagerlySetting |
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 was not sure whether to revert this part to its original state, as it was wrong. This has the discussion. Basically the cache should be loaded whenever the shard can be searched. But welcome feedback.
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
Pinging @elastic/es-distributed (Team:Distributed) |
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
@@ -126,10 +126,11 @@ protected void asyncShardOperation(GetRequest request, ShardId shardId, ActionLi | |||
IndexService indexService = indicesService.indexServiceSafe(shardId.getIndex()); | |||
IndexShard indexShard = indexService.getShard(shardId.id()); | |||
if (indexShard.routingEntry().isPromotableToPrimary() == false) { | |||
assert indexShard.indexSettings().isFastRefresh() == false |
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 have no idea how serverless upgrade tests are working and we'll see what CI says, but I suppose this can trip if a request is wrongly redirected in a mixed cluster.
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.
You're right, lets not risk it. I'll comment the assertion and add a TODO.
@@ -103,7 +105,10 @@ static boolean shouldLoadRandomAccessFiltersEagerly(IndexSettings settings) { | |||
boolean loadFiltersEagerlySetting = settings.getValue(INDEX_LOAD_RANDOM_ACCESS_FILTERS_EAGERLY_SETTING); | |||
boolean isStateless = DiscoveryNode.isStateless(settings.getNodeSettings()); | |||
if (isStateless) { | |||
return loadFiltersEagerlySetting && DiscoveryNode.hasRole(settings.getNodeSettings(), DiscoveryNodeRole.SEARCH_ROLE); | |||
return loadFiltersEagerlySetting |
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
As this induces ES-8275 and makes fleet time outs for some APIs. Relates ES-9573
As this induces ES-8275 and makes fleet time outs for some APIs. Relates ES-9573
As this induces ES-8275 and makes fleet time outs for some APIs. Relates ES-9573
The changes of PR elastic#115019 were reverted because it induced ES-8275. Now that the ticket is done, this PR re-introduces the reverted changes. Fast refresh indices should now behave like non fast refresh indices in how they execute (m)gets and searches. I.e., they should use the search shards. For BWC, we define a new transport version. We expect search shards to be upgraded first, before promotable shards. Until the cluster is fully upgraded, the promotable shards (whether upgraded or not) will still receive and execute gets/searches locally. Relates ES-9573
The changes of PR #115019 were reverted because it induced ES-8275. Now that the ticket is done, this PR re-introduces the reverted changes. Fast refresh indices should now behave like non fast refresh indices in how they execute (m)gets and searches. I.e., they should use the search shards. For BWC, we define a new transport version. We expect search shards to be upgraded first, before promotable shards. Until the cluster is fully upgraded, the promotable shards (whether upgraded or not) will still receive and execute gets/searches locally. Relates ES-9573
The changes of PR elastic#115019 were reverted because it induced ES-8275. Now that the ticket is done, this PR re-introduces the reverted changes. Fast refresh indices should now behave like non fast refresh indices in how they execute (m)gets and searches. I.e., they should use the search shards. For BWC, we define a new transport version. We expect search shards to be upgraded first, before promotable shards. Until the cluster is fully upgraded, the promotable shards (whether upgraded or not) will still receive and execute gets/searches locally. Relates ES-9573
The changes of PR elastic#115019 were reverted because it induced ES-8275. Now that the ticket is done, this PR re-introduces the reverted changes. Fast refresh indices should now behave like non fast refresh indices in how they execute (m)gets and searches. I.e., they should use the search shards. For BWC, we define a new transport version. We expect search shards to be upgraded first, before promotable shards. Until the cluster is fully upgraded, the promotable shards (whether upgraded or not) will still receive and execute gets/searches locally. Relates ES-9573
As this induces ES-8275 and makes fleet time outs for some APIs.
Reverts #113478 .
Relates ES-9573