本文中含有需要您注意的重要提示信息,忽略该信息可能对您的业务造成影响,请务必仔细阅读。
通过快照备份与恢复命令,您可以实现手动备份与恢复阿里云Elasticsearch实例的索引数据,并将备份的数据保存到一个共享仓库里。本文介绍如何手动备份与恢复数据。
背景信息
ES数据备份与恢复依赖于elasticsearch-repository-oss插件,阿里云ES实例默认已安装该插件且不可卸载。关于该插件的详细信息,请参见elasticsearch-repository-oss。
前提条件
已开通对象存储服务OSS(Object Storage Service),并新建一个标准存储类型的Bucket(不支持归档存储类型),开通Bucket公共读权限,且Bucket的地域需要与Elasticsearch实例的地域保持一致。 具体操作,请参见开通OSS服务和创建存储空间。
RAM用户需要具备
AliyunOSSFullAccess
权限策略。具体操作,请参见为RAM用户授权。
注意事项
快照仅保存索引数据,不保存Elasticsearch实例自身的监控数据(例如以
.monitoring
和.security_audit
为前缀的索引)、元数据、Translog、实例配置数据、Elasticsearch软件包、自带和自定义的插件、Elasticsearch日志等。本文中的代码均可以在阿里云Elasticsearch实例的Kibana控制台上执行。详细信息,请参见登录Kibana控制台。
创建仓库
创建一个名称为my_backup的仓库。
云上集群创建仓库。
PUT _snapshot/my_backup/ { "type": "oss", "settings": { "endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com", "access_key_id": "xxxx", "secret_access_key": "xxxxxx", "bucket": "xxxxxx", "compress": true, "chunk_size": "500mb", "base_path": "snapshot/" } }
8.x版本自建集群创建仓库,需要安装elasticsearch-repository-oss插件。具体操作,请参见安装elasticsearch-repository-oss插件。
说明关于该插件的详细信息,请参见elasticsearch-repository-oss。
PUT /_snapshot/my_backup { "type": "oss", "settings": { "oss.client.endpoint": "oss-cn-shanghai.aliyuncs.com", "oss.client.access_key_id": "xxx", "oss.client.secret_access_key": "xxx", "oss.client.bucket": "xxxxxx", "oss.client.base_path":"snapshot/", "oss.client.compress": true } }
参数 | 说明 |
endpoint | OSS Bucket的内网访问域名。获取方式,请参见访问域名和数据中心。 |
access_key_id | 用于标识用户。获取方式,请参见获取AccessKey。 |
secret_access_key | 用于验证用户的密钥。获取方式,请参见获取AccessKey。 |
bucket | OSS Bucket的名称,需要一个已经存在的Bucket。获取方式,请参见控制台创建存储空间。 |
compress | 打开快照文件的压缩功能:
|
chunk_size | 当您上传的数据非常大时,配置此参数可以限制快照过程中分块的大小。超过这个大小,数据将会被分块上传到OSS中。 |
base_path | 仓库的起始位置,默认为根目录。可以指定具体快照的存放目录,例如snapshot/myindex/。 |
获取仓库信息
获取所有仓库的信息
GET _snapshot
获取指定仓库的信息
GET _snapshot/my_backup
创建快照
为全部索引创建快照
PUT _snapshot/my_backup/snapshot_1
以上命令会为所有打开的索引创建名称为snapshot_1的快照,并保存到my_backup仓库中。该命令会立刻返回,并在后台执行备份任务。如果您希望任务执行完成后再返回,可通过添加wait_for_completion实现。该参数会阻塞调用直到备份完成,如果是大型快照,需要很长时间才能返回。
PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true
一个仓库可以包含多个快照,每个快照中可以包含所有、部分或单个索引的备份数据。
第一次创建快照时,系统会备份所有的数据,后续所有的快照仅备份已存快照和新快照之间的增量数据。随着快照的不断进行,备份也在增量的添加和删除。这意味着后续备份会相当快速,因为它们只传输很小的数据量。
为指定索引创建快照
系统默认会备份所有打开的索引。如果您在使用Kibana,并且考虑到磁盘空间大小因素,不需要把所有诊断相关的.kibana
索引都备份起来,那么可以在创建快照时,指定需要备份的索引。
PUT _snapshot/my_backup/snapshot_2
{
"indices": "index_1,index_2"
}
以上命令只会备份名称为index_1和index_2的索引。
查看快照信息
查看所有快照信息
GET _snapshot/my_backup/_all
预期结果如下:
{
"snapshots": [
{
"snapshot": "snapshot_1",
"uuid": "vIdSCkthTeGa0nSj4D****",
"version_id": 5050399,
"version": "5.5.3",
"indices": [
".kibana"
],
"state": "SUCCESS",
"start_time": "2018-06-28T01:22:39.609Z",
"start_time_in_millis": 1530148959609,
"end_time": "2018-06-28T01:22:39.923Z",
"end_time_in_millis": 1530148959923,
"duration_in_millis": 314,
"failures": [],
"shards": {
"total": 1,
"failed": 0,
"successful": 1
}
},
{
"snapshot": "snapshot_3",
"uuid": "XKO_Uwz_Qu6mZrU3Am****",
"version_id": 5050399,
"version": "5.5.3",
"indices": [
".kibana"
],
"state": "SUCCESS",
"start_time": "2018-06-28T01:25:00.764Z",
"start_time_in_millis": 1530149100764,
"end_time": "2018-06-28T01:25:01.482Z",
"end_time_in_millis": 1530149101482,
"duration_in_millis": 718,
"failures": [],
"shards": {
"total": 1,
"failed": 0,
"successful": 1
}
}
]
}
根据快照名查看指定快照的信息
GET _snapshot/my_backup/snapshot_3
预期结果如下:
{
"snapshots": [
{
"snapshot": "snapshot_3",
"uuid": "vIdSCkthTeGa0nSj4D****",
"version_id": 5050399,
"version": "5.5.3",
"indices": [
".kibana"
],
"state": "SUCCESS",
"start_time": "2018-06-28T01:22:39.609Z",
"start_time_in_millis": 1530148959609,
"end_time": "2018-06-28T01:22:39.923Z",
"end_time_in_millis": 1530148959923,
"duration_in_millis": 314,
"failures": [],
"shards": {
"total": 1,
"failed": 0,
"successful": 1
}
}
]
}
使用_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
}
}
}
}
}
}
]
}
删除快照
删除指定的快照。如果该快照正在进行,执行以下命令,系统会中断快照进程并删除仓库中创建到一半的快照。
DELETE _snapshot/my_backup/snapshot_3
删除快照请使用DELETE API,而不能使用其他机制删除(例如手动删除可能会造成备份严重损坏)。因为快照是增量的,很多快照可能依赖于之前的备份数据。DELETE API能够过滤出还在被其他快照使用的数据,只删除不再被使用的备份数据。
从快照恢复
建议不要恢复
.
开头的系统索引,此操作可能会导致Kibana访问失败。如果集群中存在与待恢复索引同名的索引,需要提前删除或者关闭该同名索引后再恢复,否则恢复失败。
如果需要跨地域恢复集群快照,需要先将原地域OSS中的快照数据迁移到目标地域的OSS中,再恢复到目标地域的Elasticsearch集群中。OSS间迁移的具体操作,请参见迁移实施。
在目标集群中创建OSS仓库
在将快照恢复到目标集群前,需要在目标集群中创建仓库,并映射到与快照备份相同的OSS地址中,详细信息请参见创建仓库。
PUT _snapshot/my_backup_restore/
{
"type": "oss",
"settings": {
"endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com",
"access_key_id": "xxxx",
"secret_access_key": "xxxxxx",
"bucket": "xxxxxx",
"compress": true,
"chunk_size": "500mb",
"base_path": "snapshot/"
}
}
恢复指定索引
如果您需要在不替换现有数据的前提下,恢复旧版本的数据来验证内容,或者进行其他处理,可恢复指定的索引,并重命名该索引。
POST /_snapshot/my_backup_restore/snapshot_1/_restore
{
"indices": "index_1",
"rename_pattern": "index_(.+)",
"rename_replacement": "restored_index_$1"
}
参数 | 说明 |
indices | 只恢复index_1索引,忽略快照中的其他索引。 |
rename_pattern | 查找正在恢复的索引,该索引名称需要与提供的模板匹配。 |
rename_replacement | 重命名查找到的索引。 |
恢复所有索引(除.
开头的系统索引)
POST _snapshot/my_backup_restore/snapshot_1/_restore
{"indices":"*,-.monitoring*,-.security*,-.kibana*","ignore_unavailable":"true"}
恢复所有索引(包含.
开头的系统索引)
POST _snapshot/my_backup_restore/snapshot_1/_restore
假设snapshot_1中包含5个索引,那么这5个索引都会被恢复到集群中。
_restore API会立刻返回,恢复进程会在后台进行。如果您希望调用阻塞直到恢复完成,可以添加wait_for_completion参数。
POST _snapshot/my_backup_restore/snapshot_1/_restore?wait_for_completion=true
将快照恢复到Indexing Service实例中。
将index_1
索引数据恢复到Indexing Service实例中,并且放到my_backup_restore仓库下,示例如下。
实际使用时,您需要将对应信息替换为您实际的信息。
POST /_snapshot/my_backup_restore/snapshot_1/_restore
{
"indices": "index_1",
"ignore_index_settings": [
"index.apack.cube.following_index"
]
}
查看快照恢复信息
您可以通过_recovery API来监控快照恢复的状态、进度等信息。
查看快照中指定索引的恢复状态
GET restored_index_3/_recovery
查看集群中的所有索引的恢复信息
获取的恢复信息可能包含跟您的恢复进程无关的其他分片的恢复信息。
GET /_recovery/
预期结果如下:
{
"restored_index_3" : {
"shards" : [ {
"id" : 0,
"type" : "snapshot",
"stage" : "index",
"primary" : true,
"start_time" : "2014-02-24T12:15:59.716",
"stop_time" : 0,
"total_time_in_millis" : 175576,
"source" : {
"repository" : "my_backup",
"snapshot" : "snapshot_3",
"index" : "restored_index_3"
},
"target" : {
"id" : "ryqJ5lO5S4-lSFbGnt****",
"hostname" : "my.fqdn",
"ip" : "10.0.**.**",
"name" : "my_es_node"
},
"index" : {
"files" : {
"total" : 73,
"reused" : 0,
"recovered" : 69,
"percent" : "94.5%"
},
"bytes" : {
"total" : 79063092,
"reused" : 0,
"recovered" : 68891939,
"percent" : "87.1%"
},
"total_time_in_millis" : 0
},
"translog" : {
"recovered" : 0,
"total_time_in_millis" : 0
},
"start" : {
"check_index_time" : 0,
"total_time_in_millis" : 0
}
} ]
}
}
输出结果会展示所有恢复中的索引,并列出这些索引中的所有分片。同时每个分片中会展示启动和停止时间、持续时间、恢复百分比、传输字节数等统计值。部分参数说明如下。
参数 | 说明 |
type | 恢复的类型。snapshot表示这个分片是在从一个快照恢复。 |
source | 待恢复的快照和仓库。 |
percent | 恢复的进度。94.5%表示对应分片已经恢复了94.5%的数据。 |
删除正在进行快照恢复的索引
通过DELETE命令删除正在恢复的索引,取消恢复操作。
DELETE /restored_index_3
如果restored_index_3正在恢复中,以上删除命令会停止恢复,同时删除所有已经恢复到集群中的数据。