-
Notifications
You must be signed in to change notification settings - Fork 39
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
Retire this repo in favor of the Bitnami mariadb-galera chart #35
base: main
Are you sure you want to change the base?
Conversation
- https://mariadb.com/kb/en/unicode/ - the meaning of utf8 will change from 10.5 to 10.6 - https://mariadb.com/docs/reference/mdb/system-variables/collation_server/ - a majority of setups use utf8mb4_unicode_ci Ref Yolean/kubernetes-mysql-cluster#35
When starting a new cluster from empty volumes, you'll get a split brain situation unless replicas is This stack is most certainly more robust that what we intend to replace, but there's more lines of bash to understand and source and issues live in separate repositories for the image and the chart. I see no evidence of automated tests in recent commits to the docker image. This means it's as ad-hoc as our script, but baked into the custom image combined with snippets mixed with helm. I've seen the following outcomes of scaling down to zero, then back up to three again:
None of these are split brain. I'll try to capture both initial apply and some failure modes in the test script. |
I think this stack is ok. It must be initialized by applying |
Breaking. Existing PVCs won't work.
As with our own setup, recovery from zero replicas is prone to data loss. With
OrderedReady
it shouldn't be prone to split brain. See https://github.com/bitnami/charts/tree/master/bitnami/mariadb-galera#bootstraping-a-node-other-than-0.TODO
my.cnf
. It now matches the choice we made here.