On 5/20/23 12:14, Dave wrote:
I never trust a solr upgrade path with an index from one major version to another. It has to be completely recreated in my opinion with the updated schema as sometimes there may be major changes, even though it’s said you can go two versions up with the same index using the upgrade path. I’ve had to rebuild indexes that take weeks to coordinate but the mechanism was in place and ready to do. I love the idea of holding one index in a core and building the next one in a secondary core and switching the names. It’s almost seamless and has been a trusted mechanism in traditional databases for decades.
Version enforcement on upgrades started in 8.x. Before 8.x, you COULD upgrade a Lucene index more than one major version. It has always been discouraged, but it was still possible. Now it's not possible. I did once see a tool that would perform delicate surgery on an index to make such upgrades possible ... but that is a bad idea.
Best of luck, but you should always have a path to completely destroy and rebuild a solr index as it’s not to be trusted to be consistent, it’s not a database. I mean if you want speed it’s on an ssd, which can fail at any given moment but you want the speed, just things to consider going forward.
Agreed. There are many situations outside of version upgrades where rebuilding the index from scratch is an absolute requirement. It is something all Solr users need to be able to do at ANY time. I used to maintain an index where a full rebuild would quite literally take about six or seven days, but I found a way to do it with zero downtime.
Thanks, Shawn
