Es 各个版本之间的升级

Es各个版本之间的升级主要有3种方式:

  • 直接替换二进制包,下载新版本的es 二进制包,直接替换现有的包,启动。这种方式有一个风险,就是升级过程如果出错,那么可能没法回滚。
  • backup restore,把es集群的数据备份到BOS,HDFS,NFS这样的共享存储上,用新版本的二进制包搭建一个新集群,然后在新集群上restore备份的数据,大部分情况下,我们都推荐这种方式。
  • reindex。可以做任何版本的之间的升级,但是由于是把原始集群的数据一条条读取出来然后再插入到新集群中,所以性能比较差,耗时比较长。从2.x版本开始有reindex功能。

目前Es在生产中使用的主要版本有1.7, 2.4, 5.5, 6.5。下面分别介绍下不同版本之间的升级方式。

  • 1.7 --> 2.4, 正常情况下替换jar包,backup restore均可以,但是实际发现在一些情况下是升级不了的,主要发现以下几个情况:1. 字段名包含特殊字符 2. 同一个字段在不同type中的doc value设置不一样,此时只能把这些异常的index删除后再升级。
  • 1.7 --> 5.5,不能直接升级,必须先升级到2.4,然后从2.4 reindex 到 5.5。
  • 1.7 --> 6.5,不能直接升级,必须先升级到2.4,然后从2.4 reindex 到 6.5。
  • 2.4 --> 5.5,可以通过backup restore或者替换二进制的方式进行。
  • 2.4 --> 6.5,通过reindex方式。
  • 5.5 --> 6.5,可以通过backup restore或者替换二进制的方式进行。

通过上面的描述可以总结一个原则:

  • 主版本之间只间隔1个版本号的升级从X 到 X+1(比如1.x 到 2.x, 或者 5.x 到 6.x )是可以通过backup restore或者替换二进制jar包实现的。
  • 主版本之间的版本号间隔超过1时(比如从1.x 到 5.x)是不可以通过backup restore或者替换二进制的方式来升级的,只能通过reindex。
  • 从版本号X 通过backup restore或者替换二进制jar包的方式升级到版本X+1后,不可以再通过替换二进制jar包或者backup restore的方式升级到版本X+2,只能通过reindex。

更详细的升级的约束信息请参考 Es官方网站