Skip to content

Conversation

@DaveCTurner
Copy link
Contributor

@DaveCTurner DaveCTurner commented Feb 21, 2020

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.

Relates #50999

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.
@DaveCTurner DaveCTurner added >enhancement :Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs labels Feb 21, 2020
@DaveCTurner DaveCTurner requested review from tlrx and ywelsch February 21, 2020 17:15
@elasticmachine
Copy link
Collaborator

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) {
Copy link
Contributor Author

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.

Copy link
Contributor

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).

Copy link
Contributor Author

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:

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;
Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Member

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?

Copy link
Contributor Author

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.

@DaveCTurner DaveCTurner mentioned this pull request Feb 21, 2020
19 tasks
@DaveCTurner
Copy link
Contributor Author

@tlrx @ywelsch this is ready for review.

Copy link
Member

@tlrx tlrx left a 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);
Copy link
Member

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);
Copy link
Member

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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you assertOK() this?

@DaveCTurner
Copy link
Contributor Author

DaveCTurner commented Mar 2, 2020

Thanks @tlrx. Good catch on the missing assertOKs, added in b10dd74.

@DaveCTurner DaveCTurner merged commit 050583e into elastic:feature/searchable-snapshots Mar 2, 2020
@DaveCTurner DaveCTurner deleted the 2020-02-21-freeze-searchable-snapshots branch March 2, 2020 11:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs >enhancement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants