通过SnapShot迁移静态ES索引
迁移规划
由于规划，目前需要将北京ElasticSearch 迁移至 上海 ElasticSearch, 原则上迁移应尽可能的快，同时迁移期间应不影响现有业务数据，最好不要对待迁移资源有过多的访问，以及业务代码层面应该维持不变，
仅对底层数据源做切换。
迁移流程
迁移过程中将数据区分为增量数据，存量数据，并进行区别对待。针对数据的类型，通过不同的方式，介质迁移至上海新ElasticSearch 集群。
存量数据
存量数据使用ElasticSearch本身的备份机制，将备份存储至OSS 对象存储, 同时在上海集群中通过OSS 对象存储 执行索引恢复动作，从而达到迁移的目的。
主要步骤如下：
1.在待备份ElasticSearch集群创建备份仓库，指定备份仓库的存储地址为OSS，并配置指定的信息。
PUT _snapshot/bj_es_snapshot
{
"type": "oss", //仓库存储类型为 oss, 也可以指定其他的类型，fs, s3....
"settings": {
"endpoint": "http://oss-cn-beijing.aliyuncs.com", // 根据不同的 type， 配置不同的参数即可
"access_key_id": "***",
"secret_access_key": "***",
"bucket": "bj-es-transfer-sh",
"compress": true
}
}
2.在待备份ElasticSearch集群备份指定索引, 同时指定在指定仓库(bj_es_snapshot)中，当前备份的名字(snapshot_20200722_note_comment)
PUT _snapshot/bj_es_snapshot/snapshot_20200722_note_comment
{
"indices": "note_comment"
}
3.查看备份的状态，需要指定在指定仓库，指定备份。
GET /_snapshot/bj_es_snapshot/snapshot_20200722_note_comment/_status
返回值大概如下所示
{
"snapshots": [
{
"snapshot": "snapshot_20200722_note_comment",
"repository": "bj_es_snapshot",
"uuid": "_aU8yiywSmSgA6YluetXoA",
"state": "SUCCESS",
"shards_stats": {
"initializing": 0,
"started": 0,
"finalizing": 0,
"done": 5,
"failed": 0,
"total": 5
},
"stats": {
"number_of_files": 573,
"processed_files": 573,
"total_size_in_bytes": 6055684624,
"processed_size_in_bytes": 6055684624,
"start_time_in_millis": 1595399266865,
"time_in_millis": 116151
},
"indices": {
"note_comment": {
"shards_stats": {
"initializing": 0,
"started": 0,
"finalizing": 0,
"done": 5,
"failed": 0,
"total": 5
},
"stats": {
"number_of_files": 573,
"processed_files": 573,
"total_size_in_bytes": 6055684624,
"processed_size_in_bytes": 6055684624,
"start_time_in_millis": 1595399266865,
"time_in_millis": 116151
},
"shards": {
"0": {
"stage": "DONE",
"stats": {
"number_of_files": 129,
"processed_files": 129,
"total_size_in_bytes": 1188725503,
"processed_size_in_bytes": 1188725503,
"start_time_in_millis": 1595399267060,
"time_in_millis": 111677
}
},
"1": {
"stage": "DONE",
"stats": {
"number_of_files": 126,
"processed_files": 126,
"total_size_in_bytes": 1305824139,
"processed_size_in_bytes": 1305824139,
"start_time_in_millis": 1595399267062,
"time_in_millis": 115954
}
},
"2": {
"stage": "DONE",
"stats": {
"number_of_files": 90,
"processed_files": 90,
"total_size_in_bytes": 1113769915,
"processed_size_in_bytes": 1113769915,
"start_time_in_millis": 1595399267024,
"time_in_millis": 105830
}
},
"3": {
"stage": "DONE",
"stats": {
"number_of_files": 115,
"processed_files": 115,
"total_size_in_bytes": 1253077381,
"processed_size_in_bytes": 1253077381,
"start_time_in_millis": 1595399267044,
"time_in_millis": 114764
}
},
"4": {
"stage": "DONE",
"stats": {
"number_of_files": 113,
"processed_files": 113,
"total_size_in_bytes": 1194287686,
"processed_size_in_bytes": 1194287686,
"start_time_in_millis": 1595399266865,
"time_in_millis": 31435
}
}
}
}
}
}
]
}
主要观察，shards_stats 中， total 和 done 是不是相等，同时需要关注是否有失败的 shard, 如果done < total, 那么需要等待，或者存在 failed 那么需要排查失败的原因，同时再次进行备份，直至完全成功为止。
4.当观察到索引的所有shard都备份完毕，同时不存在失败的时候，那么就可以在新集群中执行恢复动作了。
4.1首先需要在新集群中新建相应的仓库，其中仓库的配置以及相关信息需要和源集群中创建的配置相同，因为之后需要从该仓库中进行恢复。也就是和集群中创建的仓库相同即可。
4.2执行回放动作即可, 需要指定 仓库名称，备份名称。
4.3.持续观察回放进度，待回放完成即可。即该命令的返回值中 percent 达到 100% 即可。
展开原码
4.4抽查相关数据，进行对比，以及查看数据条数总量，占用存储大小。无误即可。
增量数据
在备份开始前，可以将操作动作，同步至mq,同时原有索引正常使用，存量使用备份进行迁移，迁移完毕之后，消费mq, 待消费完积压数据，索引双写，
查询切换索引，进行数据验证，验证无误之后，迁移完毕，后续可停掉mq, 废弃原有索引。迁移完成。
相关点
备份，以及回放，总有一端可以使用oss 的内网进行传输，可以进行权衡利弊，在哪一个方向需要更快的网速。
耗时相关
迁移 algorithm_cluster_experiment doc数量 4200W+, 48GB, 备份耗时 308455 Millis
