[From Found] Issue in .kibana index when checking upgrade to ES 2.0


(Erik Redding) #1

Continuing the discussion from Issue in .kibana index when checking upgrade to ES 2.0:


(Andres Fortier) #2

Hi Erik,
thanks for moving this forward. To add some more info in case it helps:

  • Hosted ES + Kibana in Found.
  • ES version: 1.7.1
  • Kibana version: 4.1.1

(Andres Fortier) #3

Bump. Anyone?


(Tanya Bragin) #4

Hi - Yeah, I've seen this myself. I am following up with the Kibana team on this.


(Tanya Bragin) #5

We've seen this type of mapping conflict resulting from a bug we had in 4.1.0, which affected Kibana users that imported objects from one Kibana instance into another: https://github.com/elastic/kibana/issues/3882 This bug was fixed in later versions of 4.1.x.

Unfortunately, Elasticsearch 2.0 introduced a breaking change that made mappings more strict (which is what this wizard is highlighting), users with .kibana index which is affected by this mapping conflict have no other choice on upgrade other than to delete and recreate the .kibana index. In terms of migrating your data, you can export all saved searches, visualizations, and dashboards in 4.1 and re-import them in 4.2. However, you will have to manually re-create all index patterns and advanced settings.

Please let me know if this helps you. We'll work to document this better in 4.2 release notes.


(Andres Fortier) #6

Hi Tanya,
thanks for clearing that out. We have temporarily stopped on the migration to focus in some urgent stuff, as this will take more time than expected. I will be getting back to that sooner than later, so I'll post here any updates in case it helps someone else.


(Suny Kim) #7

Hi, we had the same issue. Now our migration tool now tells us that we can go ahead (with caution). We created a new index .kibana-reindexed, with a mapping stolen from a newer .kibana index, and reindexed into it. The reindexing was done via logstash, similar to https://gist.github.com/markwalkom/8a7201e3f6ea4354ae06 ). We dropped the inconsistent .kibana, and reindexed back again. For some reason, the .kibana-reindexed also had issues. Which didn't matter, because the new .kibana doesn't.
Update: I don't recommend this. The migration to elasticsearch 2.2 worked, but the .kibana index is unusable and all objects (searches, visualisations, dashboards) are lost.


#8

We're having the same issue, we're stuck at this point
Conflicting field mappings
Mapping for field dashboard:hits conflicts with: search:hits. Check parameter: type


(system) #9