On Tue, Feb 28, 2017 at 10:06 PM, Chris Adams <cma@cmadams.net> wrote:
Hello again, still working on my upgrade from 3.5...
I'm trying to understand the cluster compatibility version setting and how that applies to major upgrades. Do I have to always raise the compatibility version when I do a major upgrade?
Not immediately. Doing this will let you use the new features.
In other words, when I upgrade from 3.5 to 3.6, do I need to raise it to 3.6 before I upgrade to 4.0 (and then again raise it 4.0 before upgrading to 4.1)?
Each engine version has a set of supported compatibility levels. If you run engine-setup and have a cluster/DC with a too-old level, it will refuse to upgrade.
It looks like the 3.6->4.0 EL6->EL7 migration requires the cluster compatibility level to be at 3.6 (if I'm reading things right).
Indeed.
It appears that when I upgrade to 3.6, I will have to stop all running VMs to raise the compatibility version (and I found an open bug about whether that's possible with the hosted engine). It sounds like with 4.0, the VMs can be flagged for compatibility and I can reboot them individually. I have over 80 VMs, many behind a load balancer (for HA and load sharing), but taking them all down will obviously still interrupt service for a while.
Is there a safe way around that?
I saw someone mention they partitioned their servers and made a new cluster (with the new version), and migrated VMs from cluster to cluster. Can I do live migrations in that case? How do I get the hosted engine from one cluster to another (especially with starting at 3.5)?
You'll definitely need hosted-engine downtime, but that's usually not an issue. For your other VMs, not sure - I think that if you get a mark saying they should be rebooted, they should. See also: https://bugzilla.redhat.com/show_bug.cgi?id=1336527 Best, -- Didi