Upgrading a cluster without downtime

What are the steps to make this happen?

My requirements would be to be able to upgrade part of the cluster so that the user could test the upgrade before switching everything over.

As this is for a 24/7 control center, downtime is not good time.

What version of Ignition are you using?

First off, I moved this… though, for what it’s worth, I debated a long time before doing it :slight_smile: Anyhow, I think we should keep with the goal of having the Knowledge Base forum be “solution posts” only.

My first thought is that it should be fairly easy, ignoring the whole “test things out first” requirement. Take down the master, everything switches over, upgrade it, everything switches back, upgrade the backup.

To test first, though, you would want everything to switch to the backup and then be able to upgrade the master and test it without everything switching back. The only think I can think of right now is to stop the master service - everything switches to backup. In master’s install dir, edit “redundancy.xml” to change its mode from Master to Independent. Upgrade it. When you start it, it won’t be redundant, and you can test all you want, while the backup still runs the previous clients. Once satisfied, go into the redundancy settings and switch it back to master.

Now, there’s one kink in the plan that I need to double-check. When two Ignitions are redundant but have different versions, they’ll connect, but be “incompatible”. I need to make sure that a backup in this situation would properly transfer its clients back to the master. Keep in mind that the clients might restart automatically due to a new client software version, but that’s unavoidable. Anyhow, I’ll try to double check that today.


Thanks Colby,

I was hoping for a “solution post” in response which is why I picked Knowedge Base form.

Version will be the latest because it hasn’t been sold yet :slight_smile: I’m doing investigative work :smiling_imp:
So if it doesn’t work as planned, can you move this thread to Feature Requests?

Ok, I finally got around to testing this out (in my world, a week is like a day… haha), going from 7.2.5 to 7.2.6.

It worked pretty much like I expected, besides an unfortunate error that popped up when going back from the backup to master after I upgraded the master (after clicking ‘abort’ on the error though, it recovered automatically and reconnected). After upgrading the master, all of the clients moved back to it, but the backup node became “incompatible”. This meant that when I took the master down again, all of the clients (which had automatically updated themselves to 7.2.6) would no longer connect to the backup- they reported “version mismatch” instead.

So, it’s basically exactly like I described: If you need to test the new version before moving the clients back over, you’ll need to manually switch the redundancy mode on the master while it is shutdown. That way, the clients will continue to run on the backup, you can test on the master, and when you’re happy, enable redundancy again, and the clients will switch back over.


After which, you take down the backup, upgrade it and then add it back in.

Cool, Thanks for that.