Cluster MariaDB Galera com mariabackup no Ubuntu

Armazém de tijolos em Katajanokka, Helsinque, com o leão-marinho oficial da MariaDB na parede, três servidores em palete e Tux em pé

Três Ubuntu, um Galera, SST com mariabackup. Não é réplica assíncrona: todo nó escreve, o quorum decide. Dois nós não bastam — cai um e o outro fica sozinho sem maioria. Abaixo o cluster de três, do pacote ao galera_new_cluster, no Ubuntu 24.04 e 26.04.

Três nós, um quorum

Galera (Codership, Helsinque) entra no MariaDB como libgalera_smm.so. Cada commit vira um writeset; os outros certificam e aplicam. InnoDB só. MyISAM no cluster é dor. A biblioteca é o pacote galera-4 (wsrep API 26.4.x). O método SST rsync trava o donor; o mysqldump é lento. O mariabackup (o binário hoje se chama mariadb-backup) copia a quente e manda o stream via socat na porta 4444. O donor continua servindo leitura. Por isso três servidores e esse SST.

Os IPs deste howto — troque pelos seus:

db1  10.0.0.11
db2  10.0.0.12
db3  10.0.0.13

Mesma versão de MariaDB nos três. Mesmo wsrep_cluster_name. Relógio razoavelmente junto (NTP/chrony). Disco local; NFS no datadir não.

O mapa em setembro de 2026

  • Ubuntu 24.04 (noble): MariaDB 10.11 e galera-4 26.4.16 na distro. Serve. O patch de segurança do Galera de junho de 2026 (11.8.8 / 11.4.12 / 10.11.18) pede o repo da Fundação se você ainda está no pacote original do ISO.
  • Ubuntu 26.04 (resolute): MariaDB 11.8 no main — LTS até junho de 2028. Galera 26.4.24+. O repo mariadb.org ainda não publica suite resolute; use a distro.
  • Binário de backup: mariadb-backup. O valor de wsrep_sst_method continua mariabackup — o nome antigo do SST. Não misture.

Quem já empilha PHP no mesmo host: Nginx e várias versões de PHP. O GLPI é um dos clientes típicos deste cluster.

Pacotes e o libgalera

Nos três nós. Ubuntu 26.04, distro:

sudo apt update
sudo apt install -y mariadb-server mariadb-backup galera-4 socat

Ubuntu 24.04 com 11.8 da Fundação (recomendado se você quer o Galera patchado):

sudo apt install -y curl ca-certificates apt-transport-https
curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup \
  | sudo bash -s -- --mariadb-server-version="11.8"
sudo apt update
sudo apt install -y mariadb-server mariadb-backup galera-4 socat

O path da biblioteca muda conforme a origem do pacote. Confira de verdade:

dpkg -L galera-4 | grep libgalera_smm.so

Na distro Ubuntu costuma ser /usr/lib/libgalera_smm.so. No repo MariaDB, /usr/lib/galera/libgalera_smm.so. Esse path vai no wsrep_provider. Errar aqui e o mariadbd sobe sem cluster, calado.

Pare o serviço antes de editar — a instalação já deixou um MariaDB sozinho no ar:

sudo systemctl stop mariadb
sudo systemctl enable mariadb

Rede, firewall, AppArmor

Galera fala em quatro portas. Só entre os três IPs, não no mundo:

  • 3306/tcp — cliente SQL
  • 4567/tcp (e UDP se for multicast) — replicação wsrep
  • 4568/tcp — IST
  • 4444/tcp — SST do mariabackup/socat
NET=10.0.0.0/24
for p in 3306 4567 4568 4444; do
  sudo ufw allow proto tcp from "$NET" to any port "$p"
done
sudo ufw allow proto udp from "$NET" to any port 4567
sudo ufw reload

No /etc/hosts dos três:

10.0.0.11  db1
10.0.0.12  db2
10.0.0.13  db3

AppArmor no Ubuntu 26.04 passou o perfil do mariadbd para enforce. SST chama dash + wsrep_sst_mariabackup e o perfil padrão ainda nega. Se o joiner morrer com apparmor="DENIED" no dmesg:

sudo apt install -y apparmor-utils
# 24.04
sudo aa-complain /usr/sbin/mariadbd
# 26.04 (perfil novo)
sudo aa-complain /etc/apparmor.d/mariadbd 2>/dev/null || true
dmesg -T | grep -i apparmor | tail

SST longo estoura o timeout de 90 s do systemd. Nos três:

sudo mkdir -p /etc/systemd/system/mariadb.service.d
sudo tee /etc/systemd/system/mariadb.service.d/galera.conf >/dev/null <<'EOF'
[Service]
TimeoutStartSec=0
EOF
sudo systemctl daemon-reload

60-galera.cnf

O Ubuntu já traz /etc/mysql/mariadb.conf.d/60-galera.cnf. Esvazie o comentário e deixe assim — só mudam wsrep_node_name, wsrep_node_address e, se preciso, o path do .so.

Em db1:

[galera]
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name="linuxpro"
wsrep_cluster_address="gcomm://10.0.0.11,10.0.0.12,10.0.0.13"
wsrep_node_name=db1
wsrep_node_address=10.0.0.11
wsrep_sst_method=mariabackup
wsrep_sst_auth=mariabackup:troque-esta-senha
wsrep_provider_options="gcache.size=1G;gcache.recover=yes"

binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_doublewrite=1
bind-address=0.0.0.0

Em db2 e db3 copie o arquivo e troque só o nome e o IP do nó. O gcomm:// lista os três em todos — Galera ignora o endereço próprio. Não deixe gcomm:// vazio no arquivo permanente: isso bootstrapa um cluster novo a cada start.

No 50-server.cnf, comente o bind-address = 127.0.0.1 se ainda estiver lá. O 60 ganha porque carrega depois, mas não dependa da ordem para sempre.

Usuário do SST

O donor precisa de um usuário local. Na 11.8 a conta temporária automática existe se você não definir wsrep_sst_auth — funciona, mas o howto deixa explícito, igual nos três nós, e serve no 10.11. Suba o MariaDB ainda sem Galera uma vez, crie o usuário, pare de novo. Ou crie depois do bootstrap no db1 e replique. Mais simples: bootstrap primeiro, crie o usuário no cluster (vai para os três), só então junte db2/db3.

Ordem prática deste post: bootstrap db1 com wsrep_sst_auth já no cnf, crie o usuário nele antes de ligar db2.

CREATE USER 'mariabackup'@'localhost' IDENTIFIED BY 'troque-esta-senha';
GRANT RELOAD, PROCESS, LOCK TABLES, BINLOG MONITOR ON *.* TO 'mariabackup'@'localhost';
FLUSH PRIVILEGES;

BINLOG MONITOR é o nome desde 10.5; REPLICATION CLIENT ainda funciona como alias em várias 10.11. O backup conecta em localhost no donor — não abra esse user na rede.

Laboratório em Otaniemi com três racks ligados em malha e Tux em pé no SST

Bootstrap e os dois joiners

Nos três o serviço está parado, o cnf já está no disco. Só o primeiro nó nasce o cluster:

# em db1
sudo galera_new_cluster

Isso é um wrapper systemd que sobe o mariadbd com --wsrep-new-cluster. Confira:

SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';
SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';
SHOW GLOBAL STATUS LIKE 'wsrep_ready';

Esperado: size 1, Synced, ON. Crie agora o usuário SST acima. Depois, nos outros:

# em db2, depois em db3 — um de cada vez
sudo systemctl start mariadb

O joiner pede SST ao donor. Log: journalctl -u mariadb -f e, no datadir, mariadb-backup.backup.log (donor) / mariadb-backup.prepare.log (joiner). Datadir Ubuntu 24.04: /var/lib/mysql. Ubuntu 26.04 da distro: confira — algumas builds 11.8 usam /var/lib/mariadb.

Quando o size for 3 e os três disserem Synced:

SHOW GLOBAL STATUS LIKE 'wsrep_incoming_addresses';
SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status';

Primary. Crie um schema em db1, SHOW DATABASES em db3. Se apareceu, o writeset passou.

Backup a quente e o cluster morto

Backup do cluster é backup de um nó. Tire-o do balancer, desincronize, rode o backup, volte:

mariadb -e "SET GLOBAL wsrep_desync=ON"
sudo mariadb-backup --backup --galera-info \
  --target-dir=/backup/full \
  --user=mariabackup --password='troque-esta-senha'
mariadb -e "SET GLOBAL wsrep_desync=OFF"

O nó pede IST e alcança os outros. wsrep_local_state_comment volta a Synced antes de devolver tráfego.

Se os três caírem juntos, o cluster acabou — os dados não. Olhe grastate.dat em cada datadir. O maior seqno com safe_to_bootstrap: 1 é o bootstrap. Se todos estão seqno: -1 (crash):

sudo galera_recovery

Edite o safe_to_bootstrap para 1 só no mais avançado e:

sudo galera_new_cluster   # nesse nó
sudo systemctl start mariadb   # nos outros dois

Não rode galera_new_cluster num cluster que ainda tem nó no ar — nasce UUID novo e você fende o cérebro.

Quem ainda está no 10.11 da 24.04 e vai pular major: o SST mariabackup não atravessa algumas majors (redo log, MDEV-27437). Nesse pulo use rsync temporário, ou suba o major em todos parados e bootstrap de novo.

O que costuma quebrar

  • wsrep_sst_method=mariadb-backup — nome errado. É mariabackup.
  • wsrep_provider apontando para um .so que o dpkg -L não listou.
  • AppArmor DENIED no joiner; o log do MariaDB só diz “SST failed”.
  • systemd matou o joiner aos 90 s. TimeoutStartSec=0.
  • socat ausente: WSREP_SST: [ERROR] socat not found.
  • Dois nós. Quorum 2/2: um cai, o outro vira Non-Primary. Três, ou um garbd.
  • bind-address=127.0.0.1 ainda ativo: os outros não conectam em 4567.

O git do provider: github.com/codership/galera. Docs: Getting Started · SST: mariadb-backup SST method · opções obrigatórias: Configuring MariaDB Galera Cluster · repo: DEB / apt.