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

背景介绍

待迁移索引名：search-resource

源ES版本：5.6.16

目的ES版本： 7.11.1

操作步骤

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

GET  _cat/indices?v

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

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

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

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

核心思路就是：要把多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": """
    ctx._id = ctx._type + "-" + ctx._id;
    ctx._source.type = ctx._type;
    ctx._type = "doc";
    """,
    "lang": "painless"
  }
}

以上示例通过自定义type的方式，指定ctx._source.type在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的值，目的已经达成，下面一步是迁移索引到es7.11上去了。

7.这一步有很多方法可以实现，比如用logstash，比如esm：https://github.com/medcl/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.remote.whitelist
    }
    , "index": "search-resources-7"
    , "size": 100
  }
  , "dest": {
    "index": "search-resources"
  }
}

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

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