Hi Jan!
Really appreciate your follow up. I did have a couple of clarifying
questions to bounce of you
On 2022-08-14 11:39, Jan Høydahl wrote:
1. The upgrade process[1] suggests an N+/-1 compat story, e.g. 8.11.2
should be able to co-mingle with 7.>3 but I haven't turned up any firm
statements about that.
Yes, rolling upgrade from 7.x (recommend first going to latest 7.x) to
8.x is possible as outlined here
https://solr.apache.org/guide/solr/latest/upgrade-notes/major-changes-in-solr-8.html#rolling-upgrades-with-solr-8.
You should carefully audit all the upgrade notes before starting.
Appreciate for the pointer! We had caught the HTTP/1.1 vs HTTP/2 bit
while reviewing the change list but it's a good reminder :D
By simulating the full upgrade procedure on your test / QA cluster
first you can weed out any issues before heading to your prod cluster.
Yup, this bit of reading / research is in service of fleshing out our
process for the dev fleet. Definitely not going to lead with prod.
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?
2. Is there forward/backward compatibility between segment/index files
between version? e.g. we have automatic core recovery from backups in
the event that a node fails. If I'm running a v8 node that fails after
a backup has been taken and the core gets restored to a v7 does that
sound problematic? (I'm guessing maybe/yes per [3])
If the restore is an index created with 7.x, no issues, see above.
Right, the scenario I was worried about:
1. NodeA + NodeB are both running Solr 7 (they're just nodes in the
system, no replication, serve disparate cores)
2. NodeA begins upgrade process, now running Solr 8
3. NodeA takes backup on regular intervals, sends to s3 bucket
4. NodeA host failure
5. Custom cluster automation notices NodeA is dead and identifies it
should find new node for the cores that were previously assigned to
NodeA
6. Automation reassigns NodeA cores to NodeB which has not yet been
upgraded to Solr8
7. NodeB (Solr7) restores index from s3 backups, tries to serve Solr8
index
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).
[...] then Solr8 would refuse to start since it will find traces
of v6.x in the binary index files.
-r
