Elasticsearch版本升级实践、注意事项

版本关系

从官方文档看可以发现两个大版本升级需要关注到具体的版本，比如想从 5.x 版本升级到 7.x 版本，就必须先升级到 6.8 版本，再从 6.8 升级到 7.x 版本。

检查是否可以升级

1. 版本号确认

2. 通过API检查是否存在过期的用法

	# ES 6.x
	GET /_xpack/migration/deprecations?filter_path=index_settings

    # ES 7.x
	GET /_migration/deprecations?filter_path=index_settings

    关注其中的critical的整改项；

    

3. 可以查看segment信息，检查是什么版本的lucene（也就可以知道ES版本）创建的，例如5.x创建的索引，即使已经升级到6.8版本，想要升级到7.17，依然需要重建索引。

异常

如果出现不兼容的情况，ES节点无法启动。

注意事项

1. 客户端

ES不同版本的客户端，可以说是非常乱了，抛开非官方推荐的client（jest、bboss等），依然有很多不兼容的地方。

这里简单列一些结论：（仅包括 rest-high-level-client）

7.5 的 client 可以访问 6.8 的集群

6.8 的 client 可以访问 7.5 的集群

6.8.23 的 client 的版本可以访问 7.17.5 的集群

7.17.5 的 client 不能访问 6.8.5 集群 （"message": "Elasticsearch exception [type=exception, reason=Content-Type header [application/vnd.elasticsearch+json; compatible-with=7] is not supported]"）

2. type

ES 的 type 也是比较尴尬的地方，带有历史债的场景，改动相对不那么平滑。

ES6.8 创建带 type 的 index，直接升级到 7.17，可以通过 带type/_doc 来查询、写入

# 在6版本创建index
PUT zmc
{
 "mappings": {
      "properties": {
        "aa": {
          "type": "keyword"
        }
      }
    }
}

# PUT 一条数据

# 升级到7.17

# 执行，可以查到结果
GET zmc/type/_search
{

}

# 执行，可以查到结果
GET zmc/_search
{
  
}

# 执行，不可以查到结果
GET zmc/_doc/_search
{

}

# 可以写入
POST zmc/_doc/aa
{
  "aa":"111"
}

# 可以写入
POST zmc/type/bb
{
  "aa":"111"
}


# 可以查到结果
GET zmc/_doc/bb

# 可以查到结果
GET zmc/type/bb

总的来说，7.17会对6.8集群创建的带type的index进行兼容，需要注意读写语句的写法，可以看到上面的测试，建议读写都带上type。(当然，升级完成后type肯定还是要去掉的)

注：7.x/8.x 对_doc不再视为一个默认的type，而且查询中的一个永久的路径。

升级流程

1.API检查是否可以升级，不能则先改造

2.升级ES集群（此时依然使用6.8客户端，兼容访问6.8/7.17集群）

3.重建索引（去掉type）

4.修改客户端代码 & 升级客户端版本到 7.17

注：如果发现是5版本创建的索引，得先重建索引，再升级集群，再重建索引。

参考

官方文档：

1. Reindex before upgrading | Elasticsearch Guide [7.17] | Elastic

2. Rolling upgrades | Elasticsearch Guide [7.17] | Elastic