Elasticsearch 5.x升级至6.x启动失败：string类型映射异常求助

Hey there, let's tackle this mapping issue blocking your client upgrade step by step. First, let's anchor on the core error you're hitting when loading data in ES 6.8:

Caused by: org.elasticsearch.index.mapper.MapperParsingException: Failed to parse mapping [datapoint]: No handler for type [string] declared on field [batchId]

You've confirmed the expected mapping for batchId is {"type":"keyword"}—so why is this deprecated string type popping up for some clients? Let's break down the root cause and fixes.

1. Where is the string type coming from? #

ES 5.x used string as the default text type, which auto-generated both a text (for full-text search) and keyword (for exact matches) sub-field. But ES 6.x completely deprecated the string type, requiring explicit text/keyword declarations. Here are the most likely sources of the rogue mapping:

• Legacy 5.x indices with dynamic mappings: Some failing clients might connect to indices first created in 5.x without an explicit template. When the first batchId was written, ES dynamically generated a string mapping for it. Normal clients might use indices created with an explicit keyword mapping, or where early writes triggered a different (correct) dynamic setup.
• Subtle client configuration differences: Even if clients look identical, double-check for hidden code branches or config files that hardcode string for batchId when initializing indices or writing documents. Leftover 5.x legacy code is a common culprit here.
• Partial index upgrades: If you didn't reindex all 5.x indices to align with 6.x mapping rules before upgrading, some indices might still have the old string type buried in their mappings.

2. Fixing the 6.8 Load Failure #

Since you can't directly modify string to keyword in 5.x, and 6.x won't start due to the mapping error, here are two actionable paths:

Option A: Fix the Index in 5.x First #

If your 5.x cluster is still accessible, use this approach to clean up mappings before upgrading:

1. Create a new index with the correct mapping:

   PUT /new_healthy_index
   {
     "mappings": {
       "datapoint": {
         "properties": {
           "batchId": {"type": "keyword"},
           // Add all other fields from your existing mapping with their correct types
         }
       }
     }
   }
   

2. Reindex data from the problematic old index to the new one:

   POST _reindex
   {
     "source": {"index": "old_problematic_index"},
     "dest": {"index": "new_healthy_index"}
   }
   

3. Swap the indices: Delete the old index and alias the new one to match the original name:

   DELETE /old_problematic_index
   POST /_aliases
   {
     "actions": [{"add": {"index": "new_healthy_index", "alias": "old_problematic_index"}}]
   }
   

Now this index will load smoothly in 6.8, as it no longer uses the deprecated string type.

Option B: Force-Fix the Mapping in 6.8 (If You Can Start ES) #

If you can get ES 6.8 to start temporarily (e.g., by excluding the problematic index from loading), use this workaround:

1. Close the problematic index:

   PUT /problematic_index/_close
   

2. Update the mapping to replace string with keyword:

   PUT /problematic_index/_mapping/datapoint
   {
     "properties": {
       "batchId": {"type": "keyword"}
     }
   }
   

3. Open the index again:

   PUT /problematic_index/_open
   

Closed indices allow mapping modifications that are otherwise blocked on open indices, so this should resolve the loading error.

3. Preventing This in Future Upgrades #

• Enforce global mapping templates: Create a template for all indices that defines batchId (and other fields) with their correct types, and disable dynamic mapping with index.mapper.dynamic: false to stop ES from auto-generating problematic mappings.
• Audit all client code: Ensure every client uses identical mapping definitions when creating indices or writing documents. Even tiny differences in field declarations can cause mismatched mappings.
• Reindex all 5.x indices before 6.x upgrade: This ensures all deprecated string types are replaced with text/keyword before moving to a version that doesn't support them.

内容的提问来源于stack exchange，提问作者yBother