[
https://issues.apache.org/jira/browse/SOLR-17725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18039569#comment-18039569
]
Rahul Goswami edited comment on SOLR-17725 at 11/20/25 11:38 PM:
-----------------------------------------------------------------
https://github.com/apache/lucene/pull/14607 is merged, so now we should be able
to open an index irrespective of which version it was created in, as long as
all segments are either LATEST or LATEST-1 version. This is the part that will
be achieved through this JIRA. Submitted a PR for a custom merge policy to kick
off code contribution on this effort. Thanks [~dsmiley] and [~magibney] for the
pointers!
was (Author: [email protected]):
https://github.com/apache/lucene/pull/14607 is merged, so now we should be able
to open an index irrespective of which version it was created in, as long as
all segments are either LATEST or LATEST-1 version. This is the part that will
be achieved through this JIRA. Submitted a PR for a custom merge policy to kick
off code contribution on this effort.
> Automatically upgrade Solr indexes without needing to reindex from source
> -------------------------------------------------------------------------
>
> Key: SOLR-17725
> URL: https://issues.apache.org/jira/browse/SOLR-17725
> Project: Solr
> Issue Type: Improvement
> Reporter: Rahul Goswami
> Priority: Major
> Labels: pull-request-available
> Attachments: High Level Design.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Today upgrading from Solr version X to X+2 requires complete reingestion of
> data from source. This comes from Lucene's constraint which only guarantees
> index compatibility between the version the index was created in and the
> immediate next version.
> This reindexing usually comes with added downtime and/or cost. Especially in
> case of deployments which are in customer environments and not completely in
> control of the vendor, this proposition of having to completely reindex the
> data can become a hard sell.
> I, on behalf of my employer, Commvault, have developed a way which achieves
> this reindexing in-place on the same index. Also, the process automatically
> keeps "upgrading" the indexes over multiple subsequent Solr upgrades without
> needing manual intervention.
> It comes with the following limitations:
> i) All _source_ fields need to be either stored=true or docValues=true. Any
> copyField destination fields can be stored=false of course, just that the
> source fields (or more precisely, the source fields you care about
> preserving) should be either stored or docValues true.
> ii) The datatype of an existing field in schema.xml shouldn't change upon
> Solr upgrade. Introducing new fields is fine.
> For indexes where this limitation is not a problem (it wasn't for us!), the
> tool can reindex in-place on the same core with zero downtime and
> legitimately "upgrade" the index. This can remove a lot of operational
> headaches, especially in environments with hundreds/thousands of very large
> indexes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
