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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
