lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: SnapshotDeletionPolicy usage
Date Tue, 05 Feb 2008 15:35:26 GMT

jm wrote:

> Thanks for the reply Mike.
>
>> You can also wrap any other deletion policy (it doesn't have to be
>> KeepOnlyLastCommit).
>>
>> When you want to do a backup, make sure to do try/finally, ie:
>>
>>    IndexCommitPoint cp = dp.snapshot();
>>    try {
>>      Collection files = cp.getFileNames();
>>      <do copying here>
>>    } finally {
>>      dp.release();
>>    }
>
> Ohhh, I was hoping that by using that policy any _external_ process (a
> commercial backup tool) would be able to backup the index files in a
> consistent way...I am afraid I was asking too much.

Well, an external process doesn't have enough information.

EG if you have a reader on the index, it could be keeping files  
around (because it has them open) that are not actually referenced by  
the most recent commit to the index.  You don't need to back up those  
files.  So you really need to use the current writer to have it tell  
you which files are referenced.

And, if you keep adding docs via the writer, and merges complete, the  
index files will be changing while you're doing the backup (but, not  
the files referenced by your snapshot).

> If I manage to coordinate with the external process so it signals it
> wants to do a backup, I take the snapshot in the indexing process, and
> it then copies the files, and then I release the snapshot that will
> work no?

Yes, that will work.  Once you have the list of files, you can send  
it to any external  tool (rsync, tar, robocopy, cp, etc.) to have  
them actually do the copying.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message