Return-Path: Delivered-To: apmail-lucene-solr-dev-archive@minotaur.apache.org Received: (qmail 86283 invoked from network); 23 Jul 2009 05:18:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 23 Jul 2009 05:18:07 -0000 Received: (qmail 47466 invoked by uid 500); 23 Jul 2009 05:19:12 -0000 Delivered-To: apmail-lucene-solr-dev-archive@lucene.apache.org Received: (qmail 47396 invoked by uid 500); 23 Jul 2009 05:19:12 -0000 Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-dev@lucene.apache.org Delivered-To: mailing list solr-dev@lucene.apache.org Received: (qmail 47386 invoked by uid 99); 23 Jul 2009 05:19:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Jul 2009 05:19:12 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=FS_REPLICA,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of noble.paul@gmail.com designates 209.85.216.193 as permitted sender) Received: from [209.85.216.193] (HELO mail-px0-f193.google.com) (209.85.216.193) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Jul 2009 05:19:04 +0000 Received: by pxi31 with SMTP id 31so414104pxi.29 for ; Wed, 22 Jul 2009 22:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; bh=RKoiwse7UycqUl0J/ug8wx0Ofn+e0cWjvxwVBVKoM34=; b=EObHhLKzrPJ7X3tq82Gai7pM5YbZvYE8afK5TvB0OMEV43G/PpQ1UAuAQrSEXnTHiG 5WNDBii+A9Y9WjC4SLT9U5RH0Z1kEqy139N3krwwtwEih4EdxLj/vDBgODz+Wi4swD4r lGgwOKRTYGBlcXCDoGNGL7BhstmYhK8dqiNO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=c8H0lzra9/HDOqq6jJKzCHc6G7kEEnKW9F6xEzA/mOlZjxHThbuo6i1k55t5vSwtGK RdI+FAsy3+tH6iboUF1H/03e/c8g+UckTp/GEW00Hu5Gwjrri/qUr7UEoymxdge2wZye WmG4DTColkyIBYIqC/ixIe1J9UZ/XD8sMgEcc= MIME-Version: 1.0 Sender: noble.paul@gmail.com Reply-To: noble.paul@gmail.com Received: by 10.140.177.13 with SMTP id z13mr1149452rve.9.1248326324120; Wed, 22 Jul 2009 22:18:44 -0700 (PDT) In-Reply-To: <85d3c3b60907221428s4cb62d5i31c5e7ede186ab8a@mail.gmail.com> References: <85d3c3b60907221428s4cb62d5i31c5e7ede186ab8a@mail.gmail.com> From: =?UTF-8?B?Tm9ibGUgUGF1bCDgtKjgtYvgtKzgtL/gtLPgtY3igI0gIOCkqOCli+CkrOCljeCks+CljQ==?= Date: Thu, 23 Jul 2009 10:48:24 +0530 X-Google-Sender-Auth: e57f182d176f0f82 Message-ID: <5e76b0ad0907222218q5cfb5997lc7c05d9da4002f4@mail.gmail.com> Subject: Re: Add replication push support? To: solr-dev@lucene.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org There is an issue already created for realtime replication https://issues.apache.org/jira/browse/SOLR-982 In general push based replication is more error prone because the master has to be aware of the state of each slave . it is difficault because a slave may go down at any time and may come up later or new slaves get added randomly. In a pull based replication the master is agnostic of the slaves and a slave can easily know his current state and take appropriate action. We can take a middle path. The slaves can register with the master for notifications for availability of new snapshots. This can be as good as a push based replication without the complexities associated with it. I have raised as issue already https://issues.apache.org/jira/browse/SOLR-1305 On Thu, Jul 23, 2009 at 2:58 AM, Jason Rutherglen wrote: > It would be useful to push snapshots as they are created from > the master to the slaves. I prefer this approach to constant > polling by slaves. Partially because the timing could be off on > the slave servers, the data is replicated, and the user sees > different snapshots? > > Something like a virtual 2 phase commit, where phase 1 is > replicate the new snapshots and load the searcher, phase two is > all slaves synchronously expose the new searcher. I'm also > wondering how we'll handle synchronous slaves with near realtime > search. > -- ----------------------------------------------------- Noble Paul | Principal Engineer| AOL | http://aol.com