My starting point:
% escurl "_cat/nodes?v&h=name,ip,role,version,master" | sort
name ip role version master
rhel10x1 192.168.122.152 cdfhilmrstw 8.15.2 *
rhel10x2 192.168.122.242 cdfhilmrstw 8.15.2 -
rhel10x3 192.168.122.177 m 8.15.2 -
I upgraded first node, waited.
% escurl "_cat/nodes?v&h=name,ip,role,version,master" | sort
name ip role version master
rhel10x1 192.168.122.152 cdfhilmrstw 8.19.3 -
rhel10x2 192.168.122.242 cdfhilmrstw 8.15.2 -
rhel10x3 192.168.122.177 m 8.15.2 *
Upgraded second node, waited.
% escurl "_cat/nodes?v&h=name,ip,role,version,master" | sort
name ip role version master
rhel10x1 192.168.122.152 cdfhilmrstw 8.19.3 -
rhel10x2 192.168.122.242 cdfhilmrstw 8.19.3 -
rhel10x3 192.168.122.177 m 8.15.2 *
Now, to demonstrate, I just rebooted rhel10x3. As its still on old release, it now will not be able to join the cluster. But the 2-node cluster is still functional.
% escurl "_cat/nodes?v&h=name,ip,role,version,master" | sort
name ip role version master
rhel10x1 192.168.122.152 cdfhilmrstw 8.19.3 *
rhel10x2 192.168.122.242 cdfhilmrstw 8.19.3 -
rhel10x3 logs
Caused by: java.lang.IllegalStateException: node version [8.15.2] may not join a cluster comprising only nodes of version [8.19.3] or greater
So I upgraded that too and waited:
% escurl "_cat/nodes?v&h=name,ip,role,version,master" | sort
name ip role version master
rhel10x1 192.168.122.152 cdfhilmrstw 8.19.3 *
rhel10x2 192.168.122.242 cdfhilmrstw 8.19.3 -
rhel10x3 192.168.122.177 m 8.19.3 -
Upgrade complete!!
Now actually, elastic recommends upgrader to master-only nodes first, so if it were my system I’d follow that recommendation.
There was no cluster downtime. No point where there was not 2+ nodes in a functioning cluster.
There is no way I am investing any more time to spin up a RHEL 8.9 3-node cluster, as I sure I’ll just see exactly the same.