lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Furkan KAMACI <>
Subject Re: SolrCloud: How to replicate shard of another machine for failover?
Date Wed, 26 Feb 2014 18:20:32 GMT

As Daniel mentioned it is just for "first time" and not a suggested
approach. However if you follow that way you can assign shards to machines.
On the other hand you can not change it after a time later with same


2014-02-26 15:53 GMT+02:00 Daniel Collins <>:

> This is only true the *first* time you start the cluster.  As mentioned
> earlier, the correct way to assign shards to cores is to use the collection
> API.  Failing that, you can start cores in a determined order, and the
> cores will assign themselves a shard/replica when they first start up.
>  From that point on, that mapping is defined in clusterstate.json, and will
> persist until you change it (delete cluster state or use collection/core
> API to move/remove a core.  It is a kludgy approach, that's why generally
> it isn't recommended for new starters to use, but by starting the first
> cores in a particular order you can get exactly the distribution you want.
> The collection API is good generally because it has some logic to
> distribute shards across machines, but you can't be very specific with it,
> you can't say "I want shard 1 on machine A, and its replicas on machines b,
> c & d). So we use the "start order" mechanism for our production systems,
> because we want to place shards on specific machines., We have 256 shards,
> so we want to know exactly what set of cores & machines is required in
> order to have a "full collection" of data.  As long as you are aware of the
> limitations of each mechanism, both work.
> On 26 February 2014 10:26, Oliver Schrenk <>
> wrote:
> > > There is a round robin process when assigning nodes at cluster. If you
> > want
> > > to achieve what you want you should change your Solr start up order.
> >
> > Well that is just weird. To bring a cluster to a reproducible state, I
> > have to bring the whole cluster down, and start it up again in a specific
> > order?
> >
> > What order do you suggest, to have a failover mechanism?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message