Return-Path: X-Original-To: apmail-lucene-solr-user-archive@minotaur.apache.org Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5299AFC82 for ; Wed, 17 Apr 2013 14:49:16 +0000 (UTC) Received: (qmail 49572 invoked by uid 500); 17 Apr 2013 14:49:12 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 49453 invoked by uid 500); 17 Apr 2013 14:49:12 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 49445 invoked by uid 99); 17 Apr 2013 14:49:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Apr 2013 14:49:12 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of markrmiller@gmail.com designates 209.85.212.47 as permitted sender) Received: from [209.85.212.47] (HELO mail-vb0-f47.google.com) (209.85.212.47) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Apr 2013 14:49:06 +0000 Received: by mail-vb0-f47.google.com with SMTP id x13so1317838vbb.20 for ; Wed, 17 Apr 2013 07:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=IK4xFlfbnv82bFq4D1DZZgSgi0CKF96zF4Iq4alSPAk=; b=cTOiQmV9yVT94eQsQfWLhruffW3njlmhVhzmqDPQDiaw19K3Y3IWowQUu4bryuACVe EruHFAHSLIxPMcV81zin+PwyYMYjtYWvJDYzH8USrBcyhNm4tPV7oggerITRG48OpkAw UZzyOMzMAmLE4hpg5dTPG7XMG1BdqEP6bGtxw6DzQskCVCEDTQm/dZJA0Iabz45dTbNu b/PGkmt5fy93X1KZr46yGmKWzyqh+pj3+XP/sGeejiU3amwwEGjGvHNJ7Q9Ea/1hqxHr R6YBnz0KNNXAtylpBjcPBud8GYPgxZOGfsXIwIVGNoU0cx/PbAMY4hdu58ZmyiZ1qJlL 9sFQ== X-Received: by 10.58.132.232 with SMTP id ox8mr5098085veb.45.1366210125319; Wed, 17 Apr 2013 07:48:45 -0700 (PDT) Received: from [192.168.1.10] (ool-18bf2b7d.dyn.optonline.net. [24.191.43.125]) by mx.google.com with ESMTPS id bi15sm5827686vdc.6.2013.04.17.07.48.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Apr 2013 07:48:44 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Push/pull model between leader and replica in one shard From: Mark Miller In-Reply-To: Date: Wed, 17 Apr 2013 10:48:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <33D35EAA-EEEF-47AB-AAA9-07312A90451D@gmail.com> References: <4b8fb256.17d83.13e115851d0.Coremail.suonayi2006@163.com> To: solr-user@lucene.apache.org X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on apache.org Thanks, the earlier presentation is done with KeyNote and the later = (more animation) is done with Tumult Hype. - Mark On Apr 17, 2013, at 3:43 AM, Furkan KAMACI = wrote: > Hej Mark; >=20 > What did you use to prepare your presentation, its really nice. >=20 > 2013/4/17 Furkan KAMACI >=20 >> Really nice presentation. >>=20 >>=20 >> 2013/4/17 Mark Miller >>=20 >>>=20 >>> On Apr 16, 2013, at 1:36 AM, SuoNayi wrote: >>>=20 >>>> Hi, can someone explain more details about what model is used to = sync >>> docs between the lead and >>>> replica in the shard? >>>> The model can be push or pull.Supposing I have only one shard that = has >>> 1 leader and 2 replicas, >>>> when the leader receives a update request, does it will scatter the >>> request to each available and active >>>> replica at first and then processes the request locally at last?In = this >>> case if the replicas are able to catch >>>> up with the leader can I think this is a push model that the leader >>> pushes updates to it's replicas? >>>=20 >>> Currently, the leader adds the doc locally and then sends it to all >>> replicas concurrently. >>>=20 >>>>=20 >>>>=20 >>>> What happens if a replica is behind the leader?Will the replica = pull >>> docs from the leader and keep >>>> a track of the coming updates from the lead in a log(called = tlog)?If so >>> when it complete pulling docs >>>> it will replay updates in the tlog at last? >>>=20 >>> If an update forwarded from a leader to a replica fails it's likely >>> because that replica died. Just in case, the leader will ask that = replica >>> to enter "recovery". >>>=20 >>> When a node comes up and is not a leader, it also enters "recovery". >>>=20 >>> Recovery tries to peersync from the leader, and if that fails (works = if >>> off by about 100 updates), it replicates the entire index. >>>=20 >>> If you are interested in more details on the SolrCloud architecture, = I've >>> given a few talks on it - two of them here: >>>=20 >>> http://vimeo.com/43913870 >>> http://www.youtube.com/watch?v=3DeVK0wLkLw9w >>>=20 >>> - Mark >>>=20 >>>=20 >>=20