# What does "re-syncing mappings with cluster state for types" on startup mean? **URL:** \ **Category:** Elasticsearch\ **Created:** [November 21, 2011, 4:48pm UTC](https://discuss.elastic.co/t/what-does-re-syncing-mappings-with-cluster-state-for-types-on-startup-mean/5928 "2011-11-21T16:48:55Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Matt1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/matt1/32/2986_2.png) [@Matt1](https://discuss.elastic.co/u/Matt1)\ **Post date:** [November 21, 2011, 4:48pm UTC](https://discuss.elastic.co/t/what-does-re-syncing-mappings-with-cluster-state-for-types-on-startup-mean/5928/1 "2011-11-21T16:48:55Z")
Hey all, I have a cluster with a couple of hundred indices, each one between tens of megs to hundreds of megs and tens of thousands to hundreds of thousands of documents. I was doing an upgrade from 18.2 to 18.4, and it took a solid 20+ minutes to load up, with messages like the following: re-syncing mappings with cluster state for types for each index, which would take between a few seconds up to a minute or two. I also get missing shard exceptions like the following, on indices which were closed before the shutdown: [2011-11-21 11:41:19,510][DEBUG][action.admin.indices.status] [Paragon] [index1][0], node[smWjnoWoQza9C-ql5hpGig], [P], s[INITIALIZING]: Failed to execute [org.elasticsearch.action.admin.indices.status.IndicesStatusRequest@38b4a41] org.elasticsearch.index.IndexShardMissingException: [index1][0] missing at org.elasticsearch.index.service.InternalIndexService.shardSafe(InternalIndexService.java:177) at org.elasticsearch.action.admin.indices.status.TransportIndicesStatusAction.shardOperation(TransportIndicesStatusAction.java:135) at org.elasticsearch.action.admin.indices.status.TransportIndicesStatusAction.shardOperation(TransportIndicesStatusAction.java:58) at org.elasticsearch.action.support.broadcast.TransportBroadcastOperationAction$AsyncBroadcastAction.performOperation(TransportBroadcastOperationAction.java:232) at org.elasticsearch.action.support.broadcast.TransportBroadcastOperationAction$AsyncBroadcastAction.performOperation(TransportBroadcastOperationAction.java:210) at org.elasticsearch.action.support.broadcast.TransportBroadcastOperationAction$AsyncBroadcastAction$1.run(TransportBroadcastOperationAction.java:186) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) Are the exceptions something I need to worry about? Can somebody explain what it's doing during this time? Lastly, what can I do to eliminate/minimize this time? Cheers for any help or explanation anybody can provide! Matt ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [November 21, 2011, 6:41pm UTC](https://discuss.elastic.co/t/what-does-re-syncing-mappings-with-cluster-state-for-types-on-startup-mean/5928/2 "2011-11-21T18:41:47Z")
Usually, this "re-sync" should not happen, but, sometimes the order at which mappings are serialized was wrong, and in order to fix it, the mappings needs to "resync". There was a change like that in 0.18.3/4, if you used root level mapping elements (like \_source / \_size). This will be "heavy" the more indices / types you have, since it needs to be applied to all of them, but, this change only happens when an unordered part of the serialization is found, which I hope we nailed them by now. Regarding the indices status, you can ignore it, it should be harmless. On Mon, Nov 21, 2011 at 6:48 PM, Matt [matt.chu@gmail.com](mailto:matt.chu@gmail.com) wrote: > Hey all, > > I have a cluster with a couple of hundred indices, each one between tens > of megs to hundreds of megs and tens of thousands to hundreds of thousands > of documents. I was doing an upgrade from 18.2 to 18.4, and it took a solid > 20+ minutes to load up, with messages like the following: > > re-syncing mappings with cluster state for types > > for each index, which would take between a few seconds up to a minute or > two. I also get missing shard exceptions like the following, on indices > which were closed before the shutdown: > > [2011-11-21 11:41:19,510][DEBUG][action.admin.indices.status] [Paragon] > [index1][0], node[smWjnoWoQza9C-ql5hpGig], [P], s[INITIALIZING]: Failed to > execute > [org.elasticsearch.action.admin.indices.status.IndicesStatusRequest@38b4a41 > ] > org.elasticsearch.index.IndexShardMissingException: [index1][0] missing > at > org.elasticsearch.index.service.InternalIndexService.shardSafe(InternalIndexService.java:177) > at > org.elasticsearch.action.admin.indices.status.TransportIndicesStatusAction.shardOperation(TransportIndicesStatusAction.java:135) > at > org.elasticsearch.action.admin.indices.status.TransportIndicesStatusAction.shardOperation(TransportIndicesStatusAction.java:58) > at > org.elasticsearch.action.support.broadcast.TransportBroadcastOperationAction$AsyncBroadcastAction.performOperation(TransportBroadcastOperationAction.java:232) > at > org.elasticsearch.action.support.broadcast.TransportBroadcastOperationAction$AsyncBroadcastAction.performOperation(TransportBroadcastOperationAction.java:210) > at > org.elasticsearch.action.support.broadcast.TransportBroadcastOperationAction$AsyncBroadcastAction$1.run(TransportBroadcastOperationAction.java:186) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > > Are the exceptions something I need to worry about? Can somebody explain > what it's doing during this time? Lastly, what can I do to > eliminate/minimize this time? > > Cheers for any help or explanation anybody can provide! > > Matt ---
**Author:** ![Matt1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/matt1/32/2986_2.png) [@Matt1](https://discuss.elastic.co/u/Matt1)\ **Post date:** [November 22, 2011, 3:44am UTC](https://discuss.elastic.co/t/what-does-re-syncing-mappings-with-cluster-state-for-types-on-startup-mean/5928/3 "2011-11-22T03:44:31Z")
I see. Is this a fix in master, that will go out as part of the next point release (0.18.5)? Thanks for the explanation! ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [November 22, 2011, 8:01am UTC](https://discuss.elastic.co/t/what-does-re-syncing-mappings-with-cluster-state-for-types-on-startup-mean/5928/4 "2011-11-22T08:01:32Z")
No, its not a fix, I explained the change in 0.18.3, why mappings might need to be "re-sync'ed", which is a one time cost when upgrading to 0.18 (and only applicable in certain situations, depending on your mappings). On Tue, Nov 22, 2011 at 5:44 AM, Matt [matt.chu@gmail.com](mailto:matt.chu@gmail.com) wrote: > I see. Is this a fix in master, that will go out as part of the next point > release (0.18.5)? Thanks for the explanation! ---
**Author:** ![Matt1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/matt1/32/2986_2.png) [@Matt1](https://discuss.elastic.co/u/Matt1)\ **Post date:** [November 22, 2011, 3:04pm UTC](https://discuss.elastic.co/t/what-does-re-syncing-mappings-with-cluster-state-for-types-on-startup-mean/5928/5 "2011-11-22T15:04:12Z")
Ok, ok, I think I got it: because I jumped from 0.17.8 to 0.18.2 then to 0.18.4, I saw this happen twice. Now, if I understand correctly, subsequent restarts should no longer have to go through this. Is that about right? ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [November 22, 2011, 3:39pm UTC](https://discuss.elastic.co/t/what-does-re-syncing-mappings-with-cluster-state-for-types-on-startup-mean/5928/6 "2011-11-22T15:39:35Z")
Yea, you got it. The way a node checks if mapping have changed is using a binary check of the serialized format of the mappings (regenerated by ES, to make sure its ordered and consistent). On Tue, Nov 22, 2011 at 5:04 PM, Matt [matt.chu@gmail.com](mailto:matt.chu@gmail.com) wrote: > Ok, ok, I think I got it: because I jumped from 0.17.8 to 0.18.2 then to > 0.18.4, I saw this happen twice. Now, if I understand correctly, subsequent > restarts should no longer have to go through this. Is that about right? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:47am UTC](https://discuss.elastic.co/t/what-does-re-syncing-mappings-with-cluster-state-for-types-on-startup-mean/5928/7 "2017-07-06T03:47:50Z")