【腾讯云 Elasticsearch Service】高可用,可伸缩,云端全托管。集成X-Pack高级特性,适用日志分析/企业搜索/BI分析等场景
在日常开发及运维工作中,我们经常会遇到一些内外部的客户希望将不同地域的es集群迁移到另外一个地域。例如有的客户es集群原来是在北京地域,由于一些原因,现在想要将集群迁移到上海地域来。下面我们就详细介绍下借助腾讯云COS和es的snapshot功能来实现跨地域的数据迁移。
我们的演示是将北京的集群数据迁移到上海集群来,因此北京集群作为源地域集群。上海集群作为目的地域集群。
一、源地域备份
1、源地域cos中创建bucket
创建bucket:
创建完bucket后,在该bucket下创建一个路径:
2、源地域创建repository仓库
代码语言:javascript复制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/ .
创建好仓库后,我们可以使用如下命令查看
代码语言:javascript复制GET /_snapshot/my_cos_backup
返回如下:
可以看到仓库是创建成功了,下面我们把该集群上的所有索引快照都备份到该仓库下。
3、源地域备份snapshot
在上一步我们创建了my_cos_backup的repository,下面我们就开始将snapshot备份到该repository中。
代码语言:javascript复制PUT /_snapshot/my_cos_backup/es_snapshot
其中:my_cos_backup为repository的名字,es_snapshot是本次打快照的名字。
返回如下:
该命令是异步执行的,即执行完该命令后立马返回,可以使用下面的命令来查看快照的状态:
代码语言:javascript复制GET /_snapshot/my_cos_backup/es_snapshot/_status
返回结果如下:(限于篇幅,具体索引的信息被省略)
代码语言:javascript复制{
"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中同样执行创建仓库的命令:
代码语言:javascript复制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 。
同样,创建完成仓库后,可以使用下面命令查看:
代码语言:javascript复制GET _snapshot/my_cos_backup
2、目的端集群恢复snapshot
在恢复之前,我们可以先使用下面的命令查看该仓库下有哪些快照:
代码语言:javascript复制GET /_snapshot/my_cos_backup/es_snapshot
结果如下:
代码语言:javascript复制{
"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个索引。
我们可以将所有索引都恢复,也可以选择部分索引进行恢复。
下面我们恢复所有的快照数据:
代码语言:javascript复制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参数)。
上面的是恢复所有的索引数据,通常会有一些系统索引已经存在,那就会出现异常的情况,我们也可以对部分特定索引进行恢复。命令如下:
代码语言:javascript复制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集群中。
使用如下命令查看该索引的恢复情况:
代码语言:javascript复制GET wurong_bj_index/_recovery
返回结果如下:
代码语言:javascript复制{
"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 企业首购特惠,助力企业复工复产>>