lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Staveley \(Tom\)" <rstave...@seseit.com>
Subject Index file compatibility and a migration plan to lucene 3
Date Wed, 09 Dec 2009 12:13:20 GMT
I have Lucene 2.3.1 code and indexes deployed in production in a distributed
system and would like to bring everything up to date with 3.0.0 via 2.9.1.

Here's my migration plan:

1. Add a index writer which generates a 2.9.1 "test" index 
2. Have that "test" index writer push that 2.9.1 "test" index into
production and see if the distributed 2.3.1 index readers can cope with it
OK
3. Upgrade my index writers to 2.9.1 (still using evil compressed fields) -
we shall have 2.9.1 writers and 2.3.1 readers during this phase. See if it
works.
4. Upgrade my index readers to 2.9.1 (still using evil compressed fields,
but with support for explicit use of CompressionTools for decompression,
where fields have been explicitly compressed with CompressionTools - the
application will knows which need decompression)
5. Add a CompressionTools to my "test" index writer, generating explicitly
compressed fields in the 2.9.1 "test" index
6. Test explicit decompression for relevant fields with CompressionTools in
my 2.9.1 "test" index in my index readers
7. Upgrade my "test" index writer to 3.0.0 
8. Have that "test" index writer push that 3.0.0 "test" index into
production and see if the distributed 2.9.1 index readers can cope with it
OK
9. Go through my index writers and index reader clients and systematically
purge all of the Field.Store.COMPRESS fields and migrate to an explicit
CompressionTools approach where applicable and no compression where
applicable. During this phase I'll expect to have
CompressionTools-compressed fields coexisting with their
Field.Store.COMPRESS predecessors, where index reader client use of
Field.Store.COMPRESS is in transit to the explicit decompression approach.
10. Upgrade my index writers to 3.0.0 
11. Upgrade my index readers to 3.0.0

I've simplified this a bit, because I shan't really be testing straight off
in production(!) - I'll test the migration plan in a test cluster first; but
this gives you the idea about the path.

I wanted to know if I should expect problems with this plan. I'm depending
on newer writers generating indexes for older readers and 3 is a major
number upgrade. It looks like I can get away with this in version 3, but
that's by no means a guarantee according to
http://wiki.apache.org/lucene-java/BackwardsCompatibility#File_Formats

Does this sound like a good plan?


---------------------------------------------------------------------
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