# cat recovery

原文链接 : [https://www.elastic.co/guide/en/elasticsearch/reference/5.0/cat-recovery.html](https://www.elastic.co/guide/en/elasticsearch/reference/5.0/cat-recovery.html)

译文链接 : [http://www.apache.wiki/display/Elasticsearch/cat+recovery](http://www.apache.wiki/display/Elasticsearch/cat+recovery)

贡献者 : [那伊抹微笑](/display/~wangyangting)

**recovery** 命令是一个索引分片恢复的视图，包括恢复中的和先前已完成的。它是一个更紧凑的 **JSON **[recovery](https://www.elastic.co/guide/en/elasticsearch/reference/5.0/indices-recovery.html) **API** 的视图。

恢复事件可以发生任何时候。在集群中一个索引的分片移动到另一个节点时的，快照恢复时，副本级别改变时，故障发生时，或者节点重启。其中最后面的类型称为本地存储类型，并且在节点启动时从硬盘加载分片的方式是正常的。

例如，在没有分片从一个节点传输到另一个节点时，下面看起来像是一个集群状态的恢复 : 

```
> curl -XGET 'localhost:9200/_cat/recovery?v'
index shard time type  stage source_host  source_node target_host target_node repository snapshot files files_percent bytes bytes_percent
 total_files total_bytes translog translog_percent total_translog
index 0     87ms store done  127.0.0.1        I8hydUG      127.0.0.1        I8hydUG      n/a        n/a      0     0.0%          0     0.0%          0           0           0        100.0%           0
index 1     97ms store done  127.0.0.1        I8hydUG      127.0.0.1        I8hydUG      n/a        n/a      0     0.0%          0     0.0%          0           0           0        100.0%           0
index 2     93ms store done  127.0.0.1        I8hydUG      127.0.0.1        I8hydUG      n/a        n/a      0     0.0%          0     0.0%          0           0           0        100.0%           0
index 3     90ms store done  127.0.0.1        I8hydUG      127.0.0.1        I8hydUG      n/a        n/a      0     0.0%          0     0.0%          0           0           0        100.0%           0
index 4     9ms  store done  127.0.0.1        I8hydUG      127.0.0.1        I8hydUG      n/a        n/a      0     0.0%          0     0.0%          0           0           0        100.0%           0
```

在上面的情况中，**source**（源）和 **target** **node**（目标节点）都是一样的，因为恢复的类型是 **store**（存储）。

例如，在节点启动时它们将从本地硬盘读取数据。

现在让我们看一下集群恢复中的模样。通过增加索引的副本数量，引起另一个节点上线到副本的主机中，我们可以看到现在的恢复是这样的 : 

```
> curl -XPUT 'localhost:9200/wiki/_settings' -d'{"number_of_replicas":1}'
{"acknowledged":true}

> curl -XGET 'localhost:9200/_cat/recovery?v&h=i,s,t,ty,st,shost,thost,f,fp,b,bp'
i     s t      ty      st    shost  thost  f     fp      b        bp
wiki  0 1252ms store   done  hostA  hostA  4     100.0%  23638870 100.0%
wiki  0 1672ms replica index hostA  hostB  4     75.0%   23638870 48.8%
wiki  1 1698ms replica index hostA  hostB  4     75.0%   23348540 49.4%
wiki  1 4812ms store   done  hostA  hostA  33    100.0%  24501912 100.0%
wiki  2 1689ms replica index hostA  hostB  4     75.0%   28681851 40.2%
wiki  2 5317ms store   done  hostA  hostA  36    100.0%  30267222 100.0%
```

在上面的列表中我们可以看到，在不同的阶段中 **3** 个初始化的分片从一个节点复制到另一个节点。注意，恢复类型显示为 **replcia**。该文件和字节被复制，并且实时测量。

最后， 让我们看一下快照恢复的情况。假设我先前对我的索引做了一个备份，我可以使用 [snapshot and restore](https://www.elastic.co/guide/en/elasticsearch/reference/5.0/modules-snapshots.html "Snapshot And Restore")来恢复它。

```
> curl -XPOST 'localhost:9200/_snapshot/imdb/snapshot_2/_restore'
{"acknowledged":true}
> curl -XGET 'localhost:9200/_cat/recovery?v&h=i,s,t,ty,st,rep,snap,f,fp,b,bp'
i     s t      ty       st    rep        snap     f     fp      b     bp
imdb  0 1978ms snapshot done  imdb       snap_1   79    8.0%    12086 9.0%
imdb  1 2790ms snapshot index imdb       snap_1   88    7.7%    11025 8.1%
imdb  2 2790ms snapshot index imdb       snap_1   85    0.0%    12072 0.0%
imdb  3 2796ms snapshot index imdb       snap_1   85    2.4%    12048 7.2%
imdb  4  819ms snapshot init  imdb       snap_1   0     0.0%    0     0.0%
```