The update router would also need to look for failures indexing at each leader, then re-read the cluster state to see if the leader had changed. Also re-send any failed updates, and so on.
wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Feb 11, 2019, at 11:07 AM, lstusr 5u93n4 <lstusr...@gmail.com> wrote: > > Hi Boban, > > First of all: I agree with Walter here. Because the bottleneck is during > indexing on the leader, a basic round robin load balancer will perform just > as well as a custom solution. With far less headache. A custom solution > will be far more work than it's worth. > > But, should you really want to write this yourself, you can get all of the > information you need from zookeeper, from the path: > > <zkroot>/collections/<collection_name>/state.json > > There, for each shard you'll see: > - the "range" parameter that tells you which subset of documents this > shard is responsible for (see > https://lucene.apache.org/solr/guide/7_6/shards-and-indexing-data-in-solrcloud.html#document-routing > for details on routing) > - the list of all replicas. On each replica it will tell you: > - the host name (base_url) > - if it is the leader (has the property leader: true) > > So your go-based solution would be to watch the state.json file from > zookeeper, and build up a function that, given the proper routing structure > for your document (the hash of the id by default, I think) will return the > hostname of the replica that's the leader. > > Kyle > > On Mon, 11 Feb 2019 at 13:30, Boban Acimovic <b...@it-agenten.com> wrote: > >> Like I said before, nginx is not a load balancer or at least not a clever >> load balancer. It does not talk to ZK. Please give me advanced solutions. >> >> >> >> >>> On 11. Feb 2019, at 18:32, Walter Underwood <wun...@wunderwood.org> >> wrote: >>> >>> I haven’t used Kubernetes, but a web search for “helm nginx” seems to >> give some useful pages. >>> >>> wunder >>> Walter Underwood >>> wun...@wunderwood.org >>> http://observer.wunderwood.org/ (my blog) >>> >>>> On Feb 11, 2019, at 9:13 AM, Davis, Daniel (NIH/NLM) [C] < >> daniel.da...@nih.gov> wrote: >>>> >>>> I think that the container orchestration framework takes care of that >> for you, but I am not an expert. In Kubernetes, NGINX is often the Ingress >> controller, and as long as the services are running within the Kubernetes >> cluster, it can also serve as a load balancer, AFAICT. In Kubernetes, a >> "Load Balancer" appears to be a concept for accessing services outside the >> cluster. >>>> >>>> I presume you are using Kubernetes because of your reference to helm, >> but for what it's worth, here's an official haproxy image - >> https://hub.docker.com/_/haproxy >>
