elasticserach 1.x upgrade to 5.x

Elasticserach has been using 1.x, and is ready to upgrade to 5.x this quarter. Because it manages the entire cluster, it is necessary to let other business parties upgrade without thinking.

This quarter, record the upgrade process:
1.x upgrade to 2 .x

installed the elasticsearch-migration-1.x plug-in and found a lot of problems, first let’s talk about the problems encountered in the

startup :

"—————— The impact is serious and will prevent the cluster from starting- --------------------》
1.mapping: 1.x supports fields with the same name under different types in the same index, and the field mapping can be completely different
         2.x No, the field types under different types must be the same, the word segmentation method, indexing and other settings must also be the same, except for the following cases:
Fields with the same name, in the same index, in different types, must have the same mapping , with the exception of the copy_to, dynamic, enabled, ignore_above, include_in_all, and properties parameters, which may have different settings per field.

This change is still very supportive, after unification to avoid confusing use, I am here in 1.x When using it, there has been a problem because the same name attribute under different types is different.


Things to pay attention to when using:

1. The "_id" field is used as the unique identifier automatically generated or specified by mapping in 1.x. In 2.x, the name has changed, and it becomes "_uid".
If the _id sorting is used in use, it needs to be modified . (Just change the name? Why, it doesn't make sense)
---I queried the api again, I misunderstood, the id of 1.x can specify the path, but the 2.x cannot be specified, only

2.routing can be automatically generated Personally, I think this change is quite big and unreasonable. The previous "_routing": you need to specify a path. This is very good and understandable. Why do you need to change the method now, or two operations , What kind of trouble, I haven't figured out the foreshadowing here. --However, there is a need to modify the

use of the 3.BOOLEAN field, mainly because the returned content has changed. It used to be true/false (T/F), but now it has become 1/0.
If you use it, you must pay attention That's it.

4. Use of expiration time: _timestamp and _ttl are discarded. It seems that 2.x can also have the same function, but it is not used often, so I don’t pay attention

to the use of 5. The use of dots: this is also a specification, in the previous 1.x field Can contain ".", 2.x is now not allowed, if there was in the previous index, it is a bit of a tragedy, and the data needs to be

rebuilt , now use the analyzer directly, but fortunately, the search_analyzer is retained, which is also good, making the settings more concise. (Personally, I feel a little bit out of my pants and fart. The previous 3 were easy to use.)

The _analyzer meta field, which allows the analyzer settings for each document, has also been removed (this attribute has not been used, not clear, but it is a change, also posted here)

7. A field can no longer be referenced using its short name. Instead, the full path to the field is required.
The problem of the field reference name is not used much. Generally, when this problem is encountered, it is ok to bring the full path.

8. The use of date: It is not completely clear, the analysis method has changed, and then update it when it is clear