(57) ElasticSearch rebuilds the index and ensures that the application does not need to be restarted

　　Once the type of the field in ElasticSearch is determined, it cannot be modified. If we want to modify the type of the field, we must rebuild the mapping. Then batch import the data from the old index into the new index. At the same time, the index is aliased so that the client application does not need to be restarted.

　　1. Once the demo field type is determined, it cannot be modified

　　Add documents and create indexes by default

PUT index1/type1/1
{
  "content":"2000-11-11"
}

　　Query field type, content type is date

GET index1/type1/_mapping

{
  "index1": {
    "mappings": {
      "type1": {
        "properties": {
          "content": {
            "type": "date"
          }
        }
      }
    }
  }
}

　　Adding a string type document gives an error. Because the field has been mapped to the date type, to add a string type, then you must modify the content type to string

PUT index1/type1/1
{
  "content":"I like Java"
}

{
  "error": {
    "root_cause": [
      {
        "type": "mapper_parsing_exception",
        "reason": "failed to parse [content]"
      }
    ],
    "type": "mapper_parsing_exception",
    "reason": "failed to parse [content]",
    "caused_by": {
      "type": "illegal_argument_exception",
      "reason": "Invalid format: \"I like Java\""
    }
  },
  "status": 400
}

　　Direct modification is unsuccessful and an error is reported

PUT index1/_mapping/type1
{
  "properties": {
    "content":{
      "type":"text"
    }
  }
}

{
  "error": {
    "root_cause": [
      {
        "type": "illegal_argument_exception",
        "reason": "mapper [content] of different type, current_type [date], merged_type [text]"
      }
    ],
    "type": "illegal_argument_exception",
    "reason": "mapper [content] of different type, current_type [date], merged_type [text]"
  },
  "status": 400
}

　　2. Demonstrate importing data from the old index into the new index

　　In the application, the application is connected to the alias. We only need to associate the alias with a different index to rebuild the index and ensure that the application does not need to be restarted.

　　1) alias index1 as index2

PUT /index1/_alias/index2

　　2) Create a new index

PUT /newindex
{
  "mappings": {
    "type1":{
      "properties": {
        "content":{
          "type":"text"
        }
      }
    }
  }
}

　　3) Perform the operation of querying the old index before importing into the new index

　　Because the amount of data in the old index may be very large, it is recommended to use the scroll api and reindex the data in a multi-threaded concurrent way when querying in batches. Each time the scroll queries a piece of data on a specified date, it can be handed over to a thread.

　　Example: Batch query old index index1

GET /index1/type1/_search?scroll=1m
{
  "query": {
    "match_all": {}
  },
  "sort": ["_doc"],
  "size":2
}

　　Example: Batch import new index newindex

POST /_bulk
{"index":{"_index":"newindex","_type":"type1","_id":1}}
{"content":"1988-08-08"}

　　4) Delete the alias association between index2 and index1, and increase the alias association between index2 and newindex

POST _aliases
{
  "actions": [
    {
      "remove": {
        "index": "index1",
        "alias": "index2"
      }
    },
    {
      "add": {
        "index": "newindex",
        "alias": "index2"
      }
  }
  ]
}

　　5) Query verification

GET index2/type1/_search

　　Query results, you can see that index2 is associated with a new index (the data in newindex is "content": "1988-08-08")

{
  "took": 3,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 1,
    "hits": [
      {
        "_index": "newindex",
        "_type": "type1",
        "_id": "1",
        "_score": 1,
        "_source": {
          "content": "1988-08-08"
        }
      }
    ]
  }
}