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.
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
