Hi, maybe its clearer with an example. Imagine I have 5 data node, 5 river nodes and 10 rivers running on these 5 river nodes. The data nodes are called N1 to N5, these have river set to false. The river nodes are called R1 to R5, these have river set to true. After creating the rivers or after a full cluster restart everything is nicely balanced, each of the 5 river nodes has exactly 2 rivers.
I then want to restart the river nodes R1-R5 without restarting N1-N5. The problem here is that the first node that comes up again and joins the cluster gets all the 10 rivers assigned. I have no issue with having a small imbalance between the number of rivers running per river node, but I want to prevent that all the rivers run on one node, therefore I wanted to turn off or throttle river allocation before doing the partial cluster restart and turing it back on, when all (or most) of the node are up again. If that does not work, I could still use the 'hacky' solution, which does: Restart R1-R5. Node R1 (as an example) comes up first and gets all the 10 rivers. Node R2-R5 come up and get no rivers (as R1 already has all of them) Restart R1. Then R2-R5 get the rivers distributed among them, which is acceptable for my use-case, even if R1 has none. But I somehow don't like the idea of restarting R1 twice just for redistributing the rivers, so I was wondering if there is a better solution, like adding a transient cluster setting which skips allocation. Thanks for any ideas, Mechel On Tue, Jan 14, 2014 at 4:31 PM, joergpra...@gmail.com <joergpra...@gmail.com> wrote: > Maybe I do not understand fully, but you say "as it is the only node with > river set to true" - this means to me there is only this one node that > should run river instances - and then you have observed the RiversRouter > redistributes "uniformly" rivers to other nodes? I'm a bit confused where > you want to see river instances running. > > The current river concept is that a river instance is running as a singleton > on the node where it has been started, and in case of a node failure (or > shutdown), another node takes over. There are several challenges with that > concept. > > So I'm afraid that disabling river allocation will add more challenges to > the automatic failover idea. > > Jörg > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/CAKdsXoG%2BYR0sNgCv-%3Dx7WbzSjasPGuonzP_%2BZ1srsKh49wR6pA%40mail.gmail.com. > For more options, visit https://groups.google.com/groups/opt_out. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAH0sEYhiqp0qx0VcEVwaqyegSxNv032cRsbuHMjPH16ogrcVUw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
