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
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
Understandable. Right now we have a large set up of solr 5.x servers that
has been doing great for years. But the time to upgrade has come, with
some things that we want that are not available in the 5.x branch. I
really like legacy ( master/slave) replication, for the reasons you stated,
but al
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
horizonta
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
