You could take one node out of the cluster, and use this to perform the update, and deploy the code changes. You can then bring this node back into the cluster, take the other node out of the cluster, and perform the code update on that cluster. So long as there are no data changes that may cause a problem to the original node, this should be sufficient for your purposes. There's the usual concern of whether there are customers half way through a transaction when you take the node out, but you can drain the node of connections with a decent load balancer, or if you've got session replication then this would mitigate this particular issue.
Your backend nodes are going to show as being down during the update - not much you can do about that - but unless you are making massive changes, this shouldn't be running for too long.
However, sometimes you can only get management to agree to an upgrade when the alternative is more distasteful. This seems like the perfect opportunity to make that case, and take the potential downtime as an incentive.
Even with a rolling update, there are some data changes (e.g. if an attribute name or sometimes type changes or there's a general data remodelling) that may necessitate some downtime on rare occasions, so you may shoot for 100% uptime, but in reality (and with large upgrades) you sometimes need some downtime.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.