Skip to content
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

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)

@@ -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) {
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