Unable to add arbitrator to galera cluster

[dot-mike]

Name and Version

bitnami/mariadb-galera:11.4.4

What architecture are you using?

amd64

What steps will reproduce the bug?

In my enviornment I have a working galera cluster running 11.4.4 using bitnami docker with a garb arbitrator running on a third node using apt package. I wanted to set-up a new environment today with the exact same set-up and noticed that the arbitrator failed to join the galera cluster. I couldn't figure out why.. until I noticed that the SHA256 for 11.4.4 image had changed. On the environment that works I'm running 11.4.4@sha256:0d70ebcbeebd9320cb4cb05257b00087b724eea12ca202f833cea9d02f21d14e while on this new non-working environment I was getting 11.4.4@sha256:b76d5c5aaa2dfde8c338dedd3122da767d13bec5e4da04e793fe76e8c2a7f3c9

Revering back to using the image tag 11.4.4@sha256:0d70ebcbeebd9320cb4cb05257b00087b724eea12ca202f833cea9d02f21d14e on my new environment allowed for the arbitrator to join without any issues

The error I was receiving in my arbitrator node was:

2025-01-23 07:22:51.540 FATAL: ./gcs/src/gcs_group.cpp:group_check_proto_ver():343: Group requested gcs_proto_ver: 5, max supported by this node: 4.Upgrade the node before joining this group.Need to abort.
2025-01-23 07:22:51.540  INFO: /usr/bin/garbd: Terminated.

So somewhere between this old version and the newest version there is a breakage in the compatibility. MariaDB states on their website that galera version 26.4.20 is to be shipped with version 11.4.4. To my knowledge, there is no newer version of garbd available as 26.4.20 is latest. Why question is then, why does a newer version of this docker image don't allow garbd version 26.4.20 to join?

Environment info

Arbitrator node

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.5 LTS (Jammy Jellyfish)"

$ /usr/bin/garbd --version
 INFO: 26.4.20.r

$ dpkg -s galera-arbitrator-4
Package: galera-arbitrator-4
Status: install ok installed
Priority: optional
Section: database
Installed-Size: 24671
Maintainer: Codership Oy <[email protected]>
Architecture: amd64
Source: galera-4
Version: 26.4.20-ubu2204
Depends: lsb-base (>= 3.0-6), libboost-program-options1.74.0 (>= 1.74.0), libc6 (>= 2.34), libgcc-s1 (>= 3.3.1), libssl3 (>= 3.0.0~~alpha1), libstdc++6 (>= 11)
Conflicts: galera-arbitrator-3, garbd-2, garbd-3, garbd2, garbd3, percona-galera-arbitrator-3, percona-galera-arbitrator-4, percona-xtradb-cluster-garbd-2.x, percona-xtradb-cluster-garbd-3.x, percona-xtradb-cluster-garbd-4.x
Conffiles:
 /etc/default/garb 35ae868c8717c02d348e53dcc2b0e8af
 /etc/init.d/garb cf119e961381dc20236c17f9fe539ffe
Description: Galera arbitrator daemon
 Galera is a fast synchronous multimaster wsrep provider (replication engine)
 for transactional databases and similar applications. For more information
 about wsrep API see https://github.com/codership/wsrep-API. For a description
 of Galera replication engine see http://galeracluster.com.
 .
 This package contains the Galera arbitrator daemon (garbd).
Homepage: https://www.galeracluster.com/

[carrodher]

Taking a look at the changes in the code between both revisions, there is nothing remarkable that could cause any issue... I am wondering if 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.

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.