Assuming the crash was not caused due to something in the lucene layer, what happens if you downgrade Solr but leave the previous (higher version) lucene-core.jar and lucene-backward-codecs.jar in Solr's WEB-INF/lib ? It's likely that the contract between APIs across minor versions is still intact and things continue to work. Easy to try out and provided no API breakage, solves the codec problem. The real root cause to uncover is what's causing the crash of course.
But I get your broader concern. My understanding of the back-compat promise in Lucene (and by extension Solr) has been that indexes created in a certain *major* version will continue to be opened by all *subsequent* versions until the end of the next *major* version. But you can only look backwards and hence I'd always be wary of the fact that a past Lucene version cannot open an index which has been written by a future Lucene codec (assuming data was already written before the downgrade), aka the downgrade path is always a slippery slope. I am not a fan of option A since that limits Solr from benefitting from a lot of features/speedups that Lucene introduces across minor versions. A couple of examples : Vector search is pretty actively evolving, and Solr has added features across minor versions to benefit from the same; there is also the index upgradability support recently introduced in Solr for which a foundational piece <https://github.com/apache/lucene/pull/15431> comes from the lucene layer in the soon-to-be-released Lucene 10.4 and I plan to have it in for Solr 10.1. And having to wait for over a year to get some of these features (until the next Solr major version) to solve the downgrade scenario is hardly a worthy tradeoff in my opinion. The release notes could use a general heads up outlined in option B along with elaborating the back-compat contract in general. -Rahul On Wed, Feb 25, 2026 at 1:02 PM Gus Heck <[email protected]> wrote: > FWIW, I recommend the following and none of it depends on what Solr is > doing with Lucene. Lucene versions are just one possible pain point. > Changes to an UpdateProcessor could cause a new field to be written, or bad > data to be written to a field, bugs happen, etc. There are lots of possible > problems. > > 1. Have a recovery plan before you start. Things can go sideways for any > number of reasons > 2. Have a UAT system of equal size and layout, upgrate it first then > load test and functionallity test heavily. > 3. Test your recovery plan on UAT - just like unverified backups are > useless so are unverified recovery plans. > 4. Space allowing, make a backup (and verify it) > 5. Only touch production after validating forwards and backwards on UAT. > > Not everyone listens, some can't afford the time or cost, but every skipped > element is an additional risk taken. > > Did you start a thread regarding the crashing? > > -Gus > > On Wed, Feb 25, 2026 at 12:33 PM Arrieta, Alejandro < > [email protected]> wrote: > > > Hello, > > > > I think I saw something similar on Solr 8.x. > > If you decide on B) option, on top of the backup, users may need to save > > the new/updated indexed data after the upgrade, as it will be lost with > the > > rollback. > > > > Maybe the tool proposed in this thread "Automatic upgrade of Solr indexes > > over multiple versions" can add in the future the downgrade option and be > > option C). > > > > Kind Regards, > > Alejandro Arrieta > > > > On Wed, Feb 25, 2026 at 11:53 AM Jan Høydahl <[email protected]> > > wrote: > > > > > Hi, > > > > > > At a customer we upgraded from Solr 9.8.1 to 9.10.1 recently to stay on > > > top of CVEs etc. > > > Today we had the need to roll back Solr due to some crash situation. > > > But after downgrading to 9.8.1 the nodes don't get up with errors about > > > missing codec "Lucene912". > > > > > > Par of Solr/Lucene's back-compat promise is that we won't do breaking > > > chagnes in minor versions. > > > But this kind of codec changes between minor versions breaks the > ability > > > to downgrade - you need a full reindex. > > > I find a related discussion in Lucene about this > > > https://github.com/apache/lucene/issues/14623#issuecomment-2866257196 > > > > > > We currently do not clearly document this limiation in RefGuide. > > > > > > In my eyes we (Solr) have two choices: > > > > > > A) Stay at the same lucene minor version throughout a Solr major > version > > > and keep back-compat also for downgrades > > > B) Start doumenting in release notes when a new lucene version will > > > prevent future downgrade, and advise users to back up their index > before > > > upgrading if they want the ability to roll back. > > > > > > Thoughts? > > > > > > Jan > > > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) >
