The API that enables master/slave is the ReplicationHandler, where the follower (slave) pulls index files from leader (master). This same API is used in SolrCloud for the PULL replica type, and also as a fallback for full recovery if transaction log is not enough. So I don’t see it going away anytime soon, even if the non-cloud deployment style is less promoted in the documentation.
Jan > 6. okt. 2020 kl. 16:25 skrev Oakley, Craig (NIH/NLM/NCBI) [C] > <craig.oak...@nih.gov.INVALID>: > >> it better not ever be depreciated. it has been the most reliable mechanism >> for its purpose > > I would like to know whether that is the consensus of Solr developers. > > We had been scrambling to move from Master/Slave to CDCR based on the > assertion that CDCR support would last far longer than Master/Slave support. > > Can we now assume safely that this assertion is now completely moot? Can we > now assume safely that Master/Slave is likely to be supported for the > foreseeable future? Or are we forced to assume that Master/Slave support will > evaporate shortly after the now-evaporated CDCR support? > > -----Original Message----- > From: David Hastings <hastings.recurs...@gmail.com> > Sent: Wednesday, September 30, 2020 3:10 PM > To: solr-user@lucene.apache.org > Subject: Re: Master/Slave > >> whether we should expect Master/Slave replication also to be deprecated > > it better not ever be depreciated. it has been the most reliable mechanism > for its purpose, solr cloud isnt going to replace standalone, if it does, > thats when I guess I stop upgrading or move to elastic > > On Wed, Sep 30, 2020 at 2:58 PM Oakley, Craig (NIH/NLM/NCBI) [C] > <craig.oak...@nih.gov.invalid> wrote: > >> Based on the thread below (reading "legacy" as meaning "likely to be >> deprecated in later versions"), we have been working to extract ourselves >> from Master/Slave replication >> >> Most of our collections need to be in two data centers (a read/write copy >> in one local data center: the disaster-recovery-site SolrCloud could be >> read-only). We also need redundancy within each data center for when one >> host or another is unavailable. We implemented this by having different >> SolrClouds in the different data centers; with Master/Slave replication >> pulling data from one of the read/write replicas to each of the Slave >> replicas in the disaster-recovery-site read-only SolrCloud. Additionally, >> for some collections, there is a desire to have local read-only replicas >> remain unchanged for querying during the loading process: for these >> collections, there is a local read/write loading SolrCloud, a local >> read-only querying SolrCloud (normally configured for Master/Slave >> replication from one of the replicas of the loader SolrCloud to both >> replicas of the query SolrCloud, but with Master/Slave disabled when the >> load was in progress on the loader SolrCloud, and with Master/Slave resumed >> after the loaded data passes QA checks). >> >> Based on the thread below, we made an attempt to switch to CDCR. The main >> reason for wanting to change was that CDCR was said to be the supported >> mechanism, and the replacement for Master/Slave replication. >> >> After multiple unsuccessful attempts to get CDCR to work, we ended up with >> reproducible cases of CDCR loosing data in transit. In June, I initiated a >> thread in this group asking for clarification of how/whether CDCR could be >> made reliable. This seemed to me to be met with deafening silence until the >> announcement in July of the release of Solr8.6 and the deprecation of CDCR. >> >> So we are left with the question whether we should expect Master/Slave >> replication also to be deprecated; and if so, with what is it expected to >> be replaced (since not with CDCR)? Or is it now sufficiently safe to assume >> that Master/Slave replication will continue to be supported after all >> (since the assertion that it would be replaced by CDCR has been >> discredited)? In either case, are there other suggested implementations of >> having a read-only SolrCloud receive data from a read/write SolrCloud? >> >> >> Thanks >> >> -----Original Message----- >> From: Shawn Heisey <apa...@elyograg.org> >> Sent: Tuesday, May 21, 2019 11:15 AM >> To: solr-user@lucene.apache.org >> Subject: Re: SolrCloud (7.3) and Legacy replication slaves >> >> 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 asking for problems if you try to combine legacy replication with >> SolrCloud. The two features are not guaranteed to work together. >> >> CDCR is your best bet. This replicates from one SolrCloud cluster to >> another. >> >> Thanks, >> Shawn >>