在日常开发及运维工作中，我们经常会遇到一些内外部的客户希望将不同地域的es集群迁移到另外一个地域。例如有的客户es集群原来是在北京地域，由于一些原因，现在想要将集群迁移到上海地域来。下面我们就详细介绍下借助腾讯云COS和es的snapshot功能来实现跨地域的数据迁移。
我们的演示是将北京的集群数据迁移到上海集群来，因此北京集群作为源地域集群。上海集群作为目的地域集群。
一、源地域备份
1、源地域cos中创建bucket
创建bucket：
北京地域cos创建bucket创建完bucket后，在该bucket下创建一个路径：
北京地域cos2、源地域创建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：备份目录，(es目录是我自己创建的目录，)/es不能写成es/，否则会出现删除快照操作无法删除COS中数据的情况。
执行如下：
创建的仓库名称为：my_cos_backup，bucket名称为：wurong-es-snapshpt，base_path为es/ .
创建好仓库后，我们可以使用如下命令查看
代码语言：javascript复制GET /_snapshot/my_cos_backup返回如下：
查看创建的repository可以看到仓库是创建成功了，下面我们把该集群上的所有索引快照都备份到该仓库下。
3、源地域备份snapshot
在上一步我们创建了my_cos_backup的repository，下面我们就开始将snapshot备份到该repository中。
代码语言：javascript复制PUT /_snapshot/my_cos_backup/es_snapshot其中：my_cos_backup为repository的名字，es_snapshot是本次打快照的名字。
返回如下：
创建repository该命令是异步执行的，即执行完该命令后立马返回，可以使用下面的命令来查看快照的状态：
代码语言：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目录中。
查看cos中备份的snapshot进入indices目录：
bucket中的数据可以看到北京集群中的快照都已经备份到北京地域的cos中了。
二、COS跨地域数据复制
上一步我们完成了源地域集群快照数据的备份，即将北京es集群中的索引快照数据都备份到了北京cos的bucket中。由于无法直接在目的端集群中进行恢复。因此需要先将北京cos中的数据复制到上海cos的bucket中。
1、目的端cos创建bucket
和上一步一样，在上海地域cos中创建一个bucket，名称叫wurong-es-snapshot-sh。
上海地域创建bucket2、cos间数据复制
开始cos数据的同步复制迁移：将刚刚备份到北京cos桶下面的索引数据通过cos控制台提供的对象存储迁移功能，全量迁移到上海的桶中。这里我们选择根目录下的全量复制。
源端cos的信息
目的端cos信息这里选择保存到根目录。点击确定后，数据开始迁移。
cos数据复制进度看到上面的进度显示数据全部迁移完成了。这时候我们到上海的bucket中查看数据是否已经同步过来了。
上海地域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 。
在上海es集群中创建repository同样，创建完成仓库后，可以使用下面命令查看：
代码语言：javascript复制GET _snapshot/my_cos_backup2、目的端集群恢复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": "*",
"ignore_unavailable": true,
"include_global_state": false
}这里我们在命令后面加了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集群中。
另外如果想要对原来的快照索引settings进行忽略的话，则可以在恢复的请求体中加上参数：ignore_index_settings。
例如：
代码语言：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",
"ignore_index_settings":"index.routing.allocation.require.box_type,index.routing.allocation.include.tag,index.routing.allocation.require.hotwarm_type"
}当我们想要恢复一个集群中已经存在了的索引时，可以通过rename_replacement参数来控制，把快照中的索引名称进行重命名：
代码语言：javascript复制POST /_snapshot/my_cos_backup/es_snapshot/_restore
{
"indices": "wrong_bj_index",
"rename_pattern": "wrong_(. )",
"rename_replacement": "wrong_bj_index_bak"
}或者将集群中存在了的索引close掉，即先执行如下api：
代码语言：javascript复制POST wrong_bj_index/_close然后再进行恢复，这时候会自动将close的索引和恢复的索引进行合并，这个也通常用来增量快照的恢复上。例如先对集群打一全量快照snapshot_1,然后恢复到目标集群中，此时索引名称为wrong_bj_index,然后在恢复过程中持续对原集群进行读写。恢复结束后，再对原集群停写，再次打一个快照snapshot_2,此时是一个增量的快照，然后再在目标集群中使用快照snapshot_2再一次恢复索引wrong_bj_index，因此在增量恢复前，需要先将第一次恢复过的索引close掉。
如果我们在恢复索引时不想恢复一部分索引，或者不想恢复系统索引，则可以在indices参数中，将这些索引排除掉。，例如排除系统索引，支持multi-target syntax语法：
代码语言：javascript复制POST /_snapshot/my_cos_backup/es_snapshot/_restore
{
"indices": "*,-.*"
}
在恢复索引时排除索引使用如下命令查看该索引的恢复情况：
代码语言：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的几种方案介绍。
