数据备份
-
描述:
es引入仓库与快照的概念实现了数据的备份与恢复，在elasticsearch.yml中指定仓库的base目录,创建仓库，将快照创建在指定的仓房中即可实现索引的备份。
-
解决的问题:
- 备份指定的索引
- 备份全部索引
-
答疑
- 快照的过程可以后台进行
- 快照时会将保存该索引的全部数据
- 同一仓库下的同一快照只能执行一次。
- 本次快照会基于上次仓库之前的快照进行增量保存。
- 快照保存的内容：①索引数据②集群全局状态③。。。留待探索
- 同一时刻只允许一个快照执行。
-
执行步骤
- 在elasticsearch.yml 配置文件中配置仓库base目录
#以windows系统举例，路径格式依系统不同自行设置路径
path.repo: ["D:\\program\\elasticsearch-5.1.1\\data\\back"]
- 创建仓库
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: 数据是否压缩
- 快照所有打开的索引
#发送完请求会立即响应，快照会在后台进行
PUT _snapshot/my_backup_1/snapshot_1
# 指定wait_for_completion=true时会一直阻塞直到快照完成。
PUT _snapshot/my_backup_1/snapshot_1?wait_for_completion=true
- 快照指定索引
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
