-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Allow freezing searchable snapshots #52653
Allow freezing searchable snapshots #52653
Conversation
Today it does not work to freeze an index restored as a searchable snapshot, because both features try and supply their own `Engine` implementation. However a searchable snapshot works with both a `ReadOnlyEngine` and a `FrozenEngine`, so we can check to see if the searchable snapshot is frozen and, if so, avoid supplying a second `Engine` in that case.
Pinging @elastic/es-distributed (:Distributed/Snapshot/Restore) |
@@ -111,7 +111,8 @@ public void onRepositoriesModule(RepositoriesModule repositoriesModule) { | |||
|
|||
@Override | |||
public Optional<EngineFactory> getEngineFactory(IndexSettings indexSettings) { | |||
if (SearchableSnapshotRepository.SNAPSHOT_DIRECTORY_FACTORY_KEY.equals(INDEX_STORE_TYPE_SETTING.get(indexSettings.getSettings()))) { | |||
if (SearchableSnapshotRepository.SNAPSHOT_DIRECTORY_FACTORY_KEY.equals(INDEX_STORE_TYPE_SETTING.get(indexSettings.getSettings())) | |||
&& indexSettings.getSettings().getAsBoolean("index.frozen", false) == 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.
Not sure about introducing this string literal here, vs adding a dependency on the frozen-indices
module and referring to the setting directly.
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 would prefer to avoid the dependency and just use the String literal (we have other such cases in our code base).
I also wonder if we need to handle closed replicated snapshot indices (i.e. use NoOpEngine
for those).
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.
We already bypass this mechanism for closed indices:
elasticsearch/server/src/main/java/org/elasticsearch/indices/IndicesService.java
Lines 622 to 627 in 0d1e67d
private EngineFactory getEngineFactory(final IndexSettings idxSettings) { | |
final IndexMetaData indexMetaData = idxSettings.getIndexMetaData(); | |
if (indexMetaData != null && indexMetaData.getState() == IndexMetaData.State.CLOSE) { | |
// NoOpEngine takes precedence as long as the index is closed | |
return NoOpEngine::new; | |
} |
I added a test case showing that closing and reopening a searchable snapshot index does work.
import org.elasticsearch.snapshots.SnapshotInfo; | ||
import org.elasticsearch.test.ESIntegTestCase; | ||
import org.elasticsearch.xpack.core.frozen.action.FreezeIndexAction; | ||
import org.elasticsearch.xpack.frozen.FrozenIndices; |
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.
Similarly, not sure this is appropriate in terms of dependencies but I figured these interdependencies were ok for tests.
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.
For tests, it's ok I think
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 it's OK too, but I'd like to avoid adding too many test conditionals to this test. Maybe we could test this in AbstractSearchableSnapshotsRestTestCase
instead?
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.
Ok, I moved the tests to the REST suite.
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
public void testSearchResultsWhenFrozen() throws Exception { | ||
runSearchableSnapshotsTest((restoredIndexName, numDocs) -> { | ||
final Request freezeRequest = new Request(HttpPost.METHOD_NAME, restoredIndexName + "/_freeze"); | ||
client().performRequest(freezeRequest); |
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.
Can you assertOK()
this?
public void testCloseAndReopen() throws Exception { | ||
runSearchableSnapshotsTest((restoredIndexName, numDocs) -> { | ||
final Request closeRequest = new Request(HttpPost.METHOD_NAME, restoredIndexName + "/_close"); | ||
client().performRequest(closeRequest); |
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.
Can you assertOK()
this?
ensureGreen(restoredIndexName); | ||
|
||
final Request openRequest = new Request(HttpPost.METHOD_NAME, restoredIndexName + "/_open"); | ||
client().performRequest(openRequest); |
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.
Can you assertOK()
this?
…archable-snapshots
Today it does not work to freeze an index restored as a searchable snapshot,
because both features try and supply their own
Engine
implementation. Howevera searchable snapshot works with both a
ReadOnlyEngine
and aFrozenEngine
,so we can check to see if the searchable snapshot is frozen and, if so, avoid
supplying a second
Engine
in that case.Relates #50999