You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The formula makes a distinction between master and slave members of the cluster that is AFAICT not needed at all. I think it is only ever used when bootstrapping; in order to get the cluster started the 'master' node has to be started first with --wsrep-new-cluster and then the 'slave' nodes can be started normally.
It is important to understand that bootstrapping a brand new cluster is a special case and should only be done if all members of the cluster are newly installed. If the master node is re-installed while the primary component is present on the slaves (active or not), then a bootstrap action on the master is a dangerous and potentially destructive action.
I've modified the formula to remove the master/slave distinction from the pillar hierarchy and changed the orchestration code to select on a first_node:true pillar item to decide which node to bootstrap from, and put a safeguard in place to test if the grastate.dat file is new on all member nodes before advancing.
The normal high state for any node will now try to start mariadb (this is for ubuntu18 only at the moment) and that will just work if a node can re-join the primary component. So any re-installation or restart of a node will work without additional effort.
The remaining special cases are:
Install a brand new cluster from scratch
Recover a failed cluster
Case 1 is done by orchestration, case 2 for now is a manual step (one needs to figure out the most advanced node and start the cluster from there, but this can be scripted).
Since my code constitutes a wide departure from the original formula I wonder what we should do. It is certainly not backward compatible, but I'm certainly open to sharing what I've got.
The text was updated successfully, but these errors were encountered:
Make the "fork" available as a repo on your GitHub profile, maybe? At least then people can use it if they want, regardless if it's incorporated here or not.
The formula makes a distinction between master and slave members of the cluster that is AFAICT not needed at all. I think it is only ever used when bootstrapping; in order to get the cluster started the 'master' node has to be started first with
--wsrep-new-cluster
and then the 'slave' nodes can be started normally.It is important to understand that bootstrapping a brand new cluster is a special case and should only be done if all members of the cluster are newly installed. If the master node is re-installed while the primary component is present on the slaves (active or not), then a bootstrap action on the master is a dangerous and potentially destructive action.
I've modified the formula to remove the master/slave distinction from the pillar hierarchy and changed the orchestration code to select on a
first_node:true
pillar item to decide which node to bootstrap from, and put a safeguard in place to test if thegrastate.dat
file is new on all member nodes before advancing.The normal high state for any node will now try to start mariadb (this is for ubuntu18 only at the moment) and that will just work if a node can re-join the primary component. So any re-installation or restart of a node will work without additional effort.
The remaining special cases are:
Case 1 is done by orchestration, case 2 for now is a manual step (one needs to figure out the most advanced node and start the cluster from there, but this can be scripted).
Since my code constitutes a wide departure from the original formula I wonder what we should do. It is certainly not backward compatible, but I'm certainly open to sharing what I've got.
The text was updated successfully, but these errors were encountered: