lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sundaram, Dinesh" <Dinesh.Sunda...@mastercard.com>
Subject RE: Solrcloud with Master/Slave
Date Fri, 05 Jan 2018 17:12:24 GMT
Thanks Shawn and Erick. I guess now we are in same track. So two independent solrcloud nodes
are allowed to sync up via master/slave method without referring any external/embedded zookeepers.
I need to use -cloud in the command while starting solr otherwise I'm not able to see the
admin console. That console is really cool for tracking solr activities.


Dinesh Sundaram
MBS Platform Engineering

Mastercard



-----Original Message-----
From: Erick Erickson [mailto:erickerickson@gmail.com]
Sent: Friday, January 5, 2018 10:58 AM
To: solr-user <solr-user@lucene.apache.org>
Subject: Re: Solrcloud with Master/Slave

One slight correction. Solr will run perfectly fine with a single ZooKeeper.
The recommendation for 3 is that running with a single ZooKeeper creates a single point of
failure, i.e. if that node goes down for any reason your Solr cluster won't be able to update
anything at all. You can still query, maybe, for a while.

Two ZooKeepers will also run, but as Shawn says that's essentially totally wasting one of
them as it doesn't buy you anything and makes your system _less_ robust.

FWIW,
Erick

On Fri, Jan 5, 2018 at 7:57 AM, Shawn Heisey <apache@elyograg.org> wrote:

> On 1/4/2018 9:01 AM, Sundaram, Dinesh wrote:
> > Thanks Shawn for your prompt response. Assume I have solrcloud A
> > server
> with 1 node runs on 8983 port and solrcloud B server with 1 node runs
> on 8983, here I want to synch up the collection between solrcloud A
> and B using the below replication handler. Is this advisable to use at
> the solrcloud B ?
> >
> > <requestHandler name="/replication" class="solr.ReplicationHandler" >
> >     <lst name="slave">
> >         <str name="masterUrl">https://urldefense.proofpoint.com/v2/url?u=http-3A__solrcloudA-3A8983_solr_-24-257Bsolr&d=DwIBaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gCFZFMR7y0gzhIBFz1lKTqHFMl-3R6gq7ojE0Eam2Eg&m=3jqDjqHZnl2sdIUhYF4uQBQQBHzg6zEshRmcDCPcWvM&s=tEY-h4ureY9H6AkD-b9wGLmOfYQ3NJp3Rg37lNBuPgY&e=.
> core.name}/replication</str>
> >         <str name="pollInterval">00:00:20</str>
> >     </lst>
> > </requestHandler>
>
> One of the things I said in my last reply, at the beginning of a
> paragraph so it should have been quite prominent, was "you can't mix
> master-slave replication and SolrCloud."  What part of that was not clear?
>
> You need to be running standalone mode (not cloud) if you want to use
> master-slave replication.
>
> When things are set up correctly, SolrCloud will automatically keep
> multiple replicas in sync, and copy the index to new replicas when
> they are created.  There is no need to manage it with replication config.
> For replicating from one SolrCloud cluster to another, there is CDCR
> as Erick described.
>
> Another thing Erick mentioned:  What you actually have when you start
> Solr the way you did is two completely independent SolrCloud clusters,
> each of which only has one Solr server.  Each solr instance is running
> a zookeeper server embedded within it.  There is no redundancy or
> fault tolerance of any kind.
>
> If you want to run a fault-tolerant SolrCloud, you will need three
> separate servers.  The smallest possible setup would have both Solr
> and ZooKeeper running on two of those servers (as separate processes).
> The Solr instances would be started with a -z option (or the ZKHOST
> environment variable) to locate the three ZK servers, and without the
> -cloud option.  The third server, which can be a much smaller system,
> would only run ZooKeeper.  You may also need a load balancer,
> depending on what software your clients are using.
>
> The requirement of three servers comes from ZooKeeper, not Solr.  A
> two-server ZK ensemble is actually *less* reliable than a single
> server, so it's not recommended.  I don't know if they even allow such
> a setup to work.
>
> Thanks,
> Shawn
>
>
CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the
intended recipient and may contain information that is privileged, confidential or exempt
from disclosure under applicable law. If you are not the intended recipient, any disclosure,
distribution or other use of this e-mail message or attachments is prohibited. If you have
received this e-mail message in error, please delete and notify the sender immediately. Thank
you.
Mime
View raw message