Skip to content

Add SearchableSnapshotRepository #50239

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

Conversation

DaveCTurner
Copy link
Contributor

This commit adds a repository type that allows the creation of an index backed
by searchable snapshots. These indices are allocated and recovered just like
normal indices, but the underlying SearchableSnapshotDirectory makes sure
that no recovery need take place since the correct files all seem to already
exist on the target node.

There are a number of limitations in this implementation:

  • like normal indices, after the intial allocation the primary is always
    allocated to a node that previously held an in-sync copy. If the cluster
    loses all copies of a snapshot-backed index then it does not attempt to
    recover.

  • peer recoveries of indices containing deletes do not currently work.

  • when performing disk-based shard allocation we make no attempt to quantify
    the disk usage of these shards any differently.

This commit adds a repository type that allows the creation of an index backed
by searchable snapshots. These indices are allocated and recovered just like
normal indices, but the underlying `SearchableSnapshotDirectory` makes sure
that no recovery need take place since the correct files all seem to already
exist on the target node.

There are a number of limitations in this implementation:

- like normal indices, after the intial allocation the primary is always
  allocated to a node that previously held an in-sync copy. If the cluster
  loses all copies of a snapshot-backed index then it does not attempt to
  recover.

- peer recoveries of indices containing deletes do not currently work.

- when performing disk-based shard allocation we make no attempt to quantify
  the disk usage of these shards any differently.
@DaveCTurner DaveCTurner added >enhancement :Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs labels Dec 16, 2019
@DaveCTurner DaveCTurner requested review from tlrx and ywelsch December 16, 2019 15:32
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (:Distributed/Snapshot/Restore)

Copy link
Contributor

@ywelsch ywelsch left a comment

Choose a reason for hiding this comment

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

LGTM

@DaveCTurner DaveCTurner merged commit 74c4041 into elastic:feature/searchable-snapshots Dec 17, 2019
@DaveCTurner DaveCTurner deleted the 2019-12-16-recover-searchable-snapshot branch December 17, 2019 08:59
@DaveCTurner DaveCTurner mentioned this pull request Jan 14, 2020
19 tasks
DaveCTurner added a commit to DaveCTurner/elasticsearch that referenced this pull request Mar 16, 2020
In elastic#50239 we introduced a temporary workaround in Store#tryOpenIndex to allow
searchable snapshots shards to be allocated anywhere. elastic#52527 reverts this
workaround but did not revert the associated test changes. This commit reverts
the associated test changes.
DaveCTurner added a commit that referenced this pull request Mar 16, 2020
In #50239 we introduced a temporary workaround in Store#tryOpenIndex to allow
searchable snapshots shards to be allocated anywhere. #52527 reverts this
workaround but did not revert the associated test changes. This commit reverts
the associated test changes.
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.

3 participants