>> The recommendation is however to install a brand new 9.0 cluster >> (since 8.x will be EOL within a year) and re-index. > > Point taken. Given the seemingly N-1 posture for Solr & Lucene I'm guessing > if we wanted to do that we would use the IndexUpgraderTool to convert indexes > from 7->8 and then let the v9 deployment handle the 8->9 upgrade?
I think that could work. As far as I remember, it is only Lucene 8 that is going to hard fail if it finds an index originally created by N-2 version, and that Lucene 9 will eat a v8 index, even if upgraded by IndexUpgrader from v7. > So in this case we've got an index backup from Solr8 that Solr7 is attempting > to serve. That seems non ideal / potentially non-functional if Solr has > mechanisms that fail when it sees unexpected version info (which it sounds > like it does based on your commentary around the IndexUpgraderTool below). This would definitely be an issue. So best do as follows: 1. Stop all new documents flowing into the cluster 2. Do a last BACKUP call (v7) 3. Complete the rolling upgrade of all nodes to v8 4. Resume indexing traffic 5. Resume normal BACKUP and RESTORE logic Jan
