Docs: Add information about restoring to a different cluster

This commit is contained in:
Igor Motov 2015-05-12 20:59:24 -04:00
parent 79023c1e61
commit d6efe1e508

View File

@ -248,13 +248,14 @@ $ curl -XPOST "localhost:9200/_snapshot/my_backup/snapshot_1/_restore" -d '{
-----------------------------------
The restore operation can be performed on a functioning cluster. However, an existing index can be only restored if it's
<<indices-open-close,closed>>. The restore operation automatically opens restored indices if they were closed and creates new indices if they
<<indices-open-close,closed>> and has the same number of shards as the index in the snapshot.
The restore operation automatically opens restored indices if they were closed and creates new indices if they
didn't exist in the cluster. If cluster state is restored, the restored templates that don't currently exist in the
cluster are added and existing templates with the same name are replaced by the restored templates. The restored
persistent settings are added to the existing persistent settings.
[float]
=== Partial restore
==== Partial restore
By default, the entire restore operation will fail if one or more indices participating in the operation don't have
snapshots of all shards available. It can occur if some shards failed to snapshot for example. It is still possible to
@ -263,7 +264,7 @@ restored in this case and all missing shards will be recreated empty.
[float]
=== Changing index settings during restore
==== Changing index settings during restore
Most of index settings can be overridden during the restore process. For example, the following command will restore
the index `index_1` without creating any replicas while switching back to default refresh interval:
@ -279,6 +280,29 @@ $ curl -XPOST "localhost:9200/_snapshot/my_backup/snapshot_1/_restore" -d '{
}'
-----------------------------------
Please note, that some settings such as `index.number_of_shards` cannot be changed during restore operation.
[float]
==== Restoring to a different cluster
The information stored in a snapshot is not tied to a particular cluster or a cluster name. Therefore it's possible to
restore a snapshot made from one cluster into another cluster. All that is required is registering the repository
containing the snapshot in the new cluster and starting the restore process. The new cluster doesn't have to have the
same size or topology. However, the version of the new cluster should be the same or newer than the cluster that was
used to create the snapshot.
If the new cluster has a smaller size additional considerations should be made. First of all it's necessary to make sure
that new cluster have enough capacity to store all indices in the snapshot. It's possible to change indices settings
during restore to reduce the number of replicas, which can help with restoring snapshots into smaller cluster. It's also
possible to select only subset of the indices using the `indices` parameter. Prior to version 1.5.0 elasticsearch
didn't check restored persistent settings making it possible to accidentally restore an incompatible
`discovery.zen.minimum_master_nodes` setting, and as a result disable a smaller cluster until the required number of
master eligible nodes is added. Starting with version 1.5.0 incompatible settings are ignored.
If indices in the original cluster were assigned to particular nodes using
<<shard-allocation-filtering,shard allocation filtering>>, the same rules will be enforced in the new cluster. Therefore
if the new cluster doesn't contain nodes with appropriate attributes that a restored index can be allocated on, such
index will not be successfully restored unless these index allocation settings are changed during restore operation.
[float]
=== Snapshot status