要备份你的集群,你可以使用 snapshot
API。这个会拿到你集群里当前的状态和数据然后保存到一个共享仓库里。这个备份过程是"智能"的。你的第一个快照会是一个数据的完整拷贝,但是所有后续的快照会保留的是已存快照和新数据之间的差异。随着你不时的对数据进行快照,备份也在增量的添加和删除。这意味着后续备份会相当快速,因为它们只传输很小的数据量。
要使用这个功能,你必须首先创建一个保存数据的仓库:仓库类型有:
- 共享文件系统,比如 NAS
- Amazon S3
- HDFS
- Azure Cloud
一、添加仓库路径
在 elasticsearch 的配置文件 elasticsearch.yml 文件中添加 仓库路径的配置:
path.repo: /es_data/back // 这个路径必须确保集群所有节点都可以访问到
二、创建仓库
curl -XPUT http://localhost:9200/_snapshot/repertoryName -d '{
"type": "fs",
"settings":{
"location":"./5.5.1/back_up",
"compress": true
}
}'
参数解释:
repertoryName: 给仓库取得名字
location:仓库的地址(path.reop + location),共享文件系统路径必须确保集群所有节点都可以访问到
compress:是否压缩
其他参数解释:(若是添加下面两个参数,需要使用POST方式提交数据)
max_snapshot_bytes_per_sec:当快照数据进入仓库时,这个参数控制这个过程的限流情况。默认是每秒 20mb
max_restore_bytes_per_sec:当从仓库恢复数据时,这个参数控制什么时候恢复过程会被限流以保障你的网络不会被占满。默认是每秒 20mb
三、创建快照
curl -XPOST http://localhost:9200/_snapshot/repertoryName/snapshotname -d '{
"indices": "sw_standard_index,sw_lenovo_index",
"ignore_unavailable": "true",
"include_global_state": false,
"partial": "false"
}'
参数解释:
repertoryName:仓库名称
snapshotname:快照名称(快照名称必须是小写)
indices:表示创建哪些索引的快照,空表示所有
ignore_unavailable:忽略不存在的索引(不设置会快照请求会失败)
include_global_state:防止集群的全局状态被作为快照的一部分储存起来
partial:默认情况下,如果快照红的1个或多个索引不是全部分片都可用会导致整个请求过程失败,将其设置为 true 可以改变此行为
说明:
通常你会希望你的快照作为后台进程运行,不过有时候你会希望在你的脚本中一直等待到完成。这可以通过添加一个 wait_for_completion 标记实现:
curl -XPUT http://localhost:9200/_snapshot/repertoryName/snapshotName?wait_for_completion=true
四、从快照中恢复数据
一旦你备份过了数据,恢复它就简单了:只要在你希望恢复回集群的快照 ID 后面加上 _restore
即可:
curl -XPOST http://localhost:9200/_snapshot/repertoryName/snapshotname/_restore -d '{
"indices": "sw_standard_index,sw_lenovo_index",
"ignore_unavailable": "true",
"include_global_state": false,
"rename_pattern": "index_(.+)",
"rename_replacement": "restored_index_$1"
}'
参数说明:
repertoryName:仓库名称
snapshotname:快照名称
indices:需要恢复快照snapshotName下哪些索引,控表示所有索引
ignore_unavailable:忽略不存在的索引(不设置会快照请求会失败)
include_global_state:防止集群的全局状态被作为快照的一部分储存起来
rename_pattern:查找所提供的模式能匹配上的正在恢复的索引
rename_replacement:然后把它们重命名成替代的模式
说明:
和快照类似, restore 命令也会立刻返回,恢复进程会在后台进行。如果你更希望你的 HTTP 调用阻塞直到恢复完成,添加 wait_for_completion 标记:
curl -XPOST http://localhost:9200/_snapshot/repertoryName/snapshotname/_restore?wait_for_completion=true
其他相关操作说明:
五、查看仓库信息
查看所有仓库信息:curl -XGET http://localhost:9200/_snapshot/_all
查看某一个仓库信息:curl -XGET http://localhost:9200/_snapshot/repertoryname
结果:
{
"repertoryName": { //仓库名
"type": "fs", // 以快照的方式存储文件
"settings": {
"compress": "true", // 是否压缩文件
"location": "./back_up" //仓库地址
}
}
}
六、查看快照信息
查看仓库repertoryName下所有快照的信息:curl -XGET http://localhost:9200/_snapshot/repertoryname/_all
查看名为snapshotName快照的信息:curl -XGET http://localhost:9200/_snapshot/repertoryName/snapshotname
结果:
{
"snapshots": [
{
"snapshot": "snapshot_1",
"uuid": "JVHioWbISF6KH2CS6eHglg",
"version_id": 5050199,
"version": "5.5.1",
"indices": [
"sw_lenovo_index",
"sw_standard_index"
],
"state": "SUCCESS",
"start_time": "2018-11-09T06:50:32.298Z",
"start_time_in_millis": 1541746232298,
"end_time": "2018-11-09T06:50:33.140Z",
"end_time_in_millis": 1541746233140,
"duration_in_millis": 842,
"failures": [],
"shards": {
"total": 8,
"failed": 0,
"successful": 8
}
}
]
}
七、删除快照
用 API 删除快照很重要,而不能用其他机制(比如手动删除,或者用 S3 上的自动清除工具)。因为快照是增量的,有可能很多快照依赖于过去的段。delete
API 知道哪些数据还在被更多近期快照使用,然后会只删除不再被使用的段。最后可能会面临数据严重损坏的风险。
curl -XDELETE http://localhost:9200/_snapshot/repertoryName/snapshotname
repertoryName:仓库名称
snapshotName:快照名称
curl -XDELETE http://localhost:9200/_snapshot/repertoryname 删除仓库
八、快照进度监控
wait_for_completion
标记提供了一个监控的基础形式,但哪怕只是对一个中等规模的集群做快照恢复的时候,它都真的不够用。
curl -XGET http://localhost:9200/_snapshot/repertoryName/snapshotname/_status
结果:
{
"snapshots": [
{
"snapshot": "snapshotname", // 快照名称
"repository": "repertoryName", // 仓库名称
"state": "IN_PROGRESS", // IN_PROGRESS表示正在运行中
"shards_stats": {
"initializing": 0, // 表示分片在检查集群状态看看自己是否可以被快照
"started": 1, // 表示数据正在被传输到仓库
"finalizing": 0, // 数据传输完成;分片现在在发送快照元数据
"done": 4, // 表示4个分片已完成
"failed": 0, // 表示失败数
"total": 5 // 表示总共5个分片
},
"stats": {
"number_of_files": 5,
"processed_files": 5,
"total_size_in_bytes": 1792,
"processed_size_in_bytes": 1792,
"start_time_in_millis": 1409663054859,
"time_in_millis": 64
},
"indices": {
"index_3": {
"shards_stats": {
"initializing": 0,
"started": 0,
"finalizing": 0,
"done": 5,
"failed": 0,
"total": 5
},
"stats": {
"number_of_files": 5,
"processed_files": 5,
"total_size_in_bytes": 1792,
"processed_size_in_bytes": 1792,
"start_time_in_millis": 1409663054859,
"time_in_millis": 64
},
"shards": {
"0": {
"stage": "DONE",
"stats": {
"number_of_files": 1,
"processed_files": 1,
"total_size_in_bytes": 514,
"processed_size_in_bytes": 514,
"start_time_in_millis": 1409663054862,
"time_in_millis": 22
}
},
...
九、快照恢复进度监控
恢复的指定索引单独调用: curl -XGET http://localhost:9200/<index>/_recovery
查看集群里所有索引,可能包括跟你的恢复进程无关的其他分片移动: curl -XGET http://localhost:9200/_recovery
结果:
{
"sw_standard_index": { // 索引名称
"shards": [
{
"id": 3,
"type": "EXISTING_STORE", // 恢复的本子
"stage": "DONE", // 恢复的状态
"primary": true,
"start_time_in_millis": 1541733069072,
"stop_time_in_millis": 1541733069206,
"total_time_in_millis": 123,
"source": {},
"target": {
"id": "bRdT-iSkTD6T0HpQn2rOzw",
"host": "10.10.38.139",
"transport_address": "10.10.38.139:9300",
"ip": "10.10.38.139",
"name": "bRdT-iS"
},
"index": {
"size": {
"total_in_bytes": 42514,
"reused_in_bytes": 42514,
"recovered_in_bytes": 0,
"percent": "100.0%" // 完成了多少
},
"files": {
"total": 7,
"reused": 7,
"recovered": 0,
"percent": "100.0%"
},
"total_time_in_millis": 2,
"source_throttle_time_in_millis": 0,
"target_throttle_time_in_millis": 0
},
"translog": {
"recovered": 0,
"total": 0,
"percent": "100.0%",
"total_on_start": 0,
"total_time_in_millis": 100
},
"verify_index": {
"check_index_time_in_millis": 0,
"total_time_in_millis": 0
}
},
...
参考:https://www.elastic.co/guide/cn/elasticsearch/guide/current/backing-up-your-cluster.html