This package exposes the Elasticsearch Snapshot functionality.
There are two communication channels between all nodes and master in the snapshot functionality:
- The master updates the cluster state by adding, removing or altering the contents of its custom entry
SnapshotsInProgress. All nodes consume the state of the
SnapshotsInProgressand will start or abort relevant shard snapshot tasks accordingly.
- Nodes that are executing shard snapshot tasks report either success or failure of their snapshot task by submitting a
UpdateIndexShardSnapshotStatusRequestto the master node that will update the snapshot's entry in the cluster state accordingly.
Snapshots are created by the following sequence of events:
- First the
SnapshotsServicedetermines the primary shards' assignments for all indices that are being snapshotted and creates a
STARTEDand adds the map of
SnapshotsInProgress.ShardSnapshotStatusthat tracks the assignment of which node is to snapshot which shard. All shard snapshots are executed on the shard's primary node. Thus all shards for which the primary node was found to have a healthy copy of the shard are marked as being in state
INITin this map. If the primary for a shard is unassigned, it is marked as
MISSINGin this map. In case the primary is initializing at this point, it is marked as in state
WAITING. In case a shard's primary is relocated at any point after its
SnapshotsInProgress.Entrywas created and thus been assigned to a specific cluster node, that shard's snapshot will fail and move to state
- The new
SnapshotsInProgress.Entryis then observed by
SnapshotShardsService.clusterChanged(org.elasticsearch.cluster.ClusterChangedEvent)on all nodes and since the entry is in state
SnapshotShardsServicewill check if any local primary shards are to be snapshotted (signaled by the shard's snapshot state being
INIT). For those local primary shards found in state
INIT) the snapshot process of writing the shard's data files to the snapshot's
Repositoryis executed. Once the snapshot execution finishes for a shard an
UpdateIndexShardSnapshotStatusRequestis sent to the master node signaling either status
FAILED. The master node will then update a shard's state in the snapshots
SnapshotsInProgress.Entrywhenever it receives such a
- If as a result of the received status update requests, all shards in the cluster state are in a completed state, i.e are marked as
SnapshotShardsServicewill update the state of the
Entryitself and mark it as
SUCCESS. At the same time
SnapshotsService.endSnapshot(org.elasticsearch.cluster.SnapshotsInProgress.Entry, org.elasticsearch.cluster.metadata.Metadata, org.elasticsearch.repositories.RepositoryData)is executed, writing the metadata necessary to finalize the snapshot in the repository to the repository.
- After writing the final metadata to the repository, a cluster state update to remove the snapshot from the cluster state is
submitted and the removal of the snapshot's
SnapshotsInProgress.Entryfrom the cluster state completes the snapshot process.
Deleting a Snapshot
Deleting a snapshot can take the form of either simply deleting it from the repository or (if it has not completed yet) aborting it and subsequently deleting it from the repository.
Aborting a Snapshot
- Aborting a snapshot starts by updating the state of the snapshot's
- The snapshot's state change to
ABORTEDin cluster state is then picked up by the
SnapshotShardsServiceon all nodes. Those nodes that have shard snapshot actions for the snapshot assigned to them, will abort them and notify master about the shards snapshot status accordingly. If the shard snapshot action completed or was in state
FINALIZEwhen the abort was registered by the
SnapshotShardsService, then the shard's state will be reported to master as
SUCCESS. Otherwise, it will be reported as
- Once all the shards are reported to master as either
SnapshotsServiceon the master will finish the snapshot process as all shard's states are now completed and hence the snapshot can be completed as explained in point 4 of the snapshot creation section above.
Deleting a Snapshot from a Repository
- Assuming there are no entries in the cluster state's
SnapshotsInProgress, deleting a snapshot starts by the
SnapshotsServicecreating an entry for deleting the snapshot in the cluster state's
- Once the cluster state contains the deletion entry in
Repository.deleteSnapshots(java.util.Collection<org.elasticsearch.snapshots.SnapshotId>, long, org.elasticsearch.Version, org.elasticsearch.action.ActionListener<org.elasticsearch.repositories.RepositoryData>)for the given snapshot, which will remove files associated with the snapshot from the repository as well as update its meta-data to reflect the deletion of the snapshot.
- After the deletion of the snapshot's data from the repository finishes, the
SnapshotsServicewill submit a cluster state update to remove the deletion's entry in
SnapshotDeletionsInProgresswhich concludes the process of deleting a snapshot.
Cloning a Snapshot
Cloning part of a snapshot is a process executed entirely on the master node. On a high level, the process of cloning a snapshot is analogous to that of creating a snapshot from data in the cluster except that the source of data files is the snapshot repository instead of the data nodes. It begins with cloning all shards and then finalizes the cloned snapshot the same way a normal snapshot would be finalized. Concretely, it is executed as follows:
SnapshotsService.cloneSnapshot(org.elasticsearch.action.admin.cluster.snapshots.clone.CloneSnapshotRequest, org.elasticsearch.action.ActionListener<java.lang.Void>)is invoked which will place a placeholder entry into
SnapshotsInProgressthat does not yet contain any shard clone assignments. Note that unlike in the case of snapshot creation, the shard level clone tasks in
SnapshotsInProgress.Entry.shardsByRepoShardId()are not created in the initial cluster state update as is done for shard snapshot assignments in
SnapshotsInProgress.Entry.shards. This is due to the fact that shard snapshot assignments are computed purely from information in the current cluster state while shard clone assignments require information to be read from the repository, which is too slow of a process to be done inside a cluster state update. Loading this information ahead of creating a task in the cluster state, runs the risk of race conditions where the source snapshot is being deleted before the clone task is enqueued in the cluster state.
- Once a placeholder task for the clone operation is put into the cluster state, we must determine the number of shards in each
index that is to be cloned as well as ensure the health of the index snapshots in the source snapshot. In order to determine the
shard count for each index that is to be cloned, we load the index metadata for each such index using the repository's
Repository.getSnapshotIndexMetaData(org.elasticsearch.repositories.RepositoryData, org.elasticsearch.snapshots.SnapshotId, org.elasticsearch.repositories.IndexId)method. In order to ensure the health of the source index snapshots, we load the
SnapshotInfofor the source snapshot and check for shard snapshot failures of the relevant indices.
- Once all shard counts are known and the health of all source indices data has been verified, we populate the
SnapshotsInProgress.Entry#clonesmap for the clone operation with the the relevant shard clone tasks.
- After the clone tasks have been added to the
SnapshotsInProgress.Entry, master executes them on its snapshot thread-pool by invoking
Repository.cloneShardSnapshot(org.elasticsearch.snapshots.SnapshotId, org.elasticsearch.snapshots.SnapshotId, org.elasticsearch.repositories.RepositoryShardId, org.elasticsearch.repositories.ShardGeneration, org.elasticsearch.action.ActionListener<org.elasticsearch.repositories.ShardSnapshotResult>)for each shard that is to be cloned. Each completed shard snapshot triggers a call to the
SnapshotsService.SHARD_STATE_EXECUTORwhich updates the clone's
SnapshotsInProgress.Entryto mark the shard clone operation completed.
- Once all the entries in
SnapshotsInProgress.Entry#cloneshave completed, the clone is finalized just like any other snapshot through
SnapshotsService.endSnapshot(org.elasticsearch.cluster.SnapshotsInProgress.Entry, org.elasticsearch.cluster.metadata.Metadata, org.elasticsearch.repositories.RepositoryData). The only difference being that the metadata that is written out for indices and the global metadata are read from the source snapshot in the repository instead of the cluster state.
Concurrent Snapshot OperationsSnapshot create and delete operations may be started concurrently. Operations targeting different repositories run independently of each other. Multiple operations targeting the same repository are executed according to the following rules:
Concurrent Snapshot CreationIf multiple snapshot creation jobs are started at the same time, the data-node operations of multiple snapshots may run in parallel across different shards. If multiple snapshots want to snapshot a certain shard, then the shard snapshots for that shard will be executed one by one. This is enforced by the master node setting the shard's snapshot state to
SnapshotsInProgress.ShardSnapshotStatus.UNASSIGNED_QUEUEDfor all but one snapshot. The order of operations on a single shard is given by the order in which the snapshots were started. As soon as all shards for a given snapshot have finished, it will be finalized as explained above. Finalization will happen one snapshot at a time, working in the order in which snapshots had their shards completed.
Concurrent Snapshot DeletesA snapshot delete will be executed as soon as there are no more shard snapshots or snapshot finalizations executing running for a given repository. Before a delete is executed on the repository it will be set to state
SnapshotDeletionsInProgress.State.STARTED. If it cannot be executed when it is received it will be set to state
SnapshotDeletionsInProgress.State.WAITINGinitially. If a delete is received for a given repository while there is already an ongoing delete for the same repository, there are two possible scenarios: 1. If the delete is in state
META_DATA(i.e. already running on the repository) then the new delete will be added in state
WAITINGand will be executed after the current delete. The only exception here would be the case where the new delete covers the exact same snapshots as the already running delete. In this case no new delete operation is added and second delete request will simply wait for the existing delete to return. 2. If the existing delete is in state
WAITINGthen the existing
SnapshotDeletionsInProgress.Entryin the cluster state will be updated to cover both the snapshots in the existing delete as well as additional snapshots that may be found in the second delete request. In either of the above scenarios, in-progress snapshots will be aborted in the same cluster state update that adds a delete to the cluster state, if a delete applies to them. If a snapshot request is received while there already is a delete in the cluster state for the same repository, that snapshot will not start doing any shard snapshots until the delete has been executed.
ClassDescriptionThrown when a user tries to multiple conflicting snapshot/restore operations at the same time.Holds information about currently in-flight shard level snapshot or clone operations on a per-shard level.Thrown on the attempt to create a snapshot with invalid nameInformation about successfully completed restore operation.Service responsible for restoring snapshotsBasic information about a snapshot - a SnapshotId and the repository that the snapshot belongs to.Deprecated.This exception isn't thrown anymore.Generic snapshot exceptionSnapshotId - snapshot name + snapshot UUIDInformation about a snapshotThrown on the attempt to execute an action that requires that no snapshot is in progress.Thrown if requested snapshot doesn't existSnapshot restore exceptionStores information about failures that occurred during shard snapshotting processThis service runs on data nodes and controls currently running shard snapshots on these nodes.Service responsible for creating snapshots.Represents the state that a snapshot can be inSnapshot utilitiesInternal request that is used to send changes in snapshot status to master