[MDEV-25667] Proposition to add one-shot logic for the --wsrep-new-cluster option Created: 2021-05-13 Updated: 2022-02-15 Resolved: 2022-02-15 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Configuration, Docker, Galera, Server |
| Fix Version/s: | N/A |
| Type: | Task | Priority: | Major |
| Reporter: | Tymoteusz Blazejczyk | Assignee: | Daniel Black |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | Docker, Galera, bootstrap, configuration, containers, docker, galera, replication, server | ||
| Description |
|
Currently there is no easy method and out-of-box option to automatically start MariaDB + Galera with automatic cluster bootstrapping. Galera requires a bootstrap phase that are provided by the galera_new_cluster script for the systemd or calling manually the service mysql bootstrap command for the SysVinit. Both cases requires manual actions. Also this approach will not work with environments without systemd and SysVinit like Docker containers. Current workaround for the MariaDB container to automatically run Galera cluster with automatic cluster bootstrapping is to create a special wrapper for the mysqld daemon and set the GALERA_NEW_CLUSTER=1 environment variable for the first container in the cluster:
The one-shot bootstrapping is provided by the first if statement. Galera during the cluster creation creates the /var/lib/mysql/gvwstate.dat file. This file is used for auto-detecting that cluster was already bootstrapped by the --wsrep-new-cluster option. Proposition:
This should not only simplify running Galera cluster in multi container scenario but in other scenarios also. |
| Comments |
| Comment by Daniel Black [ 2021-05-18 ] |
|
Thanks for the bug report. I quite like your proposals described here. If --wsrep-new-cluster=once implements the -s gvwstate.dat, would that mean MARIADB_NEW_CLUSTER/GALERA_NEW_CLUSTER isn't needed in the container entrypoint (compose command: --wsrep-new-cluster=once is sufficent)? for ref, another bootstrap vs join implementation - https://github.com/bitnami/bitnami-docker-mariadb-galera/blob/master/10.5/debian-10/rootfs/opt/bitnami/scripts/libmariadbgalera.sh |
| Comment by Tymoteusz Blazejczyk [ 2021-05-18 ] |
|
Thanks for quick response and activity. It should be sufficient to pass --wsrep-new-cluster=once to the command: section of Docker Compose, Docker Swarm Stack or even Kubernetes/Helm pod YAML configuration files. The environment variable proposition is only an alternative for passing additional command line argument if someone prefer to use the environment: section over the command: section. Having both possibilities (by passing additional command line option or by passing environment variable) is nice but passing only the --wsrep-new-cluster=once is sufficient. |
| Comment by Daniel Black [ 2021-05-19 ] |
|
jplindst are you ok with the concept here? Since wsrep-new-cluster is a GET_BOOL its easier to change this to GET_ULONG, OPT_ARG and process the option by number rather than name. This is a pretty fundamental problem so I'd like to do a backwards compatible 10.2 fix. So I'd change the type and allow --wsrep-new-cluster=2 to have this specific meaning? |
| Comment by Tymoteusz Blazejczyk [ 2021-05-19 ] |
|
This is still WIP (Working In Progress): https://gitlab.com/tymonx/docker-mariadb/-/blob/master/mysqld-entrypoint (look into the main function) but it provides two nice features, auto bootstrapping and auto node joining during Galera cluster creation in multi containers scenario. I have created more descriptive comment here https://github.com/MariaDB/mariadb-docker/issues/28#issuecomment-844295646 Still I don't know if checking presents of the /var/lib/mysql/gvwstate.dat file is quite enough. Maybe there are better methods. I think also it should be quite possible to add automatic replication features to the `mysqld`. This should sky rocket MariaDB popularity beyond the stratosphere |
| Comment by Daniel Black [ 2022-02-15 ] |
|
I think I've achieved this with https://github.com/MariaDB/mariadb-docker/pull/377/commits/38bebe0ae65069c3902dec466753905d17a22311. A bigger discussion of galera automated recover is in MDEV-25855 |