Elasticsearch7.3.2 单点备份和还原(crul、es-head两种操作方式)

于 2019-10-28 17:46:02 发布
阅读量2.2k 收藏 6
点赞数
分类专栏： ElasticSearch
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/jiangbenchu/article/details/102783491
版权

系统版本：centos7
软件版本：Elasticsearch7.3.2

Elasticsearch提供了snapshot API 用作备份

方法一（crul）

注意：一定要用elasticsearch用户执行如下命令
流程：修改配置文件——>创建备份仓库——>开始备份索引到创建的仓库中——>恢复数据（如果存在恢复的索引需要关闭）

1、修改配置文件（开始）：

①修改Elasticsearch的配置文件 elasticsearch.yml 中增加设置：

vim /elasticsearch-7.3.2/config/elasticsearch.yml

修改内容如下：

path.repo: /home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup
2、创建备份仓库目录
curl -H "Content-Type: application/json" -X PUT http://IP地址:9200/_snapshot/esbackup -d'{
    "type": "fs", 
    "settings": {
        "location": "/home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup/esbakup"
    }
}'
3、备份（如果想等备份完成后返回结果需要添加wait_for_completion=true 参数；备份的名称：snapshot_20191028）
curl -H "Content-Type: application/json" -X PUT http://IP地址:9200/_snapshot/esbackup/snapshot_20191028?wait_for_completion=true
4、查看备份情况
curl -X GET "http://IP地址:9200/_snapshot/esbackup/_all?pretty"

[elasticsearch@test1 root]$ curl -X GET “http://IP地址:9200/_snapshot/esbackup/_all?pretty”
{
“snapshots” : [
{
“snapshot” : “snapshot_20191028”,
“uuid” : “ZofYODhERHeE4PefB_Q47Q”,
“version_id” : 7030299,
“version” : “7.3.2”,
“indices” : [
“a”,
“aaa”,
“table_2”
],
“include_global_state” : true,
“state” : “SUCCESS”,
“start_time” : “2019-10-28T07:23:06.076Z”,
“start_time_in_millis” : 1572247386076,
“end_time” : “2019-10-28T07:23:06.312Z”,
“end_time_in_millis” : 1572247386312,
“duration_in_millis” : 236,
“failures” : [ ],
“shards” : {
“total” : 11,
“failed” : 0,
“successful” : 11
}
}
]
}

可以看到备份的索引为 “a”,“aaa”, “table_2”

5、恢复数据（结束）

恢复数据=集群的快照ID 加上后面_restore即可，（?wait_for_completion=true回调提示是否成功）

curl -X POST http://1IP地址:9200/_snapshot/esbackup/snapshot_20191028/_restore?wait_for_completion=true

运行结果如下：显示已经恢复了相应的索引数据

[elasticsearch@test1 root]$ curl -X POST http://IP地址:9200/_snapshot/esbackup/snapshot_20191028/_restore?wait_for_completion=true
{“snapshot”:{“snapshot”:“snapshot_20191028”,“indices”:[“aaa”,“a”,“table_2”],“shards”:{“total”:11,“failed”:0,“successful”:11}}}[elasticsearch@test1 root]$

6、验证

[yeemiao@localhost esbak]$ curl -X GET ‘http://IP地址:9200/_cat/indices?v’
这里输出查看到跟原来的主机结果一致

[elasticsearch@test1 config]$ curl -X GET ‘http://IP地址:9200/_cat/indices?v’
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open aaa CvzBAfCbSPG9lQg8XrgC6Q 5 1 1 0 4.9kb 4.9kb
yellow open a qY3DAJGKSlmEyPQ3k-4STg 5 1 3 0 11.9kb 11.9kb
yellow open table_2 WlaimLOuRvevtqtwscAfuw 1 1 3 0 10.9kb 10.9kb
[elasticsearch@test1 config]$

以下仅供参考：

方法二（es-head）

1、创建备份仓库（根据自身系统配置文件系统选择即可）

使用备份API前，需要先创建仓库，有多个仓库类型以供选择：

  • 共享文件系统，比如 NAS
  • Amazon S3
  • HDFS (Hadoop 分布式文件系统)
  • Azure Cloud

创建仓库前：
①修改Elasticsearch的配置文件 elasticsearch.yml 中增加设置：

vim /elasticsearch-7.3.2/config/elasticsearch.yml

修改内容如下：

path.repo: /home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup

选择备份仓库的位置（ /home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup）

:wq保存后重启ES
②然后，调用 _snapshot api创建仓库，“fs”表示仓库类型,"location"为备份位置；

PUT http:IP地址:9200/_snapshot/my_backup 
{
    "type": "fs", 
    "settings": {
        "location": "/home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup/my_backup" 
    }
}

PUT _snapshot/my_backup #给我们的仓库取一个名字——快照名字，在本例它叫 my_backup 。
“type”: “fs”, #我们指定仓库的类型应该是一个共享文件系统。
“location”: “/mount/backups/my_backup” #挂载目录。

注：max_snapshot_bytes_per_sec 当快照数据进入仓库时，这个参数控制这个过程的限流情况。默认是每秒 20mb 。
max_restore_bytes_per_sec
当从仓库恢复数据时，这个参数控制什么时候恢复过程会被限流以保障你的网络不会被占满。默认是每秒 20mb
如果需要增加这些配置并自定义速度，可以使用POST

POST http:IP地址:9200/_snapshot/my_backup/  {
     "type": "fs",
     "settings": {
         "location": "/home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup/my_backup",
         "max_snapshot_bytes_per_sec" : "50mb", 
         "max_restore_bytes_per_sec" : "50mb"
     } }
 
 注意我们用的是 POST 而不是 PUT 。这会更新已有仓库的设置。
2、备份开始

备份所有打开的索引到leo_20191028中，调用后会立即返回结果，然后快照在后台运行，同时备份完成后，你可以在备份目录下看到相应文件。

PUT http:IP地址:9200/_snapshot/my_backup/leo_20191028

通常你会希望你的快照作为后台进程运行，不过有时候你会希望在你的脚本中一直等待到完成。这可以通过添加一个 wait_for_completion 标记实现：
这个会阻塞调用直到快照完成。注意大型快照会花很长时间才返回。

PUT _snapshot/my_backup/leo_20191028?wait_for_completion=true

也可以只备份其中几个索引：

PUT _snapshot/my_backup/leo_1
{
    "indices": "index_1,index_2"
}

还可以参加其他参数，如忽略不可以用的索引，不备份公共部分：

PUT _snapshot/my_backup/leo_2
{
    "ignore_unavailable": true,
	"include_global_state": false
}

查看某个快照时，可以使用

GET _snapshot/my_backup/leo_20191028

要获取一个仓库中所有快照的完整列表，使用 _all 占位符替换掉具体的快照名称：
使用“_all”是个通用的，比如关闭所有快照，打开所有快照，都可以使用。

GET _snapshot/my_backup/_all
#关闭所有快照
POST _all/_close
#打开所有快照
POST _all/_open
3、Elasticsearch 备份还原

恢复数据=集群的快照ID 加上后面_restore即可，
(注：默认是将快照中所有索引都恢复)

POST _snapshot / my_backup / snapshot_1 / _restore
POST http:IP地址:9200/_snapshot/my_backup/leo_20191028/_restore

恢复命令也可以加上wait_for_completion=true 参数

POST http:xxxx:9200/_snapshot/my_backup/leo_20191028/_restore?wait_for_completion=true
以下参考：如果需要恢复到其他库可以用到以下操作：

1、打包备份仓库

cd /home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup

以下路径为elasticsearch.yml所配置备份仓库的位置
path.repo: /home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup

tar -czvf esbakup20191028.tar ./esbakup

特别注意如下参数必须跟原来机器一致,因为我们等会将原来机器的备份文件加压到该目录

path.repo: /home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup

2、解压到需要恢复es数据的仓库位置

tar -xvf esbakup20191028.tar

3、执行恢复时需要创建备份指定目录

curl -H "Content-Type: application/json" -X PUT http://IP地址:9200/_snapshot/esbackup -d'{
    "type": "fs", 
    "settings": {
        "location": "/home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup/esbakup"
    }
}'

4、查看备份信息,这个时候备份信息已经注册进来了
curl -X GET “http://IP地址:9200/_snapshot/esbackup/_all?pretty”

5、执行恢复就?了

curl -X POST http://1IP地址:9200/_snapshot/esbackup/snapshot_20191028/_restore?wait_for_completion=true

6、验证

curl -X GET 'http://IP地址:9200/_cat/indices?v'

============================================================

关闭索引

curl -XPOST 'http://192.168.180.46:9200/schema_1/_close/' #（_open打开）

取消一个快照编辑

删除快照时，不建议直接删除备份文件，可以使用DELETE，这个会中断快照进程。然后删除仓库里进行到一半的快照。

DELETE _snapshot/my_backup/leo_1

用 API 删除快照很重要，而不能用其他机制（比如手动删除，或者用 S3 上的自动清除工具）。因为快照是增量的，有可能很多快照依赖于过去的段。delete API 知道哪些数据还在被更多近期快照使用，然后会只删除不再被使用的段。

但是，如果你做了一次人工文件删除，你将会面临备份严重损坏的风险，因为你在删除的是可能还在使用中的数据。

监控快照进度编辑

wait_for_completion 标记提供了一个监控的基础形式，但哪怕只是对一个中等规模的集群做快照恢复的时候，它都真的不够用。

另外两个 API 会给你有关快照状态更详细的信息。首先你可以给快照 ID 执行一个 GET，就像我们之前获取一个特定快照的信息时做的那样：

GET _snapshot/my_backup/snapshot_3

如果你调用这个命令的时候快照还在进行中，你会看到它什么时候开始，运行了多久等等信息。不过要注意，这个 API 用的是快照机制相同的线程池。如果你在快照非常大的分片，状态更新的间隔会很大，因为 API 在竞争相同的线程池资源。

更好的方案是拽取 _status API 数据：

GET _snapshot/my_backup/snapshot_3/_status

_status 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
         },
         "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
                     }
                  },
                  ...

①一个正在运行的快照会显示 IN_PROGRESS 作为状态。
②这个特定快照有一个分片还在传输（另外四个已经完成）。
响应包括快照的总体状况，但也包括下钻到每个索引和每个分片的统计值。这个给你展示了有关快照进展的非常详细的视图。分片可以在不同的完成状态：
INITIALIZING
分片在检查集群状态看看自己是否可以被快照。这个一般是非常快的。
STARTED
数据正在被传输到仓库。
FINALIZING
数据传输完成；分片现在在发送快照元数据。
DONE
快照完成！
FAILED
快照处理的时候碰到了错误，这个分片/索引/快照不可能完成了。检查你的日志获取更多信息。

参考：官方文档

乱蹦的小鱼干
关注
专栏目录
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值