update esm，干货看这篇!ES索引跨版本迁移参考

(9500.163.com)

Elasticsearch不同版本之间存在部分不兼容的配置，比如Elasticsearch 5索引是支持多type的，Elasticsearch从6.x版本开始，不再支持一个索引多个type。 达到当天最大量API KEY 超过次数限制那么我们在es升级之后，索引的迁移就会遇到一些麻烦。es版本好升级，索引迁移就比较困难了。本文以一个简单的例子来进行跨版本的索引迁移，方法有很多，本文仅仅作为一个参考，但是总体思路大致是差不多的。

背景介绍

待迁移索引名：search-resource

源ES版本：5.6.16

目的ES版本： 7.11.1

操作步骤

1.检查集群中待迁移的索引是否存在处于close状态

GET _cat/indices?v

2.集群中是否配置了跨集群访问，这个是集群滚到升级时候需要注意的

Elasticsearch 5.x版本中使用的配置参数是，而6.x版本中使用的是clu。

3. 检查索引模板级别配置

序号	配置级别	配置信息	配置参数
1	集群级别	集群快照设置（Snapshot settings）	clu
2		集群存储限流设置（Store throttling settings）	indices.、indices.
3	索引级别	索引相似性设置（Similarity settings）	index.
4		索引影子副本设置（Shadow Replicas settings）	index.shared_filesystem、index.shadow_replicas
5		索引存储设置（Index Store settings）	index.
6		索引存储限流设置（Index Store throttling settings）	index.、index.
7		索引Mapping参数include_in_all设置	include_in_all 说明 该配置在6.0版本之后创建的索引中无法使用，但在5.x版本中创建的包含此配置的索引，在升级到6.x版本后，可以兼容。
8		索引创建版本设置	index.ver 说明 该配置表示不允许跨主版本升级索引。例如，无法将在5.x版本创建的索引直接升级到7.x版本，需要将失败的索引通过reindex迁移到新索引并删除后，再进行升级。
9	索引模板级别	索引模板相似性设置（Similarity settings）	index.
10		索引模板影子副本设置（Shadow Replicas settings）	index.shared_filesystem、index.shadow_replicas
11		索引模板存储设置（Index Store settings）	index.
12		索引模板存储限流设置（Index Store throttling settings）	index.、index.
13		索引模板 Mapping参数include_in_all	include_in_all
14		索引模板Mapping元字段_all	_all
15		索引模板Mapping包含多个type	无 说明 检查索引Mapping中是否包含多个type。

4.使用reindex需要提前在目标ES上设置 reindex.remo

核心思路就是：要把多type合并为一个type，并所以需要把_type字段值统一为_doc，并新增一个type字段用来承载原先的_type值；或者拆索引，单索引多type数据，按照不同的type，通过reindex拆分成多个单索引单type数据

单索引多type拆分单索引单type，在源es对应的kibana上dev tools上执行如下：

POST _reindex
{
"source": {
"index": "search-resource",
"type": "device",
"size": 10000
},
"dest": {
"index": "device-search-resource"
}
}

POST _reindex
{
"source": {
"index": "search-resource",
"type": "user",
"size": 10000
},
"dest": {
"index": "user-search-resource"
}
}

5.若索引内容不大，可能将单索引多type数据合并成单索引单type数据的方案更佳。

POST _reindex?wait_for_completion=false
{
"source": {
"index": "search-resources"
},
"dest": {
"index": "search-resources-7"
},
"script": {
"inline": """
c = c + "-" + c;
c = c;
c = "doc";
""",
"lang": "painless"
}
}

以上示例通过自定义type的方式，指定c在new1索引中添加type字段，将其设置为原始_type的值。并且new1索引的_id由_type-_id组成，防止存在不同类型的文档具有相同的ID而发生冲突的情况。

6.完成索引type合并之后，我们可以GET search-resource-7 查看下索引的setting和mapping

{
"search-resources-7": {
"aliases": {},
"mappings": {
"doc": {
"properties": {
"admin_is_display": {
"type": "long"
},
"comment_count": {
"type": "long"
},
"control_code": {
"type": "long"
},
"create_time": {
"type": "date",
"format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
},
"share_count": {
"type": "long"
},
"status": {
"type": "long"
},
"topic_id": {
"type": "long"
},
"topic_name": {
"type": "text",
"fields": {
"cn": {
"type": "text",
"analyzer": "ik_max_word"
},
"en": {
"type": "text",
"analyzer": "english"
}
}
},
"topic_type_id": {
"type": "long"
},
"topic_type_ids": {
"type": "keyword"
},
"type": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"update_time": {
"type": "date",
"format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
},
"user_id": {
"type": "long"
}
}
}
},
"settings": {
"index": {
"creation_date": "1616034518905",
"number_of_shards": "1",
"number_of_replicas": "0",
"uuid": "dHFAlgwfQ3Cl6mjZL4g6wg",
"version": {
"created": "5061699"
},
"provided_name": "search-resources-7"
}
}
}
}

已经添加了type字段，如下：

"type": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},

查看合并之后的索引数据，执行如下命令

GET search-resources-7/_search
{
"query": {
"match_all": {}
}
}

具体内容我就不截图了，可以查看type的值是之前_type的值，目的已经达成，下面一步是迁移索引到e上去了。

7.这一步有很多方法可以实现，比如用logstash，比如esm：

我仍然采用的是reindex的方式，和上面不同的是，我是事先在es 7.11上创建好了索引（或者索引模板也可以）

# json内容来自于源ES合并type之后的索引，GET search-resource-7
PUT search-resources
{
"mappings": {
"doc": {
"properties": {
"admin_is_display": {
"type": "long"
},
"comment_count": {
"type": "long"
},
"control_code": {
"type": "long"
},
"create_time": {
"type": "date",
"format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
},
"share_count": {
"type": "long"
},
"status": {
"type": "long"
},
"topic_id": {
"type": "long"
},
"topic_name": {
"type": "text",
"fields": {
"cn": {
"type": "text",
"analyzer": "ik_max_word"
},
"en": {
"type": "text",
"analyzer": "english"
}
}
},
"topic_type_id": {
"type": "long"
},
"topic_type_ids": {
"type": "keyword"
},
"type": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"update_time": {
"type": "date",
"format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
},
"user_id": {
"type": "long"
}
}
}
},
"settings": {
"index": {
"number_of_shards": "1",
"number_of_replicas": "0"
}
}
}

设置副本数为0是为了加快迁移的速度，副本数可以等索引迁移完成之后再修改

8. 在ES 7.11.1对应的kibana上执行

POST _reindex?wait_for_completion=false
{
"source": {
"remote": {
"host": "http://192.168.2.14:9200" # reindex.remo
}
, "index": "search-resources-7"
, "size": 100
}
, "dest": {
"index": "search-resources"
}
}

9.对比两边索引文档的数目是一致的，随机查看几个内容也是一致的，后面就是对应的应用需要改造了，es的client也得升级到7了。

总结：对于索引内容不大的情况，reindex还是比较适配的，若是索引内容很大，重建索引和迁移会花费很多时间，可能不是最优的方案，本文只是抛砖引玉，毕竟我测试索引才300M。升级ES type是个绕不过去的坑，单索引单type则会方便很多。ES升级之路任重而道远啊！