Minor nit. For IndexUpgraderTool and optimize to be identical, you have to
specify maxSegments=1 on optimize.
As of LUCENE-7976, optimize respects the max segment size and does _not_
necessarily rewrite segments that have no deleted documents, especially if
they’re near 5G which is the
Many Thanks!
-Ursprüngliche Nachricht-
Von: Shawn Heisey
Gesendet: Montag, 1. April 2019 18:03
An: solr-user@lucene.apache.org
Betreff: Re: AW: Solr 8.0.0 + IndexUpgrader
On 4/1/2019 9:47 AM, Herbert Hackelsberger wrote:
> So, am I correct:
> - When using the IndexUp
On 4/1/2019 9:47 AM, Herbert Hackelsberger wrote:
So, am I correct:
- When using the IndexUpgrader, it will make the Index usable in the actual
version, without all new features.
- Using the Index Upgrader in the future again on the next major version will
again result in this error situation.
major version will
again result in this error situation.
Best Regards
-Ursprüngliche Nachricht-
Von: Erick Erickson
Gesendet: Montag, 1. April 2019 17:33
An: solr-user@lucene.apache.org
Betreff: Re: Solr 8.0.0 + IndexUpgrader
As of Lucene 6, a marker was written into each segment
As of Lucene 6, a marker was written into each segment, and when segments are
merged the lowest marker is preserved. If any marker for version of Lucene X-2
is found, you will see the error you see.
This has been a source of considerable confusion. The guarantee of “one major
revision
On 4/1/2019 9:19 AM, Herbert Hackelsberger wrote:
I tried to upgrade my test index from Solr 7.7.1 to Solr 8.0.0.
The file segments_4h7 already contains the string Lucene70.
I upgraded before with this command:
java -cp lucene-core-7.7.1.jar;lucene-backward-codecs-7.7.1.jar
Hi,
I tried to upgrade my test index from Solr 7.7.1 to Solr 8.0.0.
The file segments_4h7 already contains the string Lucene70.
I upgraded before with this command:
java -cp lucene-core-7.7.1.jar;lucene-backward-codecs-7.7.1.jar
org.apache.lucene.index.IndexUpgrader
