数据备份

---

• 描述:

es引入仓库与快照的概念实现了数据的备份与恢复，在elasticsearch.yml中指定仓库的base目录,创建仓库，将快照创建在指定的仓房中即可实现索引的备份。

• 解决的问题:

1. 备份指定的索引
2. 备份全部索引

• 答疑

1. 快照的过程可以后台进行
2. 快照时会将保存该索引的全部数据
3. 同一仓库下的同一快照只能执行一次。
4. 本次快照会基于上次仓库之前的快照进行增量保存。
5. 快照保存的内容：①索引数据②集群全局状态③。。。留待探索
6. 同一时刻只允许一个快照执行。

• 执行步骤

1. 在elasticsearch.yml 配置文件中配置仓库base目录

#以windows系统举例，路径格式依系统不同自行设置路径
path.repo: ["D:\\program\\elasticsearch-5.1.1\\data\\back"]

2. 创建仓库

POST _snapshot/my_backup_1
{
  "type": "fs",
  "settings": {
    "location": "D:\\program\\elasticsearch-5.1.1\\data\\back\\my_backup_1",
    "max_snapshot_bytes_per_sec": "20mb",
    "max_restore_bytes_per_sec": "20mb",
    "compress": true
  }
}

配置解释:
注意请求方式：POST请求会更新已有的仓库配置,PUT会重新创建该仓库。
type：仓库的类型为共享文件系统
location: 指定仓库的路径，必须为path.repo 的子目录
max_snapshot_bytes_per_sec:快照数据进入仓库时,该参数可以控制过程的限流情况,默认为每秒20M
max_restore_bytes_per_sec:从仓库恢复数据时,该参数控制过程限流情况，默认值：每秒20M
注意：如果挂在的路径为远程目录时，应该合理配置该值，不至于网络流量被占满。
compress: 数据是否压缩

3. 快照所有打开的索引

#发送完请求会立即响应，快照会在后台进行
PUT _snapshot/my_backup_1/snapshot_1
# 指定wait_for_completion=true时会一直阻塞直到快照完成。
PUT _snapshot/my_backup_1/snapshot_1?wait_for_completion=true

4. 快照指定索引

PUT _snapshot/my_backup_1/snapshot_3
{
  "indices": "my_index_1,my_index_2",
  "ignore_unavailable": true,
 "include_global_state": true
}

配置解释：
indices:指定索引备份
ignore_unavailable: 如果indices指定的某些索引不存在时，是否忽略，默认为true 忽略不存在的索引。
include_global_state:是否阻止集群全局状态保存为快照的一部分。

至此备份操作完成...............................

快照中恢复

---

• 从快照中恢复

#异步调用
POST _snapshot/my_backup/snapshot_1/_restore
#同步阻塞
POST _snapshot/my_backup/snapshot_1/_restore?wait_for_completion=true

将快照中的索引数据全部恢复
注意：如果已经存在相关索引必须先将索引关闭
POST index_name/_close
再将索引打开
POST index_name/_open

• 恢复指定索引并重命名索引

POST _snapshot/my_backup/snapshot_2/_restore
{
  "indices": "my_index_1,my_index_2",
  "rename_pattern": "my_index_(.+)",
  "rename_replacement": "restored_my_index_$1"
} 

备份相关其余API

---

• 获取快照的信息

#获取单个快照的信息
GET _snapshot/my_backup/snapshot_1
#获取仓库下所有快照的信息
GET _snapshot/my_backup/_all

• 删除某个快照

DELETE _snapshot/my_backup/snapshot_2

• 监控快照进度

GET _snapshot/my_backup/snapshot_1
GET _snapshot/my_backup/snapshot_1/_status

这两个API均可以监控某个快照进度
区别:
第2个API提供更加详细的监控信息
第一个API用的是快照机制相同的线程池,当快照非常大的分片时，状态更新间隔会很大，因为API在竞争线程池资源，而第二个API会在单独的线程池中运行。
综合考虑监控快照API使用 第二个API
返回结果

{
   "snapshots": [
      {
         "snapshot": "snapshot_3",
         "repository": "my_backup",
         "state": "IN_PROGRESS", 
         "shards_stats": {
            "initializing": 0,
            "started": 1, 
            "finalizing": 0,
            "done": 4,
            "failed": 0,
            "total": 5
         },
      ........
  ]
}

• 取消快照

#执行简单的删除即可，将会停止快照的执行并删除
DELETE _snapshot/my_backup/snapshot_2