lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Høydahl" ...@cominvent.com>
Subject Re: issue transplanting standalone core into solrcloud (plus upgrade)
Date Mon, 26 Sep 2016 19:21:39 GMT
If all the fields in your current schema has stored=“true”, you can try to export
the full index to an XML file which can then be imported into 6.1.
If some fields are not stored you will only be able to recover the inverted index
representation of that data, which may not be enough to recreate the original
data (or in some cases maybe it is enough).

If you share a copy of your old schema.xml we may be able to help.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 26. sep. 2016 kl. 20.39 skrev Shawn Heisey <apache@elyograg.org>:
> 
> On 9/26/2016 6:28 AM, xavi jmlucjav wrote:
>> Yes, I had to change some fields, basically to use TrieIntField etc
>> instead
>> of the old IntField. I was assuming by using the IndexUpgrader to upgrade
>> the data to 6.1, the older IntField would work with the new TrieIntField.
>> But I have tried loading the upgraded data into a standalone 6.1 and I am
>> hitting the same issue, so this is not related to _version_ field (more on
>> that below). Forget about solrcloud for now, having an old 3.6 index,
>> should it be possible to use IndexUpgrader and load it on 6.1? How would
>> one need to handle IntFields etc?
> 
> The only option when you change the class on a field in your schema is
> to wipe the index and rebuild it.  TrieIntField uses a completely
> different on-disk data format than IntField did.  The two formats simply
> aren't compatible.  This is not a bug, it's a fundamental fact of Lucene
> indexes.
> 
> Lucene doesn't use a schema -- that's a Solr concept.  IndexUpgrader is
> a Lucene program that doesn't know what kind of data each field
> contains, it just reaches down into the old index format, grabs the
> internal data in each field, and copies it to a new index using the new
> format.  The internal data must still be consistent with the Lucene
> program for the index to work in a new version.  When you're running
> Solr, it uses the schema to know how to read the index.
> 
> In 5.x and 6.x, IntField does not exist, and attempting to read that
> data using TrieIntField will not work.
> 
> The luceneMatchVersion setting in solrconfig.xml can cause certain
> components (tokenizers and filters mainly) to revert to old behavior in
> the previous major version.  Version 6.x doesn't hold onto behavior from
> 3.x and 4.x -- it can only revert behavior back to 5.x versions.
> 
> The luceneMatchVersion setting cannot bring back removed classes like
> IntField, and it does NOT affect the on-disk index format.
> 
> Your particular situation will require a full reindex.  It is not
> possible to upgrade an index using those old class types.
> 
> Thanks,
> Shawn
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message