Return-Path: X-Original-To: apmail-lucene-general-archive@www.apache.org Delivered-To: apmail-lucene-general-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 37E5A9C77 for ; Wed, 14 Dec 2011 22:00:33 +0000 (UTC) Received: (qmail 62990 invoked by uid 500); 14 Dec 2011 22:00:32 -0000 Delivered-To: apmail-lucene-general-archive@lucene.apache.org Received: (qmail 62937 invoked by uid 500); 14 Dec 2011 22:00:32 -0000 Mailing-List: contact general-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@lucene.apache.org Delivered-To: mailing list general@lucene.apache.org Received: (qmail 62929 invoked by uid 99); 14 Dec 2011 22:00:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Dec 2011 22:00:32 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.220.176] (HELO mail-vx0-f176.google.com) (209.85.220.176) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Dec 2011 22:00:24 +0000 Received: by vcbfl13 with SMTP id fl13so1467494vcb.35 for ; Wed, 14 Dec 2011 14:00:04 -0800 (PST) Received: by 10.52.174.46 with SMTP id bp14mr493976vdc.107.1323900003916; Wed, 14 Dec 2011 14:00:03 -0800 (PST) Received: from bester.local ([65.78.136.75]) by mx.google.com with ESMTPS id k16sm3728161vdt.8.2011.12.14.14.00.02 (version=SSLv3 cipher=OTHER); Wed, 14 Dec 2011 14:00:02 -0800 (PST) Date: Wed, 14 Dec 2011 14:00:00 -0800 (PST) From: Chris Hostetter To: general@lucene.apache.org Subject: Re: Data Search while replication In-Reply-To: <1323862167896-3585184.post@n3.nabble.com> Message-ID: References: <1323862167896-3585184.post@n3.nabble.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII : We would like to know what will happen to the search queries hit on a Solr : server which is a slave instance during the time of replication. Will the : searches fetch the documents from the old indexes? Can some please explain yes. : what exactly happens to the search queries while the replication is in : progress in slave solr instance. they continue to be served by the existing indx until the new index is fully loaded -- from the perspective of the slave instance, replication is exactly the same as any other "commit" that causes a new searcher to be opend (the old seracher is used until the new searcher is ready) : document(Size : 2.7 GB) and it takes more than 900 seconds for replication. replication time is almost entirely based on IO: the network IO available on both machines, and the disk IO for reading the new segments on the master and writting the new segments on the slave -- the only other time involved is instantiating the new searcher on the slave and any cache warming (again: not replication specific) : We have been reported by the users that the search request is taking longer : time during replication. this is usually an IO issue -- either slow network IO as the clients network traffic competes with the replication network traffic, or disk IO if not enough free memory is available to keep the old index segments in the filesystem cache as the new index segments are written. : Thanks in advance. Any pointers would be of great help. FWIW: you are likeley to get a wider breadth of help using the solr-user@lucene mailing list. it has more subscribers, and discussions of using solr are more topical there (general@lucene is for broad discussion of the Lucene project as a whole) -Hoss