| Lucene can only open an index whose creation version is at most one major version older than itself: an index created with Lucene N-2 is refused, even if every segment was rewritten since by Lucene N-1. The Solr core migration added in XWIKI-19813 (see AbstractSolr#migrateCore) looks for a previous core from solrMajorVersion - 1 down to 8 and migrates the first one it finds. When the only existing core is two (or more) Solr major versions older than the current one, which happens when an instance upgrades straight from an XWiki version based on Solr N-2 to one based on Solr N, the migration tries to read a core that the current Solr cannot open, and fails with a low level Lucene error. This situation will appear as soon as XWiki moves to Solr 10, for instances which never ran an XWiki version based on Solr 9 (i.e. still using Solr 8 cores). It affects both the embedded and the remote Solr setups, since XWiki performs the migration in both cases (with a remote Solr, the administrator only creates the new empty cores). Proposal
- Detect, before trying to read it, that the previous core found is older than the previous Solr major version (the Solr major version is part of the core name), and refuse to migrate it.
- Report a clear error explaining that the Solr data cannot be migrated directly, and indicating the XWiki version to upgrade to first (the last XWiki version based on the intermediate Solr major version), before upgrading to the target version.
- Maintain a mapping between each Solr major version and the latest XWiki version based on it, to compute the right upgrade steps. For example, Solr 8: XWiki 16.1.x (or 15.10.x LTS), Solr 9: the last XWiki version before the move to Solr 10.
- The search core is not concerned, since it's recreated and reindexed from the database when the Lucene version changes.
|
