Return-Path: Delivered-To: apmail-jakarta-lucene-user-archive@apache.org Received: (qmail 71171 invoked from network); 3 Jun 2002 14:39:46 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 Jun 2002 14:39:46 -0000 Received: (qmail 24498 invoked by uid 97); 3 Jun 2002 14:39:45 -0000 Delivered-To: qmlist-jakarta-archive-lucene-user@jakarta.apache.org Received: (qmail 24448 invoked by uid 97); 3 Jun 2002 14:39:43 -0000 Mailing-List: contact lucene-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Users List" Reply-To: "Lucene Users List" Delivered-To: mailing list lucene-user@jakarta.apache.org Received: (qmail 24435 invoked by uid 98); 3 Jun 2002 14:39:42 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Errors-To: User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Mon, 03 Jun 2002 07:39:39 -0700 Subject: Re: Optimization From: Peter Carlson To: Lucene Users List Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N If you watch what's going on in the index folder (if you are using an FSDirectory), you will see that Lucene actually creates a brand new set of index files with a different prefix (like current set is 2411_... And new set is 2412_...). The current index files still exist until the new index is fully created. If you take a backup in the middle of optimization, I am pretty sure that you will get the uncompleted state of the new index. This means that the new index will not be consistent, but the current index will fine. --Peter On 6/3/02 12:03 AM, "Nader S. Henein" wrote: > Lucene and Backing up the index : > > Since we're on the concurrency issue, can I take a back up from lucene while > it's indexing or optimizing (using the writer), will this be a consistent > backup image > > -----Original Message----- > From: Peter Carlson [mailto:carlson@bookandhammer.com] > Sent: Monday, June 03, 2002 10:38 AM > To: Lucene Users List > Subject: Re: Optimization > > > There should be no problem, especially if you are working on a unix based > machine. > > Since the reader will be using the current index and the optimizer will be > creating a new index there should be no problem. However, you will have to > close the reader and reopen it to have it use the new index. > > There has been some mention on the list about the optimizer deleting the old > indexes, but if you are using a unix machine then the index files will still > be available as long as one process is using them. I don't know how this > would work on Windows (my guess is it wouldn't be able to delete the index > files in use). > > At least this is my understanding. > > --Peter > > On 6/2/02 10:54 PM, "V S" wrote: > >> As optimization is a slightly different process, >> basically merging segments, I was not sure if this >> would not block, especially if you are querying on the >> segment that is being merged? >> >> I do see indexing and searching working in parallel > > > -- > To unsubscribe, e-mail: > > For additional commands, e-mail: > > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: