[OpenAFS] 14 Jan 2021 08:25:36 GMT Breakage in RX Connection ID calculation

[Neil Brown]

> I have 3 DB servers running 1.6.22.1. I'm planning to update hardware (with 
> identical IP addresses) and SW to 1.8.7. Do you see a problem in updating 
> machine for machine with some time in between, so that I have several steps 
> in time:
> now         : 3x 1.6.22.1
> intermediate: 2x 1.6.22.1 + 1x 1.8.7
> intermediate: 1x 1.6.22.1 + 2x 1.8.7
> final       : 3x 1.8.7

I seemed to remember that mixing DB versions was not recommended (or 
possibly didn't even work). I've notes from 2012 when went from 1.4 to 
1.6, that specifically avoided having mixed versions.

The usual way we upgrade DB our 3 servers from X to Y:

* shutdown DB servers 2 and 3, so we are running on a single DB server 1 on version X.
* Upgrade 1 from X to Y
* if things look good, then remove the DB files from 2 and 3
* upgrade 2 and 3 to Y
* start 2 and 3 making sure they rejoin the quorum and things look good 
with udebug

This is for major upgrades from 1.4 to 1.6 or 1.6 to 1.8, not 1.8.6 to 
1.8.7. And we warn users that there will be delays to some activities 
while the whole thing takes place.

Obviously taking copies of the raw DB files, and text dumps of the PTS an 
VOL databases with pt_util and "vos listvldb" in case of disasters.

If we were changing hardware at the same time then I guess rather than 
updating server 1 after we'd shut it down, we'd copy the necessary DB 
files to the new "1" hardware and start the new version Y of the service 
on that hardware.

Neil
-- 
  Neil Brown - Computing Officer - Appleton Tower 7.12a | Neil.Brown @ ed. ac.uk
  School of Informatics, University of Edinburgh        | Tel: +44 131 6504422

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.