"Unable to upgrade the mappings for the index" error when migrating index from 1.x to 2.x

Elastic Stack Elasticsearch
1

I'm trying to snapshot an index in 1.7.2 and restore it in another cluster 2.4.0.
Snapshot created successfully and "published" as URL. When I try to restore on the new cluster I get:

{
_ "error": {_
_ "root_cause": [_
_ {_
_ "type": "snapshot_restore_exception",_
_ "reason": "[test_restore:snapshot1] cannot restore index [logstash-2016.10.11] because it cannot be upgraded"_
_ }_
_ ],_
_ "type": "snapshot_restore_exception",_
_ "reason": "[test_restore:snapshot1] cannot restore index [logstash-2016.10.11] because it cannot be upgraded",_
_ "caused_by": {_
_ "type": "illegal_state_exception",_
_ "reason": "unable to upgrade the mappings for the index [logstash-2016.10.11], reason: [mapper [timestamp] cannot be changed from type [string] to [date]]",_
_ "caused_by": {_
_ "type": "illegal_argument_exception",_
_ "reason": "mapper [timestamp] cannot be changed from type [string] to [date]"_
_ }_
_ }_
_ },_
_ "status": 500_
}

I ran migration checker for the index on the old cluster and it reports that everithing is green.

Old and new clusters configured very similar to ingest logs from logstash. If I look into documents in old and new cluster I don't see significant difference, example:

From old:

"_source": {
...
"@timestamp": "2016-10-18T14:00:38.486Z",
...
"fields": {
"@timestamp": [
1476799238486
]

From new:

"_source": {
...
"@timestamp": "2016-10-18T13:26:26.247Z",
...
"fields": {
"@timestamp": [
1476797186247
]

As I understood from other posts, I will need to reindex, so this seems like a migration checker issue, it didn't identify the issue...

2

try to stream it from one to the other with stream2es. If a valid template is setup on your target it will stream in and take the new schema.

3

Can you paste the GET /logstash-2016.10.11/_mapping output from your old 1.7.2 cluster?

I suspect the timestamp field is not actually a date, but rather a string. If that's true, the input data is actually a string and not directly upgradeable to a date.

4

logstash-2016.10.11 has been already deleted. I'm checking on another indices. I ran migration checker on two indices logstash-2016.10.17 and logstash-2016.10.19. The first one is OK (and migration itself was successful!), for the second I do got a warning:
Conflicting field mappings
Mapping for field log:timestamp conflicts with: syslog:timestamp. Check parameters: format, norms.enabled, type

Here are snippets for mapping.

========= for logstash-2016.10.17 =============

grep -C 3 timestamp mapping17.json
"enabled" : true
},
"properties" : {
"@timestamp" : {
"type" : "date",
"format" : "dateOptionalTime"
},

      "enabled" : true
    },
    "properties" : {
      "@timestamp" : {
        "type" : "date",
        "format" : "dateOptionalTime"
      },

--
}
}
},
"timestamp" : {
"type" : "string",
"norms" : {
"enabled" : false

      "enabled" : true
    },
    "properties" : {
      "@timestamp" : {
        "type" : "date",
        "format" : "dateOptionalTime"
      },

========= for mapping19.json =========

grep -C 3 timestamp mapping19.json
"enabled" : true
},
"properties" : {
"@timestamp" : {
"type" : "date",
"format" : "dateOptionalTime"
},

          }
        }
      },
      "timestamp" : {
        "type" : "date",
        "format" : "dateOptionalTime"
      },

--
"enabled" : true
},
"properties" : {
"@timestamp" : {
"type" : "date",
"format" : "dateOptionalTime"
},

          }
        }
      },
      "timestamp" : {
        "type" : "string",
        "norms" : {
          "enabled" : false

--
"enabled" : true
},
"properties" : {
"@timestamp" : {
"type" : "date",
"format" : "dateOptionalTime"
},

5

Could you gist the entire response up somewhere (I usually use Github's Gist service)? Hard to read with individual snippets, not enough context :slight_smile:

It looks like one of the "timestamp" fields is a string with norms enabled, while another is just a date, which is causing the exception. But importantly, they appear to be in different types (which is what's causing the error message "log:timestamp conflicts with: syslog:timestamp."), but in the same index. In ES 2.x+, types are no longer allowed to have conflicting mappings.

You can read more about that here:

Again, I'm not positive (would need to see the entire mapping in context to be sure), but that looks like a potential problem. So you'll need to verify that any types in a single index have a unified, non-conflicting mapping.