lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan H√łydahl <>
Subject Re: issue transplanting standalone core into solrcloud (plus upgrade)
Date Mon, 26 Sep 2016 17:22:46 GMT
Better keep your old schema unchanged if you want to use an old index. The upgrader does not
change field type for you. If the old IntField does not exist in 6.x you're out of luck, may
try to build a custom version with the old field types as addons..

Sendt fra min iPhone

> Den 26. sep. 2016 kl. 14.28 skrev xavi jmlucjav <>:
> Hi Shawn/Jan,
>> On Sun, Sep 25, 2016 at 6:18 PM, Shawn Heisey <> wrote:
>>> On 9/25/2016 4:24 AM, xavi jmlucjav wrote:
>>> Everything went well, no errors when solr restarted, the collections
>> shows
>>> the right number of docs. But when I try to run a query, I get:
>>> null:java.lang.NullPointerException
>> Did you change any of the fieldType class values as you adjusted the
>> schema for the upgrade?  A number of classes that were valid and
>> deprecated in 3.6 and 4.x were completely removed by 5.x, and 6.x
>> probably removed a few more.
> 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?
>> If you did make changes like this to your schema, then what's in the
>> index will no longer match the schema, and the *only* option is a
>> reindex.  Exceptions are likely if you don't reindex after schema
>> changes to the class value(s) or the index analyzer(s).
>> Regarding the _version_ field:  SolrCloud expects this field to be in
>> your schema.  It might also expect that that every document in the index
>> will already contain a value in this field.  Adding _version_ to your
>> schema should be treated similarly to the changes mentioned above -- a
>> reindex is required for proper operation.
>> Even if the schema didn't change in a way that *requires* a reindex ...
>> the number of changes to the analysis components across three major
>> version jumps is quite large.  Solr might not work as expected because
>> of those changes unless you reindex, even if you don't see any
>> exceptions.  Changes to your schema because of changes in analysis
>> component behavior might  be required -- which is another situation that
>> usually requires a reindex.
>> Because of these potential problems, I always start a new Solr version
>> with no index data and completely rebuild my indexes after an upgrade.
>> That is the best way to ensure success.
> I am totally aware of all the advantages of reindexing, sure. And that is
> what I always do, this time thought, seems the original data is not
> available...
>> You referenced a mailing list thread where somebody had success
>> converting non-cloud to cloud... but that was on version 4.8.1, two
>> major versions back from the version you're running.  They also did not
>> upgrade major versions -- from some things they said at the beginning of
>> the thread, I know that the source version was at least 4.4.  The thread
>> didn't mention any schema changes, either.
>> If the schema doesn't change at all, moving from non-cloud to cloud is
>> very possible, but if the schema changes, the index data might not match
>> the schema any more, and that situation will not work.
> Since you jumped three major versions, it's almost guaranteed that your
>> schema *did* change, and the changes may have been more extensive than
>> just adding the _version_ field.
>> It's possible that there's a problem when converting a non-cloud install
>> with no _version_ field to a cloud install where the only schema change
>> is adding the _version_ field.  We can treat THAT situation as a bug,
>> but if there are other schema changes besides adding _version_, the
>> exception you encountered is most likely not a bug.
> The are two orthogonal issues here:
> A. moving to solrcloud from  standalone without reindexing. And without
> having a _version_ field already indexed, of course. Is this even possible?
> From the thread above, I understood it was possible, but you say that
> solrcloud expects _version_ to be there, with values, so this makes this
> move totally impossible without a reindexing. This should be made clear
> somewhere in the doc. I understand it is not a frequent scenario, but will
> be a deal breaker when it happens. So far the only thing I found is the
> aforementioned thread, that if I am not misreading, makes it sound as it
> will work ok.
> B. upgrading from a very old 3.6 version to 6.1 without reindexing: it
> seems like I am hitting an issue with this first. Even if this was
> resolved, I would not be able to achieve my goal due A, but would be good
> to know how to get this done too, if possible.
> Jan: I tried tweaking luceneMatchVersion too, no luck though.
> xavier
>> Thanks,
>> Shawn

  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message