Upgrading the _all field


(Nathan Trevivian) #1

We're currently operating a v2.4 cluster, and want to upgrade to v6.x
As I understand it, v6.x wont read v2.4-created indices, but will read v5.6.9-created indices.

So the plan is go to to v5.6.9, reindex all the data into v5.6.9 created-indices, and then upgrade to v6.x. That way we only have to reindex once, which is good, because we have a LOT of data. (Like, seriously, a LOT)
Bear with me.

In our v2.4 cluster we're using the _all field. v5.6.9 supports _all, but it's deprecated in v6.x, and the docs suggest using a copy_to field.

My question is: what should my 5.6.9 mapping look like with regards to the _all field to ensure that it's totally compatible with v6.x and later indices?

In my v6.x indices mappings I was going for something like this for an all field:

                "all": {
                    "type": "text",
                    "store": false
                }

with relevant fields having copy_to: all. Is that a good way of doing it?

Will copy_to in v5.6.9 work in the same way it does in v6.x?
Are people expecting that when v7.x arrives it won't be able to read v5.x indices?

Thanks!