Allow freezing searchable snapshots#52653
Allow freezing searchable snapshots#52653DaveCTurner merged 8 commits intoelastic:feature/searchable-snapshotsfrom
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) |
| 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.
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.
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.
We already bypass this mechanism for closed indices:
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.
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.
For tests, it's ok I think
There was a problem hiding this comment.
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.
Ok, I moved the tests to the REST suite.
| public void testSearchResultsWhenFrozen() throws Exception { | ||
| runSearchableSnapshotsTest((restoredIndexName, numDocs) -> { | ||
| final Request freezeRequest = new Request(HttpPost.METHOD_NAME, restoredIndexName + "/_freeze"); | ||
| client().performRequest(freezeRequest); |
| public void testCloseAndReopen() throws Exception { | ||
| runSearchableSnapshotsTest((restoredIndexName, numDocs) -> { | ||
| final Request closeRequest = new Request(HttpPost.METHOD_NAME, restoredIndexName + "/_close"); | ||
| client().performRequest(closeRequest); |
| ensureGreen(restoredIndexName); | ||
|
|
||
| final Request openRequest = new Request(HttpPost.METHOD_NAME, restoredIndexName + "/_open"); | ||
| client().performRequest(openRequest); |
…archable-snapshots
Today it does not work to freeze an index restored as a searchable snapshot,
because both features try and supply their own
Engineimplementation. Howevera searchable snapshot works with both a
ReadOnlyEngineand aFrozenEngine,so we can check to see if the searchable snapshot is frozen and, if so, avoid
supplying a second
Enginein that case.Relates #50999