What Jan said. I wanted to add that the replication API also makes use of it. A little-known fact: you can use the replication API in SolrCloud _without_ configuring anything in solrconfig.xml. You can specify the URL to pull from on the fly in the command….
Best, Erick > On Oct 8, 2020, at 2:54 AM, Jan Høydahl <jan....@cominvent.com> wrote: > > 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 >>> >
