Versão avaliada: Debian 13 (Trixie)
O Galera prioriza a disponibilidade e integridade sobre a economia de espaço, portanto para bases grandes esta não e a melhor técnica
Pré-requisitos:
Preferencialmente 3 servidores MariaDB
Portas: 3306 MariaDB padrão, 4567 Tráfego de replicação do Galera, 4568 IST (Incremental State Transfer), 4444 SST (State Snapshot Transfer).
# apt install mariadb-server mariadb-client galera-4 rsync
Realizar a configuração em ambos os servidores MariaDB.
Acessar o arquivo de configuração no NODE01:
# vi /etc/mysql/mariadb.conf.d/60-galera.cnf
[galera]
# Mandatory settings
wsrep_on = ON
wsrep_cluster_name = "MariaDB Galera Cluster"
wsrep_cluster_address = gcomm://10.1.10.153,10.1.10.154 <- Inserir outros NODEs
binlog_format = row
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
# Allow server to accept connections on all interfaces.
bind-address = 0.0.0.0
wsrep_node_name = hl153 <- Nome do servidor atual
wsrep_node_address = 10.1.10.153 <- IP do servidor atual
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_sst_method = rsync
Acessar o arquivo de configuração no NODE02:
# vi /etc/mysql/mariadb.conf.d/60-galera.cnf
[galera]
# Mandatory settings
wsrep_on = ON
wsrep_cluster_name = "MariaDB Galera Cluster"
wsrep_cluster_address = gcomm://10.1.10.153,10.1.10.154 <- Inserir outros NODEs
binlog_format = row
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
# Allow server to accept connections on all interfaces.
bind-address = 0.0.0.0
wsrep_node_name = hl154 <- Nome do servidor atual
wsrep_node_address = 10.1.10.154 <- IP do servidor atual
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_sst_method = rsync
Pare o MariaDB em ambos os servidores. <- Atenção a este passo.
# systemctl stop mariadb.service
No NODE01 inicialize o cluster
# galera_new_cluster
# ss -ntlup | grep mariadb
tcp LISTEN 0 4096 0.0.0.0:4567 0.0.0.0:* users:(("mariadbd",pid=5104,fd=8))
tcp LISTEN 0 70 0.0.0.0:3306 0.0.0.0:* users:(("mariadbd",pid=5104,fd=34))
No NODE02
# systemctl start mariadb.service
Acesse o console do MariaDB e execute o comando:
> SHOW STATUS LIKE 'wsrep_cluster_status';
> SHOW STATUS LIKE 'wsrep_cluster_size';
> SHOW STATUS LIKE 'wsrep_local_state_comment';
OBs.: O resultado deve ser 2, caso apresentar o resultado 1 o segundo NODE não conseguiu conectar
Para recuperar o funcionamento correto caso uma falha geral siga
Acesse cada NODE e avalie o conteúdo do arquivo para saber qual esta mais atualizado
# cat /var/lib/mysql/grastate.dat
seqno: 1520
safe_to_bootstrap: 1 <- O NODE com maior valor e o ponto de partida
OBs.: Caso todos os parametros "safe_to_bootstrap" estiverem com valor 0, confirme qual servidor tem o maior valor no parâmetro "seqno" e altere manualmente o valor 0 para 1 neste "safe_to_bootstrap".
No NODE com o valor 1 inicialize o cluster
# galera_new_cluster
Nos demais NODEs
# systemctl start mariadb.service
If you shut down all nodes at the same time, then you have effectively terminated the cluster. Of course, the cluster's data still exists, but the running cluster no longer exists. When this happens, you'll need to bootstrap the cluster again.
If the cluster is not bootstrapped and mariadbd on the first node is just started normally, then the node willl try to connect to at least one of the nodes listed in the wsrep_cluster_address option. If no nodes are currently running, then this will fail. Bootstrapping the first node solves this problem.
In some cases Galera will refuse to bootstrap a node if it detects that it might not be the most advanced node in the cluster. Galera makes this determination if the node was not the last one in the cluster to be shut down or if the node crashed. In those cases, manual intervention is needed.
If you know for sure which node is the most advanced you can edit the grastate.dat file in the datadir. You can set safe_to_bootstrap=1 on the most advanced node.
You can determine which node is the most advanced by checking grastate.dat on each node and looking for the node with the highest seqno. If the node crashed and seqno=-1, then you can find the most advanced node by recovering the seqno on each node with the wsrep_recover option. For example:
$ mariadbd --wsrep_recover
Systemd and Galera Recovery
On operating systems that use systemd, the position of a node can be recovered by running the galera_recovery script:
$ galera_recovery
If you are using the systemd service that supports the systemd service's method for interacting with multiple MariaDB Server processes, you can recover the position of a specific instance by specifying the instance name as a suffix:
$ galera_recovery mariadb@node1
The galera_recovery script recovers the position of a node by running mariadbd with the wsrep_recover option.
When the galera_recovery script runs mariadbd, it does not write to the error log. Instead, it redirects mariadbd log output to a file named with the format /tmp/wsrep_recovery.XXXXXX, where XXXXXX is replaced with random characters.
When Galera is enabled, MariaDB's systemd service automatically runs the galera_recovery script prior to starting MariaDB, so that MariaDB starts with the proper Galera position.
Support for systemd and the galera_recovery script were added.