up an existing SolrCloud cluster as the master for
>> legacy replication to a slave server or two? It looks like another option
>> is to use Uni-direction CDCR, but not sure what is the best option in this
>> case.
>
> You're asking for problems if you try to combin
On 5/21/2019 8:48 AM, Michael Tracey wrote:
Is it possible set up an existing SolrCloud cluster as the master for
legacy replication to a slave server or two? It looks like another option
is to use Uni-direction CDCR, but not sure what is the best option in this
case.
You're askin
Is it possible set up an existing SolrCloud cluster as the master for
legacy replication to a slave server or two? It looks like another option
is to use Uni-direction CDCR, but not sure what is the best option in this
case.
--
Michael Tracey
1a> Replication pulls down changed segments, which includes _changed_
segments. Say I have 10 segments in my index and they all get merged
into a single segment that now contains the entire index. Then the
changed segment is replicated.
1b> If you're polling interval is such that all the segments
Hi,
I have two questions regarding legacy master /slave node replication
architecture.
We noticed that slave node does full sync time to time.
1. What type of event or configuration does trigger the full sync in slave
node?
I can not locate exact time and frequency from the logs. Please let
Yeah, much as I love SolrCloud (and make most of my living working
with it), it does have its complexities.
My rule of thumb is that you really want to consider SolrCloud when
you start having to shard or need NRT
searching.
You trade the complexity of maintaining your own sharding etc. for the
c
On 12/15/2017 12:12 PM, David Hastings wrote:
Also the complexity of adding another 3
or more machines just to do nothing but ZK stuff was getting out of hand.
You can run ZK on the same machines that are running Solr. The only
strong recommendation that I would make is that it should be a
c
ram with 2TB SSDs, each, these were not cheap and are
pretty fast with standalone solr. Also the complexity of adding another 3
or more machines just to do nothing but ZK stuff was getting out of hand.
if its not broken, im not about to fix it
In any case im glad to hear legacy replication will
I love legacy replication. It is simple and bulletproof. Loose coupling for the
win! We only run Solr Cloud when we need sharding or NRT search. Loose coupling
is a very, very good thing in distributed systems.
Adding a replica (new slave) is trivial. Clone an existing one. This makes
There's pretty much zero chance that it'll go away, too much current
and ongoing functionality that depends on it.
1> old-style replication has always been used for "full sync" in
SolrCloud when peer sync can't be done.
2> The new TLOG and PULL replica types are a marriage of old-style
master/sla
So i dont step on the other thread, I want to be assured whether or not
legacy master/slave/repeater replication will continue to be supported in
future solr versions. our infrastructure is set up for this and all the HA
redundancies that solrcloud provides we have already spend a lot of time
and
11 matches
Mail list logo
