Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

master/slave distinction is artificial and unneccesary #42

Open
dvandok opened this issue Feb 19, 2019 · 2 comments
Open

master/slave distinction is artificial and unneccesary #42

dvandok opened this issue Feb 19, 2019 · 2 comments

Comments

@dvandok
Copy link

dvandok commented Feb 19, 2019

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:

  1. Install a brand new cluster from scratch
  2. 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.

@joachimtingvold
Copy link

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.

@dvandok
Copy link
Author

dvandok commented May 31, 2019

Well, it is a work in progress and somewhat unpolished at the moment. But it is at https://github.com/NDPF/salt-formula-galera/tree/dennisvd/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants