基于BOS的快照与恢复
所有文档

          Elasticsearch BES

          基于BOS的快照与恢复

          介绍如何用百度智能云Elasticsearch创建快照与恢复,如何将您的数据快照至百度对象存储BOS(Baidu Object Storage)中。快照和备份的概念基本上是一致的,快照更强调point-in-time即强调某一时刻。

          创建快照

          主要包括两个步骤

          • 创建基于BOS的仓库
          • 创建数据的快照

          创建基于BOS的仓库

          • 创建仓库前的准备,需要在您的BOS中创建相应的bucket,并保证创建快照的用户具有相应的权限,这里的用户是用百度智能云的access_key、secrect_key来标识的,bucket的存储类型您可以根据您的需求选择,推荐选用标准存储
          • BOS对应的bucket您应该保证和您的Elasticsearch集群在同一个region中
          • es_repo为您设置的仓库名字,您可以根据您自己的业务需求起不同的名字
          PUT /_snapshot/es_repo
          {
              "type": "bos",
              "settings": {
                  "access_key": "your access_key",
                  "secret_key": "your secret_key",
                  "endpoint": "s3.bj.bcebos.com",
                  "bucket": "es-repo",
                  "base_path": ""
              }
          }

          相关参数意义:

          参数 作用
          type 仓库的类型,在这里您应该填bos
          access_key 百度智能云的access_key,可以在百度智能云的console中看到
          secret_key 百度智能云的secret_key,可以在百度智能云的console中看到
          endpoint BOS对应各个region的服务域名
          bucket BOS的bucket,务必保证对应的用户身份有读写bucket权限
          base_path 仓库的起始位置,默认为根目录
          chunk_size 大文件将会被拆分成多个part,默认1G,最小5M,最大5T
          max_restore_bytes_per_sec 每个节点快照的最大速度,默认40mb/s
          max_snapshot_bytes_per_sec 每个节点恢复的最大速度,默认40mb/s

          BOS对应各个region的服务域名

          区域 访问Endpoint
          BJ s3.bj.bcebos.com
          GZ s3.gz.bcebos.com
          SU s3.su.bcebos.com

          创建完仓库后,您如果需要修改对应的参数,使用POST方法,假如我们上传的数据非常大,我们可以限制snapshot过程中分块的大小,超过这个大小,数据将会被分块上传到BOS中。

          POST /_snapshot/es_repo
          {
              "type": "bos",
              "settings": {
                  "access_key": "your access_key",
                  "secret_key": "your secret_key",
                  "endpoint": "s3.bj.bcebos.com",
                  "bucket": "es-repo",
                  "chunk_size": "1g",
                  "base_path": ""
              }
          }

          列出所有仓库信息

          GET /_snapshot

          查看具体仓库的信息

          GET /_snapshot/{您设置的仓库名}

          快照(snpashot)

          一个仓库可以包含多个快照,每个快照都是一系列索引的集合,可以是单个索引,一部分索引,所有索引。当创建快照的时候,您可以指定您需要快照的索引,再不指定的情况下将快照集群所有打开着的索引,您需要给快照取一个唯一的名字,这个名字最好有一定的意义如snapshot_2018_07_01表示2018年7月1日的一个快照,这样您恢复的时候可以根据您对数据的要求进行恢复。

          发起一次快照:

          PUT /_snapshot/es_repo/snapshot_2018_07_01?wait_for_completion=false

          这个请求会将集群中所有打开的索引快照到es_repo仓库下,并将这次快照命名为`snapshot_2018_07_01`,这个请求将会在snapshot初始化完成后会立即返回,快照过程将在您的集群后台运行。

          wait_for_completion参数用来告诉请求是否在snapshot初始化完成后或snapshot完成后返回,默认为false即snpashot初始化完成后即返回;设置为true则是在完成备份快照后才会返回结果,这可能需要很长时间,一般不建议设置为true

          在snapshot初始化的时候,关于之前所有的snapshots的信息都会被加载到内存中,这就意味着即使wait_for_completion设置为false,面对非常大的仓库可能需要花费数秒更甚至数分钟。

          默认情况下,集群中所有打开的(open)开始的(started)的索引都会被创建snapshot,可以通过在快照请求中指定那些索引被快照:

          PUT /_snapshot/es_repo/snapshot_2018_07_01
          {
             "indices": "index1,index2",
             "ignore_unavailable": true,
             "include_global_state": false
          }
          参数 作用
          indices 需要被包含在snapshot中的index列表,支持`multi index syntax`
          ignore_unavailable 设置为true时,忽略indices中不存在的index.默认情况下没有设置,如果index,不存在会报错
          include_global_state 设置为false时,阻止cluster global state被snapshot

          cluster global state是指Elasticsearch维护的集群全局元数据信息,具体解释可参考:https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-state.html。

          snapshot有以下几个特性:

          • snapshot是增量的,一个snapshot代表的是index的point-in-time 视图(从snapshot创建开始,开始后添加的records不在这个snapshot中不可见)
          • 除了创建这个index所有主分片(primary)的snapshot,snapshot还可以快照 global cluster metadata(包括持久化的cluster setting和templates等)
          • 对于集群而言,任意时刻只能有一个snapshot在进行,所有的快照请求都必须在上一个快照完成后才能被执行,否则会被直接拒绝

          查询快照

          一旦一个snapshot被创建,关于这次snapshot的信息可以通过直接对仓库和快照名字发起一次GET请求,获得特定的快照信息。

          基本格式: GET /_snapshot/{your_repo_name}/{your_snapshot_name},具体如下:

          GET /_snapshot/es_repo/snapshot_2018_07_01

          返回的响应中包含了快照相关的所有信息:

          {
             "snapshots": [
                {
                   "snapshot": "snapshot_2018_07_19",
                   "uuid": "TWKo55e7TSy1Sq4WLxMVrQ",
                   "version_id": 5050099,
                   "version": "5.5.0",
                   "indices": [
                      "snapindex"
                   ],
                   "state": "SUCCESS",
                   "start_time": "2018-07-19T10:53:17.543Z",
                   "start_time_in_millis": 1531997597543,
                   "end_time": "2018-07-19T10:53:21.795Z",
                   "end_time_in_millis": 1531997601795,
                   "duration_in_millis": 4252,
                   "failures": [],
                   "shards": {
                      "total": 1,
                      "failed": 0,
                      "successful": 1
                   }
                }
             ]
          }

          可以同时获得多个快照的信息,GET请求支持通配符方式匹配多个快照信息,这时候快照的名字代表的意义就起了作用如:

          GET /_snapshot/es_repo/snapshot_order_*

          可以使用_all参数获取一个仓库中所有快照的完整列表信息:

          GET /_snapshot/es_repo/_all

          停止或删除快照

          百度智能云提供的Elasticsearch服务没有单独的停止快照API,停止快照和删除快照是一个语义,如果发现snapshot执行有错误或耗时非常长,可以通过删除这个snapshot来停止后台运行的snapshot:

          DELETE /_snapshot/es_repo/snapshot_2018_07_01

          从仓库中删除:

          DELETE /_snapshot/es_repo/snapshot_2018_07_01

          一个仓库亦可以直接被删除:

          DELETE /_snapshot/es_repo

          注意:删除一个snapshot或删除一个仓库,ES只是删除了集群对仓库或snapshot的位置引用,真实的物理文件等是需要用户自己处理的,当确定所有的快照都不再适用的时候,可以先在Elasticsearch中删除仓库的元数据,然后登录百度智能云BOS控制台手动直接删除仓库,另外不要手动去BOS仓库中删除任何快照文件,手动删除一个快照文件后,将会导致快照处于不可用的状态,恢复的时候会出现不可挽回的损失

          查看快照进度

          可以通过status接口查看一个快照的进度信息:

          GET /_snapshot/es_repo/snapshot_2018_07_19/_status

          下面是status接口返回的详细统计信息:

          {
             "snapshots": [
                {
                   "snapshot": "snapshot_2018_07_19",
                   "repository": "es_repo",
                   "uuid": "TWKo55e7TSy1Sq4WLxMVrQ",
                   "state": "SUCCESS",  ..................  [A]
                   "shards_stats": {
                      "initializing": 0,
                      "started": 0,
                      "finalizing": 0,
                      "done": 1,
                      "failed": 0,
                      "total": 1
                   },
                   "stats": {
                      "number_of_files": 16,
                      "processed_files": 16,
                      "total_size_in_bytes": 18639,
                      "processed_size_in_bytes": 18639,
                      "start_time_in_millis": 1531997598051,
                      "time_in_millis": 2782
                   },
                   "indices": {
                      "snapindex": {
                         "shards_stats": {
                            "initializing": 0,
                            "started": 0,
                            "finalizing": 0,
                            "done": 1,  ..................... [B]
                            "failed": 0,
                            "total": 1
                         },
                         "stats": {
                            "number_of_files": 16,
                            "processed_files": 16,
                            "total_size_in_bytes": 18639,
                            "processed_size_in_bytes": 18639,
                            "start_time_in_millis": 1531997598051,
                            "time_in_millis": 2782
                         },
                         "shards": {
                            "0": {
                               "stage": "DONE",............... [C]
                               "stats": {
                                  "number_of_files": 16,
                                  "processed_files": 16,
                                  "total_size_in_bytes": 18639,
                                  "processed_size_in_bytes": 18639,
                                  "start_time_in_millis": 1531997598051,
                                  "time_in_millis": 2782
                               }
                            }
                         }
                      }
                   }
                }
             ]
          }

          相应中包括快照的所有信息例如快照的开始时间、总大小、文件总数和已经处理完的文件总数等,详细记录了被快照的所有的index的当前状态以及index下的所有shard的状态等。

          • [A]表示这个快照已经成功完成,显示SUCCESS状态,正在运行的快照会显示IN_PROGRESS
          • [B]表示这个index的所有分片(shard)完成快照
          • [C]表示这个index对应的分片(shard)完成快照

          不同的状态值表征不同的含义:

          状态值 意义
          INIT 快照还没有开始,正在做初始化工作
          STARTED 快照正在拷贝index文件
          FINALIZE 快照的元数据正在写入远端仓库
          DONE 快照成功完成
          FAILURE 快照失败,失败的原因都可以在statusAPI中看到

          恢复快照

          一个快照可以通过下面的命令被恢复(restore):

          POST /_snapshot/es_repo/snapshot_2018_07_19/_restore

          缺省情况下,指定快照中所有的index都会被恢复,可以通过在请求体中添加indicesinclude_global_state来指定特定的indexglobal cluster state:

          POST /_snapshot/es_repo/snapshot_2018_07_19/_restore
          {
            "indices": "snapindex",
            "ignore_unavailable": true,
            "include_global_state": true,
            "rename_pattern": "snap(.+)",
            "rename_replacement": "restore$1"
          }

          rename_patternrename_replacement可以用来对index重新命名,大多数的index的设置可以被重新设置,如下:

          POST /_snapshot/repo/snapshot_wyf_2018_01_29/_restore
          {
            "indices": "wyf",
            "index_settings": {
              "index.number_of_replicas": 0
            },
            "ignore_index_settings": [
              "index.refresh_interval"
            ]
          }

          需要注意的是:一些设置如index.number_of_shards是不可以在restore的时候重新设置的 可以resore到另外一个集群,新的cluster的version必须和做snapshot的集群一样或者更大(仅仅只能大1个major version).例如你可以resotre一个1.x的snapshot到2.x,但是不能到5.x。

          和快照一样,restore请求在检查完快照信息和验证快照中的index信息后立即返回,恢复将在集群后台执行,可以在请求后面追加wait_for_completion参数阻塞请求之道恢复完成:

          POST /_snapshot/es_repo/snapshot_2018_07_19/_restore?wait_for_completion=true

          监控快照的恢复

          从BOS仓库恢复数据利用了Elasticsearch内部的恢复机制,从内部实现原理来讲,从仓库恢复数据和一个节点从另一个节点上恢复数据是完全等价,Elasticsearch的内部恢复包括原地恢复(existing_store recovery)、远端恢复(peer recovery)和仓库恢复(snapshot recovery)。

          恢复进度可以通过recoveryAPI来查看:

          GET /{index}/_recovery
          
          GET snapindex/_recovery

          这个接口返回的响应如下:

          {
             "snapindex": {
                "shards": [
                   {
                      "id": 0,
                      "type": "SNAPSHOT", ........................ [A]
                      "stage": "DONE", ........................... [B]
                      "primary": true,
                      "start_time_in_millis": 1532065843418,
                      "stop_time_in_millis": 1532065845773,
                      "total_time_in_millis": 2354,
                      "source": { ................................ [C]
                         "repository": "es_repo",
                         "snapshot": "snapshot_2018_07_19",
                         "version": "5.5.0",
                         "index": "snapindex"
                      },
                      "target": {
                         "id": "8wR8Z38USImEeSO0SZ1_hA",
                         "host": "192.168.16.5",
                         "transport_address": "192.168.16.5:9300",
                         "ip": "192.168.16.5",
                         "name": "8wR8Z38"
                      },
                      "index": {
                         "size": {
                            "total_in_bytes": 18668,
                            "reused_in_bytes": 0,
                            "recovered_in_bytes": 18668,
                            "percent": "100.0%" .................. [D]
                         },
                         "files": {
                            "total": 16,
                            "reused": 0,
                            "recovered": 16,
                            "percent": "100.0%"
                         },
                         "total_time_in_millis": 2148,
                         "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": 158
                      },
                      "verify_index": {
                         "check_index_time_in_millis": 0,
                         "total_time_in_millis": 0
                      }
                   }
                ]
             }
          }
          • [A] type表示是从远端仓库快照中进行恢复
          • [B] stage字段表示这个恢复已经完成
          • [C] source字段表示这个恢复已经完成
          • [D] percent字段表示恢复完成的百分比

          取消正在进行的恢复

          可以通过删除正在恢复的index,取消对这个index的恢复:

          DELETE /snapindex

          快照需要注意

          • 一个集群同时只能有一个快照运行
          • 有删除快照的操作时,不能进行快照

          恢复需要注意

          • restore的index可以不存在,如果存在必须是closed状态。
          • restore的index会完全覆盖之前的文件:即使文件完全相同,也会先删除原来old文件,然后在创建新new文件。
          • restore过程会跳过translog recovery过程,创建出新的translog。
          • 如果恢复的目标不是做snapshot的ES集群,而是一个新集群的话,需要在新集群里也创建一下repo,并且将readonly 参数指定为true。
          上一篇
          权限管理
          下一篇
          集群配置