You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Andreas Hubold <an...@coremedia.com> on 2013/05/10 11:49:39 UTC
Index compatibility from 4.0 to 4.3
Hi,
we are planning to update Solr installations from 4.0 to 4.3 and want to
avoid reindexing. But solrconfig.xml contains the following comment for
<luceneMatchVersion>:
"... Generally, you want to use the latest version to get all bug fixes
and improvements. It is highly recommended that you fully re-index after
changing this setting ..."
What bug fixes / improvements do we loose if we'd stay at
<luceneMatchVersion>LUCENE_40</luceneMatchVersion>?
Or is it safe to change it from LUCENE_40 to LUCENE_43 without reindexing?
The release notes do no mention index format incompatibilites. However,
the compression of stored fields introduced in 4.1 is definitely an
index change. Is it correct that Solr 4.3 can still read a Solr 4.0 index?
I would think that it is not possible for Solr 4.0 to read an index from
Solr 4.3, right? This is important to know - just in case an update from
4.0 to 4.3 needs to be rolled back.
Thank you,
Andreas
Re: Index compatibility from 4.0 to 4.3
Posted by Jan Høydahl <ja...@cominvent.com>.
You're probably right, that it's only new and merged segments that will be of the new format. Solr 4.3 will be able to search the old segments.
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
10. mai 2013 kl. 15:27 skrev Shawn Heisey <so...@elyograg.org>:
> On 5/10/2013 5:11 AM, Jan Høydahl wrote:
>> Hi,
>>
>> The fastest way to upgrade is to leave luceneMatchVersion as LUCENE_40. Then you will not get any surprises wrt changed behavior for existing functionality. but you will get all the bug fixes. You can test it out on your dev box.
>
> I've wondered if it would be possible to create a list on the wiki of
> how Solr behaves differently with each successive bump in
> luceneMatchVersion. That would be very helpful in helping people with
> their upgrades.
>
>> The first time Solr reads the existing index, it will be converted to 4.3 format, so keep a backup in case you wish to downgrade again, since 4.0 will not read this index. I'm not 100% sure if this auto conversion will compressed stored fields for you or if you need a re-index for that.
>
> I'm not sure this is right. Solr should leave existing segments alone,
> but write new segments in the new format. An optimize would be required
> to upgrade the format of the whole index. Of course a full reindex
> after changing luceneMatchVersion is the recommended way to go, because
> that version number change might result in the indexing happening
> differently.
>
> One person on IRC had trouble with the compression in 4.2.1 not being
> enabled even when deleting the entire index directory and starting over,
> but the entire situation sounded like their upgrade was perhaps not
> complete, and I never could figure out what was happening.
>
> Thanks,
> Shawn
>
Re: Index compatibility from 4.0 to 4.3
Posted by Andreas Hubold <an...@coremedia.com>.
Thank you both for your answers.
I really like the idea of explaining the changes for luceneMatchVersion
in more detail. Maybe this could even go into the release notes?
Thanks,
Andreas
Shawn Heisey wrote on 10.05.2013 15:27:
> On 5/10/2013 5:11 AM, Jan Høydahl wrote:
>> Hi,
>>
>> The fastest way to upgrade is to leave luceneMatchVersion as LUCENE_40. Then you will not get any surprises wrt changed behavior for existing functionality. but you will get all the bug fixes. You can test it out on your dev box.
> I've wondered if it would be possible to create a list on the wiki of
> how Solr behaves differently with each successive bump in
> luceneMatchVersion. That would be very helpful in helping people with
> their upgrades.
>
>> The first time Solr reads the existing index, it will be converted to 4.3 format, so keep a backup in case you wish to downgrade again, since 4.0 will not read this index. I'm not 100% sure if this auto conversion will compressed stored fields for you or if you need a re-index for that.
> I'm not sure this is right. Solr should leave existing segments alone,
> but write new segments in the new format. An optimize would be required
> to upgrade the format of the whole index. Of course a full reindex
> after changing luceneMatchVersion is the recommended way to go, because
> that version number change might result in the indexing happening
> differently.
>
> One person on IRC had trouble with the compression in 4.2.1 not being
> enabled even when deleting the entire index directory and starting over,
> but the entire situation sounded like their upgrade was perhaps not
> complete, and I never could figure out what was happening.
>
> Thanks,
> Shawn
>
>
Re: Index compatibility from 4.0 to 4.3
Posted by Shawn Heisey <so...@elyograg.org>.
On 5/10/2013 5:11 AM, Jan Høydahl wrote:
> Hi,
>
> The fastest way to upgrade is to leave luceneMatchVersion as LUCENE_40. Then you will not get any surprises wrt changed behavior for existing functionality. but you will get all the bug fixes. You can test it out on your dev box.
I've wondered if it would be possible to create a list on the wiki of
how Solr behaves differently with each successive bump in
luceneMatchVersion. That would be very helpful in helping people with
their upgrades.
> The first time Solr reads the existing index, it will be converted to 4.3 format, so keep a backup in case you wish to downgrade again, since 4.0 will not read this index. I'm not 100% sure if this auto conversion will compressed stored fields for you or if you need a re-index for that.
I'm not sure this is right. Solr should leave existing segments alone,
but write new segments in the new format. An optimize would be required
to upgrade the format of the whole index. Of course a full reindex
after changing luceneMatchVersion is the recommended way to go, because
that version number change might result in the indexing happening
differently.
One person on IRC had trouble with the compression in 4.2.1 not being
enabled even when deleting the entire index directory and starting over,
but the entire situation sounded like their upgrade was perhaps not
complete, and I never could figure out what was happening.
Thanks,
Shawn
Re: Index compatibility from 4.0 to 4.3
Posted by Jan Høydahl <ja...@cominvent.com>.
Hi,
The fastest way to upgrade is to leave luceneMatchVersion as LUCENE_40. Then you will not get any surprises wrt changed behavior for existing functionality. but you will get all the bug fixes. You can test it out on your dev box.
The first time Solr reads the existing index, it will be converted to 4.3 format, so keep a backup in case you wish to downgrade again, since 4.0 will not read this index. I'm not 100% sure if this auto conversion will compressed stored fields for you or if you need a re-index for that.
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
10. mai 2013 kl. 11:49 skrev Andreas Hubold <an...@coremedia.com>:
> Hi,
>
> we are planning to update Solr installations from 4.0 to 4.3 and want to avoid reindexing. But solrconfig.xml contains the following comment for <luceneMatchVersion>:
>
> "... Generally, you want to use the latest version to get all bug fixes and improvements. It is highly recommended that you fully re-index after changing this setting ..."
>
> What bug fixes / improvements do we loose if we'd stay at <luceneMatchVersion>LUCENE_40</luceneMatchVersion>?
> Or is it safe to change it from LUCENE_40 to LUCENE_43 without reindexing?
>
> The release notes do no mention index format incompatibilites. However, the compression of stored fields introduced in 4.1 is definitely an index change. Is it correct that Solr 4.3 can still read a Solr 4.0 index?
>
> I would think that it is not possible for Solr 4.0 to read an index from Solr 4.3, right? This is important to know - just in case an update from 4.0 to 4.3 needs to be rolled back.
>
> Thank you,
> Andreas