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

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

一、源地域备份

1、源地域cos中创建bucket

创建bucket：

北京地域cos创建bucket

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

北京地域cos

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：备份目录，(es目录是我自己创建的目录，)/es不能写成es/，否则会出现删除快照操作无法删除COS中数据的情况。

执行如下：

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

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

GET /_snapshot/my_cos_backup

返回如下：

查看创建的repository

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

3、源地域备份snapshot

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

PUT /_snapshot/my_cos_backup/es_snapshot

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

返回如下：

创建repository

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

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目录中。

查看cos中备份的snapshot

进入indices目录：

bucket中的数据

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

二、COS跨地域数据复制

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

1、目的端cos创建bucket

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

上海地域创建bucket

2、cos间数据复制

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

源端cos的信息

目的端cos信息

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

cos数据复制进度

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

上海地域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 。

在上海es集群中创建repository

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

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": "*",
  "ignore_unavailable": true,
  "include_global_state": false
}

这里我们在命令后面加了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集群中。

另外如果想要对原来的快照索引settings进行忽略的话，则可以在恢复的请求体中加上参数：ignore_index_settings。

例如：

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参数来控制，把快照中的索引名称进行重命名：

POST /_snapshot/my_cos_backup/es_snapshot/_restore
{
  "indices": "wrong_bj_index",
  "rename_pattern": "wrong_(.+)",
  "rename_replacement": "wrong_bj_index_bak"
}

或者将集群中存在了的索引close掉，即先执行如下api：

POST wrong_bj_index/_close

然后再进行恢复，这时候会自动将close的索引和恢复的索引进行合并，这个也通常用来增量快照的恢复上。例如先对集群打一全量快照snapshot_1,然后恢复到目标集群中，此时索引名称为wrong_bj_index,然后在恢复过程中持续对原集群进行读写。恢复结束后，再对原集群停写，再次打一个快照snapshot_2,此时是一个增量的快照，然后再在目标集群中使用快照snapshot_2再一次恢复索引wrong_bj_index，因此在增量恢复前，需要先将第一次恢复过的索引close掉。

如果我们在恢复索引时不想恢复一部分索引，或者不想恢复系统索引，则可以在indices参数中，将这些索引排除掉。，例如排除系统索引，支持multi-target syntax语法：

POST /_snapshot/my_cos_backup/es_snapshot/_restore
{
  "indices": "*,-.*"
}

在恢复索引时排除索引

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

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集群通过COS实现跨地域备份与恢复