【腾讯云 Elasticsearch Service】高可用，可伸缩，云端全托管。集成X-Pack高级特性，适用日志分析/企业搜索/BI分析等场景
在日常开发及运维工作中，我们经常会遇到一些内外部的客户希望将不同地域的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 集群为同一地域。地域编码可参考 地域和可用区。
- 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方式的数据迁移。这种迁移方式使用于离线迁移，即源地域集群需要停止一段时间的写入。如果希望业务不停服平滑完成迁移。可以参考我的另外一篇文章自建ES集群迁移至腾讯云ES的几种方案介绍。
最新活动
包含文章发布时段最新活动，前往ES产品介绍页，可查找ES当前活动统一入口
Elasticsearch Service自建迁移特惠政策>>
Elasticsearch Service 新用户特惠狂欢，最低4折首购优惠 >>
Elasticsearch Service 企业首购特惠，助力企业复工复产>>
