Thanks, Jason. This is very helpful.

I should clarify though that I am not using CDCR currently with my
existing master-slave architecture. What I meant to say earlier was that we
will be relying heavily on the CDCR feature if we migrate from solr
master-slave architecture to solrcloud architecture. Are there any
alternatives to CDCR? AFAIK, if you want to replicate between different
data centers then CDCR is the only option. Also, when you say lot of
customers are using SolrCloud successfully, how are they working around the
CDCR situation? Do they not have any data center use cases? Is there some
list maintained somewhere where one can find which companies are using
SolrCloud successfully?



On Wed, May 27, 2020 at 9:27 AM Jason Gerlowski <gerlowsk...@gmail.com>
wrote:

> Hi Arnold,
>
> From what I saw in the community, CDCR saw an initial burst of
> development around when it was contributed, but hasn't seen much
> attention or improvement since.  So while it's been around for a few
> years, I'm not sure it's improved much in terms of stability or
> compatibility with other Solr features.
>
> Some of the bigger ticket issues still open around CDCR:
> - SOLR-11959 no support for basic-auth
> - SOLR-12842 infinite retry of failed update-requests (leads to
> sync/recovery problems)
> - SOLR-12057 no real support for NRT/TLOG/PULL replicas
> - SOLR-10679 no support for collection aliases
>
> These are in addition to other more architectural issues: CDCR can be
> a bottleneck on clusters with high ingestion rates, CDCR uses
> full-index-replication more than traditional indexing setups, which
> can cause issues with modern index sizes, etc.
>
> So, unfortunately, no real good news in terms of CDCR maturing much in
> recent releases.  Joel Bernstein filed a JIRA recently suggesting its
> removal entirely actually.  Though I don't think it's gone anywhere.
>
> That said, I gather from what you said that you're already using CDCR
> successfully with Master-Slave.  If none of these pitfalls are biting
> you in your current Master-Slave setup, you might not be bothered by
> them any more in SolrCloud.  Most of the problems with CDCR are
> applicable in master-slave as well as SolrCloud.  I wouldn't recommend
> CDCR if you were starting from scratch, and I still recommend you
> consider other options.  But since you're already using it with some
> success, it might be an orthogonal concern to your potential migration
> to SolrCloud.
>
> Best of luck deciding!
>
> Jason
>
> On Fri, May 22, 2020 at 7:06 PM gnandre <arnoldbron...@gmail.com> wrote:
> >
> > Thanks for this reply, Jason.
> >
> > I am mostly worried about CDCR feature. I am relying heavily on it.
> > Although, I am planning to use Solr 8.3. It has been long time since CDCR
> > was first introduced. I wonder what is the state of CDCR is 8.3. Is it
> > stable now?
> >
> > On Wed, Jan 22, 2020, 8:01 AM Jason Gerlowski <gerlowsk...@gmail.com>
> wrote:
> >
> > > Hi Arnold,
> > >
> > > The stability and complexity issues Mark highlighted in his post
> > > aren't just imagined - there are real, sometimes serious, bugs in
> > > SolrCloud features.  But at the same time there are many many stable
> > > deployments out there where SolrCloud is a real success story for
> > > users.  Small example, I work at a company (Lucidworks) where our main
> > > product (Fusion) is built heavily on top of SolrCloud and we see it
> > > deployed successfully every day.
> > >
> > > In no way am I trying to minimize Mark's concerns (or David's).  There
> > > are stability bugs.  But the extent to which those need affect you
> > > depends a lot on what your deployment looks like.  How many nodes?
> > > How many collections?  How tightly are you trying to squeeze your
> > > hardware?  Is your network flaky?  Are you looking to use any of
> > > SolrCloud's newer, less stable features like CDCR, etc.?
> > >
> > > Is SolrCloud better for you than Master/Slave?  It depends on what
> > > you're hoping to gain by a move to SolrCloud, and on your answers to
> > > some of the questions above.  I would be leery of following any
> > > recommendations that are made without regard for your reason for
> > > switching or your deployment details.  Those things are always the
> > > biggest driver in terms of success.
> > >
> > > Good luck making your decision!
> > >
> > > Best,
> > >
> > > Jason
> > >
>

Reply via email to