Hi, Wanted to explain my situation in more detail.
I have a master which never adds or deletes documents incrementally. I just run the dataimport with autocommit. Seems like I'll need to make a custom DeletionPolicy to keep more than one index around. I'm accessing indices from Solr. How do I tell solr to use a particular index? Thanks, Tri ________________________________ From: Michael McCandless <luc...@mikemccandless.com> To: solr-user@lucene.apache.org Sent: Tue, February 15, 2011 5:36:49 AM Subject: Re: rollback to other versions of index Lucene is able to do this, if you make a custom DeletionPolicy (which controls when commit points are deleted). By default Lucene only saves the most recent commit (KeepOnlyLastCommitDeletionPolicy), but if your policy keeps more around, then you can open an IndexReader or IndexWriter on any IndexCommit. Any changes (including optimize, and even opening a new IW with create=true) are safe within a commit; Lucene is fully transactional. For example, I use this for benchmarking: I save 4 commit points in a single index. First is a multi-segment index, second is the same index with 5% deletions, third is an optimized index, and fourth is the optimized index with 5% deletions. This gives me a single index w/ 4 different commit points, so I can then benchmark searching against any of those 4. Mike On Tue, Feb 15, 2011 at 4:43 AM, Jan Høydahl <jan....@cominvent.com> wrote: > Yes and no. The index grows like an onion adding new segments for each commit. > There is no API to remove the newly added segments, but I guess you could > hack >something. > The other problem is that as soon as you trigger an optimize() all history is >gone as the segments are merged into one. Optimize normally happens >automatically behind the scenes. You could turn off merging but that will >badly >hurt your performance after some time and ultimately crash your OS. > > Since you only need a few versions back, you COULD write your own custom >mergePolicy, always preserving at least N versions. But beware that a >"version" >may be ONE document or 10000 documents, depending on how you commit or if >autoCommit is active. so if you go this route you also need strict control >over >your commits. > > Perhaps best option is to handle this on feeding client side, where you keep > a >buffer of N last docs. Then you can freely roll back or re-index as you >choose, >based on time, number of docs etc. > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > On 15. feb. 2011, at 01.21, Tri Nguyen wrote: > >> Hi, >> >> Does solr version each index build? >> >> We'd like to be able to rollback to not just a previous version but maybe a >few >> version before the current one. >> >> Thanks, >> >> Tri > >
