Unable to setup galera cluster

[darkt2]

Name and Version

bitname/mariadb-galera

What architecture are you using?

amd64

What steps will reproduce the bug?

We are using a docker environment to setup a galera cluster with 3 nodes:

The compose file is:

services:
  galera1:
    hostname: galera1
    volumes:
      - ./data/galera1:/bitnami/mariadb
    env_file:
      - ./.env
    environment:
      - MARIADB_GALERA_CLUSTER_BOOTSTRAP=yes
    image: bitnami/mariadb-galera:latest
    user: root
  galera2:
    hostname: galera2
    volumes:
      - ./data/galera2:/bitnami/mariadb
    env_file:
      - ./.env
    image: bitnami/mariadb-galera:latest
    user: root
  galera3:
    hostname: galera3
    volumes:
      - ./data/galera3:/bitnami/mariadb
    env_file:
      - ./.env
    image: bitnami/mariadb-galera:latest
    user: root
networks: {}

and the environment file is:

MARIADB_GALERA_CLUSTER_NAME=dockgalera
MARIADB_GALERA_MARIABACKUP_USER=caesar
MARIADB_GALERA_MARIABACKUP_PASSWORD=caesar
MARIADB_ROOT_PASSWORD=caesar
MARIADB_REPLICATION_USER=caesarrep
MARIADB_REPLICATION_PASSWORD=caesar
MARIADB_GALERA_CLUSTER_ADDRESS=gcomm://galera1,galera2,galera3

We start the cluster with docker compose up

What is the expected behavior?

I expected the cluster to start and do a bootstrap from this node

What do you see instead?

Every time we do a clean startup (all datafiles cleaned) The cluster does not start.
The first node stops to work with the following error:

2025-01-21  8:34:21 0 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates. To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .
2025-01-21  8:34:21 0 [ERROR] WSREP: wsrep::connect(gcomm://) failed: 7
2025-01-21  8:34:21 0 [ERROR] Aborting

See attached log file

galera-galera1-1-2025-01-21T08-34-45.log

galera-galera1-1-2025-01-21T08-34-45.log

[carrodher]

Hi, the issue may not be directly related to the Bitnami container image/Helm chart, but rather to how the application is being utilized, configured in your specific environment, or tied to a particular scenario that is not easy to reproduce on our side.

If you think that's not the case and want to contribute a solution, we'd like to invite you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.

Your contribution will greatly benefit the community. Please feel free to contact us if you have any questions or need assistance.

If you have any questions about the application, customizing its content, or using technology and infrastructure, we highly recommend that you refer to the forums and user guides provided by the project responsible for the application or technology.

With that said, we'll keep this ticket open until the stale bot automatically closes it, in case someone from the community contributes valuable insights.

[darkt2]

Hey carrodher,

thank you for your reply. I think you are wrong here because I did not even connect an application.

I just followed your description provided here: https://github.com/bitnami/containers/blob/main/bitnami/mariadb-galera/README.md

The initial setup of the Galera environment is not working. The problem is:

Although specifying the MARIADB_GALERA_CLUSTER_BOOTSTRAP=yes variable it is ignored during the setup process.

Let me know if I can provide details or log files

greetings Thomas

[darkt2]

I also conducted a test where I provided the additional parameter:

MARIADB_GALERA_FORCE_SAFETOBOOTSTRAP=yes

In this scenario, the outcome remains the same. However, a second restart of the Docker container leads to a functional environment. That said, I still need to manually restart node2 and node3 afterward.

I suspect the issue might be related to the two MariaDB startups during the initial system setup:

1. The first startup is for the MariaDB setup, and this might reset the safe_to_boot variable in the grastate.dat file.
2. As a result, the subsequent MariaDB startup fails to create the cluster.

Best regards,
Thomas

[darkt2]

I made some further tests and only started node 1 (removing node2 and node3 from the docker compose file)

That works fine.
Adding the other two nodes later on
Everythink works fine

So maybe there is an issue in the container if the other two nodes are up and waiting for their sst?