腾讯云ES集群通过COS实现跨地域备份与恢复

在日常开发及运维工作中，我们经常会遇到一些内外部的客户希望将不同地域的 ES 集群迁移到另外一个地域。例如有的客户 ES 集群原来是在北京地域，由于一些原因，现在想要将集群迁移到上海地域来。下面我们就详细介绍下借助腾讯云 COS 和 ES 的 snapshot 功能来实现跨地域的数据迁移。

我们的演示是将北京的集群数据迁移到上海集群来，因此北京集群作为源地域集群。上海集群作为目的地域集群。

一、源地域备份
1、源地域 cos 中创建 bucket

创建 bucket：

创建完 bucket 后，在该 bucket 下创建一个路径：

2、源地域创建 repository 仓库

PUT _snapshot/my_cos_backup{ "type": "cos", "settings": { "app_id": "1254139681", "access_key_id": "xxxx", "access_key_secret": "xxxx", "bucket": "wurong-es-snapshpt", "region": "ap-beijing", "compress": true, "chunk_size": "500mb", "base_path": "es/" }}

app_id：腾讯云账号 APPID。

access_key_id：腾讯云 API 密钥 SecretId。

access_key_secret：腾讯云 API 密钥 SecretKey。

bucket：COS Bucket 名字，名字不能带-{appId}后缀。

region：COS Bucket 地域，此地域必须与 ES 集群为同一地域。地域编码可参考 地域和可用区（https://cloud.tencent.com/document/product/213/6091?from=10680）。

base_path：备份目录。

执行如下：

创建的仓库名称为：my_cos_backup，bucket 名称为：wurong-es-snapshpt，base_path 为es/ .

创建好仓库后，我们可以使用如下命令查看

GET /_snapshot/my_cos_backup

返回如下：

可以看到仓库是创建成功了，下面我们把该集群上的所有索引快照都备份到该仓库下。

3、源地域备份 snapshot

在上一步我们创建了 my_cos_backup的repository，下面我们就开始将 snapshot 备份到该repository 中。

PUT /_snapshot/my_cos_backup/es_snapshot

其中：my_cos_backup为repository的名字，es_snapshot 是本次打快照的名字。

返回如下：

该命令是异步执行的，即执行完该命令后立马返回，可以使用下面的命令来查看快照的状态：

GET /_snapshot/my_cos_backup/es_snapshot/_status

返回结果如下：（限于篇幅，具体索引的信息被省略）

{ "snapshots" : [ { "snapshot" : "es_snapshot", "repository" : "my_cos_backup", "uuid" : "vHIZketQRHm2j-6ZG_gW5w", "state" : "SUCCESS", "include_global_state" : true, "shards_stats" : { "initializing" : 0, "started" : 0, "finalizing" : 0, "done" : 32, "failed" : 0, "total" : 32 }, "stats" : { "incremental" : { "file_count" : 601, "size_in_bytes" : 389117626 }, "total" : { "file_count" : 601, "size_in_bytes" : 389117626 }, "start_time_in_millis" : 1596006911431, "time_in_millis" : 15012 } } ]}

从 _status 快照状态的返回结果中，我们看到"state" : "SUCCESS”，则表示快照是备份成功了。如果是”IN_PROCESS”则表明还在执行中。

下面我们到 COS 控制台的 ES 目录下查看备份好的快照信息，索引的信息都存储在 indices 目录中。

进入 indices 目录：

可以看到北京集群中的快照都已经备份到北京地域的 cos 中了。

二、COS 跨地域数据复制

上一步我们完成了源地域集群快照数据的备份，即将北京 ES 集群中的索引快照数据都备份到了北京 cos 的 bucket 中。由于无法直接在目的端集群中进行恢复。因此需要先将北京 cos 中的数据复制到上海 cos 的 bucket 中。

1、目的端 cos 创建 bucket

和上一步一样，在上海地域 cos 中创建一个 bucket，名称叫 wurong-es-snapshot-sh。

2、cos 间数据复制

开始 cos 数据的同步复制迁移：将刚刚备份到北京 cos 桶下面的索引数据通过 cos 控制台提供的对象存储迁移功能，全量迁移到上海的桶中。这里我们选择根目录下的全量复制。

这里选择保存到根目录。点击确定后，数据开始迁移。

看到上面的进度显示数据全部迁移完成了。这时候我们到上海的 bucket 中查看数据是否已经同步过来了。

可以看到快照数据都已经全部从北京的 cos 桶中同步迁移过来了。

三、目的地域 snapshot 恢复

在上一步，我们完成了北京 cos 的索引快照数据复制到上海的 cos bucket 中。下面我们就将这些数据在上海的 ES 集群中恢复过来。

1、目的端集群创建 repository

在上海集群的 kibana Dev Tools 中同样执行创建仓库的命令：

PUT _snapshot/my_cos_backup{ "type": "cos", "settings": { "app_id": "1254139681", "access_key_id": “xxxx", "access_key_secret": “xxxx", "bucket": "wurong-es-snapshpt-sh", "region": "ap-shanghai", "compress": true, "chunk_size": "500mb", "base_path": "es/" }}

注意，这里的 bucket 应该是在上海地域创建的 bucket，即 wurong-es-snapshot-sh。

region 则是上海地域:ap-shanghai 。

同样，创建完成仓库后，可以使用下面命令查看：

GET _snapshot/my_cos_backup

2、目的端集群恢复 snapshot

在恢复之前，我们可以先使用下面的命令查看该仓库下有哪些快照：

GET /_snapshot/my_cos_backup/es_snapshot

结果如下：

{ "snapshots" : [ { "snapshot" : "es_snapshot", "uuid" : "vHIZketQRHm2j-6ZG_gW5w", "version_id" : 7050199, "version" : "7.5.1", "indices" : [ ".monitoring-kibana-7-2020.07.22", ".watcher-history-10-2020.07.26", ".monitoring-es-7-2020.07.27", ".monitoring-kibana-7-2020.07.28", ".watcher-history-10-2020.07.22", ".kibana_task_manager_1", ".monitoring-es-7-2020.07.23", ".monitoring-es-7-2020.07.26", ".monitoring-kibana-7-2020.07.24", ".monitoring-es-7-2020.07.29", ".watcher-history-10-2020.07.25", ".triggered_watches", ".watcher-history-10-2020.07.23", ".watcher-history-10-2020.07.24", ".monitoring-kibana-7-2020.07.25", ".watcher-history-10-2020.07.28", ".kibana_1", ".monitoring-es-7-2020.07.25", ".monitoring-es-7-2020.07.28", ".monitoring-kibana-7-2020.07.23", "wurong_bj_index", ".watcher-history-10-2020.07.27", ".apm-agent-configuration", ".monitoring-kibana-7-2020.07.27", ".watches", ".monitoring-es-7-2020.07.24", ".security-7", ".watcher-history-10-2020.07.29", ".monitoring-kibana-7-2020.07.29", ".monitoring-kibana-7-2020.07.26", ".monitoring-alerts-7", ".monitoring-es-7-2020.07.22" ], "include_global_state" : true, "state" : "SUCCESS", "start_time" : "2020-07-29T07:15:11.431Z", "start_time_in_millis" : 1596006911431, "end_time" : "2020-07-29T07:15:26.443Z", "end_time_in_millis" : 1596006926443, "duration_in_millis" : 15012, "failures" : [ ], "shards" : { "total" : 32, "failed" : 0, "successful" : 32 } } ]}

可以看到有一个名称为 es_snapshot 的快照，该快照下有32个索引。

我们可以将所有索引都恢复，也可以选择部分索引进行恢复。

下面我们恢复所有的快照数据：

POST /_snapshot/my_cos_backup/es_snapshot/_restore{ "indices": "wurong_bj_index", "ignore_unavailable": true, "include_global_state": false, "rename_replacement": "wurong_bj_index"}

这里我们在命令后面加了 wait_for_completion=true 的参数，在上面我们执行备份的时候没有加，命令是立即返回，异步执行的。想要查看备份的状态，必须使用下面的 _status 命令进行查看。但是加了 wait_for_completion=true，则表示该命令是同步执行的，直到恢复完成后才会返回（如果数据比较多，则不要加 wait_for_completion=true 参数)。

上面的是恢复所有的索引数据，通常会有一些系统索引已经存在，那就会出现异常的情况，我们也可以对部分特定索引进行恢复。命令如下：

POST /_snapshot/my_cos_backup/es_snapshot/_restore{ "indices": "wurong_bj_index", "ignore_unavailable": true, "include_global_state": false, "rename_replacement": "wurong_bj_index"}

我们将北京 ES 集群中的 wurong_bj_index 索引单独恢复到上海 ES 集群中。

使用如下命令查看该索引的恢复情况：

GET wurong_bj_index/_recovery

返回结果如下：

{ "wurong_bj_index" : { "shards" : [ { "id" : 0, "type" : "PEER", "stage" : "DONE", "primary" : false, "start_time_in_millis" : 1596009480330, "stop_time_in_millis" : 1596009480461, "total_time_in_millis" : 131, "source" : { "id" : "HSl4TLATR0KZgi-a7HcvOA", "host" : "10.111.45.14", "transport_address" : "10.111.45.14:22158", "ip" : "10.111.45.14", "name" : "1593570787000758032" }, "target" : { "id" : "l1cioJZ7Qxik59S-wcrASQ", "host" : "10.111.0.24", "transport_address" : "10.111.0.24:20599", "ip" : "10.111.0.24", "name" : "1593570787000757832" }, "index" : { "size" : { "total_in_bytes" : 3501, "reused_in_bytes" : 0, "recovered_in_bytes" : 3501, "percent" : "100.0%" }, "files" : { "total" : 4, "reused" : 0, "recovered" : 4, "percent" : "100.0%" }, "total_time_in_millis" : 60, "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" : 55 }, "verify_index" : { "check_index_time_in_millis" : 0, "total_time_in_millis" : 0 } }, { "id" : 0, "type" : "PEER", "stage" : "DONE", "primary" : true, "start_time_in_millis" : 1596009480111, "stop_time_in_millis" : 1596009480265, "total_time_in_millis" : 153, "source" : { "id" : "7_w_IFMRRuOAd1QWuP-uiw", "host" : "10.111.45.2", "transport_address" : "10.111.45.2:20490", "ip" : "10.111.45.2", "name" : "1594025750002497732" }, "target" : { "id" : "HSl4TLATR0KZgi-a7HcvOA", "host" : "10.111.45.14", "transport_address" : "10.111.45.14:22158", "ip" : "10.111.45.14", "name" : "1593570787000758032" }, "index" : { "size" : { "total_in_bytes" : 3501, "reused_in_bytes" : 0, "recovered_in_bytes" : 3501, "percent" : "100.0%" }, "files" : { "total" : 4, "reused" : 0, "recovered" : 4, "percent" : "100.0%" }, "total_time_in_millis" : 58, "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" : 59 }, "verify_index" : { "check_index_time_in_millis" : 0, "total_time_in_millis" : 0 } } ] }}

同样可以在上海 ES 的 kibana-Index Manager 中查看该索引是否已经存在。

发现数据确实已经恢复过来了。到此，腾讯云 ES 集群通过 COS 备份恢复的方式进行跨地域数据迁移就结束了。

总结

本文介绍了通过腾讯云 COS 和 ES 自身提供的 snapshot 功能实现了跨地域的集群间数据备份与恢复，即通过 snapshot 方式的数据迁移。这种迁移方式使用于离线迁移，即源地域集群需要停止一段时间的写入。

点击文末「阅读原文」，了解腾讯云Elasticsearch Service更多信息~

腾讯云大数据

长按二维码
关注我们