# Elasticsearch is not rebalancing **URL:** \ **Category:** Elasticsearch\ **Created:** [November 3, 2014, 12:05pm UTC](https://discuss.elastic.co/t/elasticsearch-is-not-rebalancing/20539 "2014-11-03T12:05:14Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Bernd\_Fehling\_2](https://avatars.discourse-cdn.com/v4/letter/b/d07c76/32.png) [@Bernd\_Fehling\_2](https://discuss.elastic.co/u/Bernd_Fehling_2)\ **Post date:** [November 3, 2014, 12:05pm UTC](https://discuss.elastic.co/t/elasticsearch-is-not-rebalancing/20539/1 "2014-11-03T12:05:14Z")
I have an index with 4 shards and 1 replica so that each server has 1 primary and 1 replica. If the system is set up everything is well distributed. If 1 server goes down the primary is moved to one of the replicas but if the server comes up again the system is not rebalanced. The primary says where it is and does not move back to its origin server. Any idea whats wrong, is there a setting for this? Regards Bernd -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [November 3, 2014, 12:09pm UTC](https://discuss.elastic.co/t/elasticsearch-is-not-rebalancing/20539/2 "2014-11-03T12:09:43Z")
There is nothing wrong, this is expected behavior. It does not matter where the primaries are. Primaries and replica have exactly the same information about cluster state and do exactly the same amount of work. The only exception is that primary shards do the write operation first before sending them to replicas. So there is no need to "rebalance". Best, Jörg On Mon, Nov 3, 2014 at 1:05 PM, Bernd Fehling [bernd.fehling@gmail.com](mailto:bernd.fehling@gmail.com) wrote: > I have an index with 4 shards and 1 replica so that each server has 1 > primary and 1 replica. > If the system is set up everything is well distributed. > If 1 server goes down the primary is moved to one of the replicas but if > the server comes up > again the system is not rebalanced. The primary says where it is and does > not move > back to its origin server. > Any idea whats wrong, is there a setting for this? > > Regards > Bernd > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22%40googlegroups.com) > [https://groups.google.com/d/msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22%40googlegroups.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFsUoEbTCqCktpj1S8TyY-KvN9JE-e2Edru5LH81FByzg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFsUoEbTCqCktpj1S8TyY-KvN9JE-e2Edru5LH81FByzg%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Bernd\_Fehling\_2](https://avatars.discourse-cdn.com/v4/letter/b/d07c76/32.png) [@Bernd\_Fehling\_2](https://discuss.elastic.co/u/Bernd_Fehling_2)\ **Post date:** [November 3, 2014, 12:32pm UTC](https://discuss.elastic.co/t/elasticsearch-is-not-rebalancing/20539/3 "2014-11-03T12:32:58Z")
Exactly what I see, that one server which has now 2 primaries has higher load because of two primaries writing while bulk loading. And this is the cause why I want to have a rebalance and the primary back to its origin to have a well distributed load. So no chance to realize this with ES? But if the index is generated I get a well distributed system. Or is this just luck and generating the index several times I get always a different result? Regards, Bernd Am Montag, 3. November 2014 13:09:53 UTC+1 schrieb Jörg Prante: > There is nothing wrong, this is expected behavior. > > It does not matter where the primaries are. Primaries and replica have > exactly the same information about cluster state and do exactly the same > amount of work. The only exception is that primary shards do the write > operation first before sending them to replicas. > > So there is no need to "rebalance". > > Best, > > Jörg > > On Mon, Nov 3, 2014 at 1:05 PM, Bernd Fehling \<[bernd....@gmail.com](mailto:bernd....@gmail.com) > \\> wrote: > > > I have an index with 4 shards and 1 replica so that each server has 1 > > primary and 1 replica. > > If the system is set up everything is well distributed. > > If 1 server goes down the primary is moved to one of the replicas but if > > the server comes up > > again the system is not rebalanced. The primary says where it is and does > > not move > > back to its origin server. > > Any idea whats wrong, is there a setting for this? > > > > Regards > > Bernd > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/36b7cba2-7d2c-49c0-8323-944961289f10%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/36b7cba2-7d2c-49c0-8323-944961289f10%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [November 3, 2014, 12:43pm UTC](https://discuss.elastic.co/t/elasticsearch-is-not-rebalancing/20539/4 "2014-11-03T12:43:04Z")
I think the write load issue has not a relation to primary/replica shard setting. All writes should go to all shards of an index. If you have a shard count that is not dividable by the count of nodes, write load could be skewed, so one or more nodes have more work than others. This can be fixed at index creation time by setting a shard number so that each node carries the same number of shards for an index. Best, Jörg On Mon, Nov 3, 2014 at 1:32 PM, Bernd Fehling [bernd.fehling@gmail.com](mailto:bernd.fehling@gmail.com) wrote: > Exactly what I see, that one server which has now 2 primaries has higher > load because of two primaries writing while bulk loading. > And this is the cause why I want to have a rebalance and the primary back > to its origin to have a well distributed load. > So no chance to realize this with ES? > > But if the index is generated I get a well distributed system. > Or is this just luck and generating the index several times I get always a > different result? > > Regards, > Bernd > > Am Montag, 3. November 2014 13:09:53 UTC+1 schrieb Jörg Prante: > > > There is nothing wrong, this is expected behavior. > > > > It does not matter where the primaries are. Primaries and replica have > > exactly the same information about cluster state and do exactly the same > > amount of work. The only exception is that primary shards do the write > > operation first before sending them to replicas. > > > > So there is no need to "rebalance". > > > > Best, > > > > Jörg > > > > On Mon, Nov 3, 2014 at 1:05 PM, Bernd Fehling [bernd....@gmail.com](mailto:bernd....@gmail.com) > > wrote: > > > > > I have an index with 4 shards and 1 replica so that each server has 1 > > > primary and 1 replica. > > > If the system is set up everything is well distributed. > > > If 1 server goes down the primary is moved to one of the replicas but if > > > the server comes up > > > again the system is not rebalanced. The primary says where it is and > > > does not move > > > back to its origin server. > > > Any idea whats wrong, is there a setting for this? > > > > > > Regards > > > Bernd > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22% > > > [40googlegroups.com](http://40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/36b7cba2-7d2c-49c0-8323-944961289f10%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/36b7cba2-7d2c-49c0-8323-944961289f10%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/36b7cba2-7d2c-49c0-8323-944961289f10%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/36b7cba2-7d2c-49c0-8323-944961289f10%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHTHJVLmyFzzWP5R\_1YchMA41wS9J%3D60ipdVgsRoXYf3w%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHTHJVLmyFzzWP5R_1YchMA41wS9J%3D60ipdVgsRoXYf3w%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Bernd\_Fehling\_2](https://avatars.discourse-cdn.com/v4/letter/b/d07c76/32.png) [@Bernd\_Fehling\_2](https://discuss.elastic.co/u/Bernd_Fehling_2)\ **Post date:** [November 3, 2014, 1:01pm UTC](https://discuss.elastic.co/t/elasticsearch-is-not-rebalancing/20539/5 "2014-11-03T13:01:02Z")
I don't understand what you are trying to tell me but to sum it up, a rebalancing of primary nodes with ES is not possible. -1 for ES. So I have to stick with SOLR which can rebalance leaders " /admin/collections?action=REBALANCELEADERS" Regards Bernd Am Montag, 3. November 2014 13:43:11 UTC+1 schrieb Jörg Prante: > I think the write load issue has not a relation to primary/replica shard > setting. All writes should go to all shards of an index. > > If you have a shard count that is not dividable by the count of nodes, > write load could be skewed, so one or more nodes have more work than > others. > > This can be fixed at index creation time by setting a shard number so that > each node carries the same number of shards for an index. > > Best, > > Jörg > > On Mon, Nov 3, 2014 at 1:32 PM, Bernd Fehling \<[bernd....@gmail.com](mailto:bernd....@gmail.com) > \\> wrote: > > > Exactly what I see, that one server which has now 2 primaries has higher > > load because of two primaries writing while bulk loading. > > And this is the cause why I want to have a rebalance and the primary back > > to its origin to have a well distributed load. > > So no chance to realize this with ES? > > > > But if the index is generated I get a well distributed system. > > Or is this just luck and generating the index several times I get always > > a different result? > > > > Regards, > > Bernd > > > > Am Montag, 3. November 2014 13:09:53 UTC+1 schrieb Jörg Prante: > > > > > There is nothing wrong, this is expected behavior. > > > > > > It does not matter where the primaries are. Primaries and replica have > > > exactly the same information about cluster state and do exactly the same > > > amount of work. The only exception is that primary shards do the write > > > operation first before sending them to replicas. > > > > > > So there is no need to "rebalance". > > > > > > Best, > > > > > > Jörg > > > > > > On Mon, Nov 3, 2014 at 1:05 PM, Bernd Fehling [bernd....@gmail.com](mailto:bernd....@gmail.com) > > > wrote: > > > > > > > I have an index with 4 shards and 1 replica so that each server has 1 > > > > primary and 1 replica. > > > > If the system is set up everything is well distributed. > > > > If 1 server goes down the primary is moved to one of the replicas but > > > > if the server comes up > > > > again the system is not rebalanced. The primary says where it is and > > > > does not move > > > > back to its origin server. > > > > Any idea whats wrong, is there a setting for this? > > > > > > > > Regards > > > > Bernd > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22% > > > > [40googlegroups.com](http://40googlegroups.com) > > > > [https://groups.google.com/d/msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/e2bb0dad-8540-4f34-87a1-253f984c2d22%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/36b7cba2-7d2c-49c0-8323-944961289f10%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/36b7cba2-7d2c-49c0-8323-944961289f10%40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/36b7cba2-7d2c-49c0-8323-944961289f10%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/36b7cba2-7d2c-49c0-8323-944961289f10%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/4a5ba3bd-7a65-4bb4-a054-e573d587b955%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/4a5ba3bd-7a65-4bb4-a054-e573d587b955%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**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, 12:52am UTC](https://discuss.elastic.co/t/elasticsearch-is-not-rebalancing/20539/6 "2017-07-06T00:52:30Z")