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

should not designate one node as master #116

Closed
maxadamo opened this issue Aug 23, 2018 · 5 comments
Closed

should not designate one node as master #116

maxadamo opened this issue Aug 23, 2018 · 5 comments
Assignees
Milestone

Comments

@maxadamo
Copy link

maxadamo commented Aug 23, 2018

Hi Frank.

there is no concept of "master" that can be pre-assigned, and that can always be used to bootstrap the cluster.
There is one node in the cluster which can be considered safe to bootstrap. This node is the last node that was alive in the cluster and it can be determined by grepping as following:

grep safe_to_bootstrap ~mysql/grastate.dat 
safe_to_bootstrap: 0

If it's 1 you can bootstrap from that node.
Of course you can bootstrap for whatever node, but the risk of loosing data is considerably high, depending how long the last node was alive, while the other nodes were down!!

For you reference: Galera Safe To Bootstrap

Hope it helps!

@fraenki
Copy link
Member

fraenki commented Aug 23, 2018

@maxadamo Thanks! I'm aware of this issue. From a historical standpoint I guess this feature exists in this module to make it possible to bootstrap a new cluster.

I take your report as an opportunity to think about how this feature could be improved for existing clusters. If you're able to help with this, do not hesitate to suggest code changes by submitted a pull request.

@fraenki fraenki added this to the 1.1.0 milestone Aug 23, 2018
@fraenki fraenki self-assigned this Aug 23, 2018
@maxadamo
Copy link
Author

maxadamo commented Aug 23, 2018

I can understand.... TBH, I was investigating your modules, since it's not easy to find a proper solution.
I have my own tool, and my own module galera_proxysql

but I'm using a puppet exec, with my wrapper with the following command:

command => 'galera_wizard.py -bn -f || galera_wizard.py -jn -f',

which means: try to bootstrap or try to join.
I do also have a fact, checking the status on the port 9200.

@maxadamo
Copy link
Author

There is a possibility to use PuppetDB. I have seen it in some other module. But while it's possible to store some information information on there it's still not easy to combine together all the moving parts.
Let's see where we get :)

@fraenki fraenki modified the milestones: 1.1.0, 1.2.0 Nov 1, 2018
@ThoTischner
Copy link

Maybe this approach could be extended to support also this type of scenario: #118 (comment)

@fraenki fraenki modified the milestones: 2.0.0, 2.1.0 Mar 1, 2020
@fraenki fraenki modified the milestones: 2.1.0, 3.0.0 May 7, 2020
@fraenki
Copy link
Member

fraenki commented Jun 27, 2022

I was considering using grastate.dat in order to not bootstrap from the wrong node. However, this would require to know the location of datadir, but this is either set by puppetlabs/mysql or by a custom config. So there's no reliable way to determine the datadir and hence no way to query grastate.dat.

So I've decided to abandon this idea for now. In my experience the current mode of operation has not caused any issues in ~5 years. If someone wants to play it extra safe it would always be possible to set bootstrap_command to something like /bin/false.

I'm going to close this issue now. If someone has a solution to the formentioned problem or has a better idea, please let me know (or better: submit a pull request :)).

@fraenki fraenki closed this as completed Jun 27, 2022
fraenki added a commit that referenced this issue Jun 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants