bq: Why not use classic replication between one node in the cluster and another node in the other cluster.
First of all in SolrCloud I'm pretty sure you can't do that, where "that" is have classic replication operate where the source was one SolrCloud and the destination is another SolrCloud cluster. There's all the replication logic between leaders and followers that you'd be interfering with. Step back for a minute though. Even if you set that up you'd be replicating your index across your admittedly slow DC/DC connection. The merging process creates new segments from various subsets of current segments, and the new segment would be copied to the backup DC. In some cases the entire index will be merged into a single segment (admittedly rarely). It seems far more bandwidth-efficient to just index the raw docs to each DC from the client. Best, Erick On Tue, May 10, 2016 at 6:52 AM, Abdel Belkasri <belka...@gmail.com> wrote: > Erick, > > That's not what I was going for. No code porting. I was thinking this: > Why not use classic replication between one node in the cluster and another > node in the other cluster? > something along this line. > > Thanks, > --Abdel. > > On Tue, May 10, 2016 at 12:21 AM, Erick Erickson <erickerick...@gmail.com> > wrote: > >> bq: How similar thing could be done in 4.9.1? >> >> That's not going to happen. More precisely, >> there is zero chance that anyone will take on that >> work unless it's a custom one-off that you >> hire done or develop internally. And even >> if someone took this on, it'd never be officially >> released. >> >> IOW, if you want to try backporting it on your own, >> have at it but that'll be completely unsupported. >> >> One thing people have done is create two >> independent clusters, complete to separate ZK >> ensembles and have the indexing client send >> updates to both DCs. At that point it also makes >> sense to have them both serve queries..... >> >> Another choice is to have your system-of-record >> replicated to both DCs, and have the indexing >> process run in both DCs from the local copy of >> the system-of-record to the local Solr >> clusters independently of each other. >> >> Best, >> Erick >> >> On Mon, May 9, 2016 at 12:31 PM, Abdel Belkasri <belka...@gmail.com> >> wrote: >> > Hi Alex, >> > >> > just started reading about CDCR, looks very promissing. Is this only in >> > 6.0? our PROD server are running 4.9.1 and we cannot upgrade just yet. >> How >> > similar thing could be done in 4.9.1? >> > >> > Thanks, >> > --Abdel >> > >> > On Mon, May 9, 2016 at 2:59 PM, Alexandre Rafalovitch < >> arafa...@gmail.com> >> > wrote: >> > >> >> Have you looked at Cross Data Center replication that's the new big >> >> feature in Solr 6.0? >> >> >> >> Regards, >> >> Alex. >> >> ---- >> >> Newsletter and resources for Solr beginners and intermediates: >> >> http://www.solr-start.com/ >> >> >> >> >> >> On 10 May 2016 at 02:13, Abdel Belkasri <belka...@gmail.com> wrote: >> >> > Hi there, >> >> > >> >> > we have the main site setup as follows: >> >> > solrCould: >> >> > App --> smart Client (solrj) --> ensemble of zookeeper --> SolrCloud >> Noes >> >> > (with slice/shard/recplica....) >> >> > Works fine. >> >> > >> >> > On the DR site we have a mirror setup, how can we keep the two site in >> >> > sync, so that if something happened we point the app to DR and get >> back >> >> up >> >> > and running? >> >> > >> >> > Note: making zookeeper span the two sites is not an option because of >> >> > network latency. >> >> > >> >> > We are looking for replication (kind of master-slave that exists in >> Solr >> >> > classic)...how that is achieved in SolrCloud? >> >> > >> >> > Thanks, >> >> > --Abdel. >> >> >> > >> > >> > >> > -- >> > Abdel K. Belkasri, PhD >> > > > > -- > Abdel K. Belkasri, PhD