Configurazione di un cluster di database ad alta disponibilità utilizzando MariaDB Galera, ProxySQL, Keepalived e Debian 13

Introduzione

Man mano che le vostre applicazioni crescono in termini di dimensioni e importanza, garantire una disponibilità continua diventa fondamentale. I tempi di inattività del database possono comportare perdite di fatturato, insoddisfazione degli utenti e danni alla vostra reputazione. Questa guida illustra come creare un cluster MariaDB ad alta disponibilità (HA) sfruttando la replica Galera, ProxySQL per l’instradamento intelligente delle query e Keepalived per la gestione degli IP virtuali su Debian.

Questa architettura combina i punti di forza di ciascuna tecnologia per fornire un ambiente di database robusto e resiliente. MariaDB Galera fornisce una replica multi-master sincrona, garantendo la coerenza dei dati su più nodi. ProxySQL funge da router delle query e da bilanciatore di carico, fornendo una gestione intelligente del traffico e alleggerendo il carico sui server di database. Keepalived gestisce un indirizzo IP virtuale, fornendo un unico punto di accesso al cluster e automatizzando il failover in caso di guasti dei nodi.

Questa guida presuppone esperienza nell’amministrazione di sistemi Linux, conoscenza dei concetti di base di rete (TCP/IP, DNS) e familiarità con l’amministrazione dei database. Ci concentreremo sulla configurazione e l’integrazione di queste tecnologie in un ambiente Debian.

Vantaggi principali di questa architettura:

• Alta disponibilità: il failover automatizzato garantisce tempi di inattività minimi.
• Coerenza dei dati: la replica sincrona garantisce la coerenza dei dati su tutti i nodi.
• Prestazioni migliorate: ProxySQL ottimizza l’instradamento delle query e riduce il carico sui server di database.
• Gestione semplificata: un unico indirizzo IP virtuale semplifica la configurazione e l’accesso alle applicazioni.

Cosa ti servirà:

• Tre VPS o server Debian 13.
• Accesso root o sudo a tutti i server.
• Familiarità con l’interfaccia a riga di comando.
• Conoscenza di base delle reti TCP/IP e del DNS.

Prerequisiti

Interconnessione dei nodi

Una corretta risoluzione dei nomi host è essenziale per il corretto funzionamento del cluster. Ogni server deve essere in grado di individuare gli altri server in base al nome. Utilizziamo i nomi host per semplificare la gestione. Gli indirizzi IP dei nodi devono trovarsi nella stessa sottorete.

Mappatura tra nomi host e indirizzi IP

• galera0 (nodo master): 192.168.10.10
• galera1 (nodo slave): 192.168.10.11
• galera2 (nodo slave): 192.168.10.12

È possibile effettuare la risoluzione dei nomi host utilizzando sia il file /etc/hosts che il DNS.

• Utilizzo del file /etc/hosts (configurazione più semplice): questa opzione è indicata per gli ambienti di test e sviluppo. Su ciascun server, aggiungere nel file /etc/hosts le voci che associano il nome host del server al suo indirizzo IP statico.
• Utilizzo del DNS (consigliato per la produzione): per ambienti più grandi o complessi, configurare i record DNS (record A) che mappano i nomi host dei server ai rispettivi indirizzi IP.

Verifica

Dopo aver configurato la risoluzione dei nomi host, verificare che ogni server sia in grado di risolvere i nomi host degli altri server utilizzando il comando ping. Ad esempio, da galera0, eseguire ping galera1. Si dovrebbe ricevere una risposta.

Installazione dei pacchetti necessari

Prima di poter configurare il cluster Galera, è necessario installare i pacchetti MariaDB necessari su ciascun nodo. Questa sezione illustra i passaggi richiesti per i sistemi basati su Debian.

Aggiunta dei repository necessari

Aggiungere i repository necessari utilizzando i seguenti comandi:

apt-get update && apt-get install -y --no-install-recommends lsb-release wget apt-transport-https ca-certificates

wget -nv -O /usr/share/keyrings/proxysql-3.0.x-keyring.gpg 'https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/repo_pub_key.gpg'

echo "deb [signed-by=/usr/share/keyrings/proxysql-3.0.x-keyring.gpg] https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/bookworm/ ./" | tee /etc/apt/sources.list.d/proxysql.list

Aggiornamento del sistema

Per prima cosa, aggiornare gli elenchi dei pacchetti e i pacchetti stessi. Eseguire il comando seguente come root su ciascun nodo:

apt update && apt upgrade -y

Installazione dei pacchetti

Installare i pacchetti necessari su ciascun nodo utilizzando questo comando:

apt install rsync mariadb-server mariadb-client galera-4 proxysql keepalived -y

Protezione dell'installazione di MariaDB

Eseguire lo script di sicurezza su ciascun nodo:

sudo mariadb-secure-installation

Questo script esegue due passaggi fondamentali: ti chiederà di impostare una password root complessa per il server MariaDB e rimuoverà eventuali configurazioni predefinite non sicure. Segui le istruzioni visualizzate sullo schermo per completare questa procedura.

Abilitare l'accesso remoto a MariaDB

Esegui questi comandi per abilitare l'accesso remoto su ciascun nodo:

sed -i "s/.*bind-address.*/bind-address = 0.0.0.0/" /etc/mysql/mariadb.conf.d/50-server.cnf
systemctl restart mariadb

Galera

Galera garantisce la replica sincrona dei dati su tutti i nodi del cluster. Ciò significa che ogni modifica apportata al database su un nodo viene propagata automaticamente e simultaneamente a tutti gli altri nodi. Vantaggi principali di Galera in questa configurazione:

• Alta disponibilità: se un nodo si guasta, gli altri nodi continuano a fornire i dati senza interruzioni. Il cluster promuove automaticamente un nodo funzionante a nodo primario.
• Coerenza dei dati: grazie alla replica sincrona, i dati sono sempre coerenti su tutti i nodi. Ciò elimina il rischio di letture non aggiornate: si legge sempre la versione più recente dei dati.
• Scalabilità in lettura: poiché i dati vengono replicati su più nodi, è possibile distribuire le query di lettura su tutto il cluster per migliorare le prestazioni in lettura.

In sostanza, Galera garantisce che il database MariaDB rimanga altamente disponibile, coerente e scalabile: requisiti fondamentali per molte applicazioni.

Configurazione

Creare un file di configurazione /etc/mysql/conf.d/galera.cnf su ciascun nodo. Il contenuto sarà identico, ad eccezione del nome e dell’indirizzo di ciascun nodo. Incollare questo modello:

[mysqld]
# Basic MariaDB settings
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0 # Binds to all network interfaces. Adjust if you have a specific private IP for cluster traffic.
# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so # Adjust path if different (e.g., /usr/lib64/galera-4/libgalera_smm.so)
# Galera Cluster Configuration
wsrep_cluster_name="my_galera_cluster" # A unique name for your cluster
# IP addresses of ALL nodes in the cluster, comma-separated.
# Use private IPs if available for cluster communication.
wsrep_cluster_address="gcomm://galera0,galera1,galera2"
# This node's specific configuration
wsrep_node_name="<node_name>" # Must be unique for each node (e.g., node1, node2, node3)
wsrep_node_address="<node_address>" # This node's own IP address

Modifica <node_name> e <node_address> su ciascun nodo. Usa galera0 per il primo nodo e così via.

Avvia il cluster

Avviare il cluster sul primo nodo utilizzando questo comando:

sudo systemctl stop mariadb && sudo galera_new_cluster

Riavviare MariaDB sugli altri nodi:

sudo systemctl restart mariadb

Verifica della configurazione

Verifica le dimensioni del cluster

Connettersi a MariaDB su un nodo qualsiasi e verificare lo stato del cluster. Connettersi al database:

sudo mariadb -u root -p

Verifica lo stato dei nodi del cluster nella shell di MariaDB:

SHOW STATUS LIKE 'wsrep_cluster_size';

wsrep_cluster_size dovrebbe essere pari al numero dei nostri nodi.

MariaDB [galtest]> SHOW STATUS LIKE
'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+
1 row in set (0.001 sec)

MariaDB [galtest]>

Testare la replica

Creare un database di prova su un nodo qualsiasi e inserire un messaggio di prova. Eseguire i seguenti comandi dalla shell di MariaDB:

CREATE DATABASE galtest;
USE galtest;
CREATE TABLE messages (id INT AUTO_INCREMENT PRIMARY KEY, text VARCHAR(255));
INSERT INTO messages (text) VALUES ('Test from galera0!');

Quindi verificare i dati sugli altri nodi utilizzando la seguente query SQL tramite la shell di MariaDB:

USE galtest;
SELECT * FROM messages;

Il messaggio di prova dovrebbe apparire:

MariaDB [galtest]> USE galtest;
Database changed
MariaDB [galtest]> SELECT * FROM messages;
+----+--------------------+
| id | text               |
+----+--------------------+
|  7 | Test from galera0! |
+----+--------------------+
1 row in set (0.001 sec)

MariaDB [galtest]>

ProxySQL

ProxySQL, in questa configurazione di cluster, è molto più di un semplice intermediario: migliora notevolmente le prestazioni, l’affidabilità e la gestibilità del database. ProxySQL funge da livello cruciale tra le applicazioni e il cluster Galera. I suoi scopi principali sono:

• Caching delle query: ProxySQL memorizza in modo aggressivo nella cache le query eseguite frequentemente. Anziché interrogare ripetutamente il cluster Galera per gli stessi dati, fornisce il risultato memorizzato nella cache, riducendo significativamente il carico sul database e migliorando i tempi di risposta. Ciò è particolarmente vantaggioso per le applicazioni con un'elevata attività di lettura.
• Pool di connessioni: ProxySQL gestisce un pool di connessioni persistenti al cluster Galera. Stabilire una connessione al database è un’operazione che richiede molte risorse. Il pool di connessioni evita questo sovraccarico riutilizzando le connessioni esistenti, aumentando ulteriormente le prestazioni.
• Bilanciamento del carico e instradamento delle query: ProxySQL è in grado di instradare in modo intelligente le query verso diversi nodi del cluster Galera in base a fattori quali il carico del server, il tipo di query o l’affinità dei dati. Ciò consente di distribuire il carico di lavoro e massimizzare le prestazioni del cluster.
• Ottimizzazione delle query: ProxySQL è in grado di riscrivere le query per renderle più efficienti, sfruttando potenzialmente le funzionalità di Galera per un’esecuzione ottimale.
• Rilevamento dei guasti e instradamento: ProxySQL monitora costantemente lo stato di salute dei nodi Galera. Se un nodo si guasta, ProxySQL reindirizza automaticamente le query verso i nodi funzionanti, garantendo un servizio ininterrotto.

In sostanza, ProxySQL funge da gestore intelligente del traffico e da ottimizzatore delle prestazioni per il cluster Galera, migliorandone significativamente l’efficienza e la resilienza.

Precauzioni

Configurazione degli utenti

Utente di monitoraggio

L'utente di monitoraggio all'interno di ProxySQL è un account di database dedicato esclusivamente agli strumenti di monitoraggio, per accedere in modo sicuro a statistiche e metriche interne. È configurato con autorizzazioni minime – solo accesso SELECT – garantendo l'integrità e la sicurezza dei vostri dati e consentendo al contempo un monitoraggio completo delle prestazioni.

Eseguire questa query nella shell di MariaDB sul nodo master per aggiungere l’utente di monitoraggio:

CREATE USER 'monitor'@'%' IDENTIFIED BY 'monitor';
GRANT SELECT ON *.* TO 'monitor'@'%';
FLUSH PRIVILEGES;

Utente dell’applicazione

L'utente dell'applicazione all'interno di ProxySQL è un account di database standard utilizzato dalle applicazioni per connettersi ed eseguire query sul cluster Galera sottostante. È tramite questo utente che l'applicazione interagisce direttamente con il database, recuperando e manipolando i dati.

Esegui questa query nella shell di MariaDB sul nodo master per aggiungere l’utente dell’applicazione:

GRANT ALL PRIVILEGES ON *.* TO 'test'@'%' IDENTIFIED BY 'test' WITH GRANT OPTION;
FLUSH PRIVILEGES;

Verifica

Verificare la creazione dell’utente su tutti i nodi utilizzando questo comando:

mariadb -u root -e "SELECT user, host FROM mysql.user;"

Configurazione

Creare un file di configurazione /etc/proxysql.cnf su ciascun nodo e incollare il seguente contenuto:

datadir="/var/lib/proxysql"

admin_variables=
{
        admin_credentials="admin:admin"
        mysql_ifaces="127.0.0.1:6032"
}

mysql_variables=
{
        threads=4
        max_connections=2048
        monitor_username="monitor"
        monitor_password="monitor"
}

mysql_servers=
(
        { address="galera0" , port=3306 , hostgroup=0 },
        { address="galera1" , port=3306 , hostgroup=0 },
        { address="galera2" , port=3306 , hostgroup=0 }
)

mysql_users=
(
        { username = "test" , password = "test" , default_hostgroup = 0 , active = 1 }
)

mysql_query_rules=
(
        {
                rule_id=2
                active=1
                match_pattern="^SELECT.*"
                destination_hostgroup=0
                apply=1
        }
)

Abilita e avvia ProxySQL utilizzando questi comandi:

sudo systemctl start proxysql
sudo systemctl enable proxysql
sudo proxysql --reload

Verifica la configurazione di ProxySQL utilizzando questo comando:

mysql -u admin -padmin -h 127.0.0.1 -P6032 -e "SELECT hostname, status FROM mysql_servers;"

Tutti i nodi devono essere online:

+----------+--------+
| hostname | status |
+----------+--------+
| galera0  | ONLINE |
| galera1  | ONLINE |
| galera2  | ONLINE |
+----------+--------+

Keepalived

Keepalived gestisce un indirizzo IP virtuale, fornendo un unico punto di accesso al cluster e automatizzando il failover in caso di guasti dei nodi. Monitora lo stato di salute dei nodi MariaDB e reindirizza il traffico verso un nodo funzionante se si verifica un guasto, garantendo un'elevata disponibilità. La configurazione definisce l'ID del router virtuale 51 e utilizza l'interfaccia eth0. Sul nodo master, lo stato è impostato su MASTER con una priorità di 100. I nodi di backup sono configurati con lo stato BACKUP, con priorità rispettivamente di 90 e 80. Il parametro virtual_ipaddress è impostato su 192.168.10.50 su tutti i nodi. Il VIP e i nodi devono trovarsi nella stessa sottorete. L’hosting deve supportare il VIP per i VPS. L’autenticazione è abilitata con una password condivisa pari a 1234. L’impostazione advert_int definisce la frequenza con cui il nodo master invia gli annunci VRRP. Un valore più basso comporta annunci più frequenti, accelerando potenzialmente il rilevamento del failover; un valore più alto comporta annunci meno frequenti, ritardando potenzialmente il failover ma riducendo il sovraccarico di rete.

Configurazione

Creare un file di configurazione /etc/keepalived/keepalived.conf su ciascun nodo e incollare il seguente contenuto:

vrrp_instance VI_1 {
    state <NODE_STATE>
    interface eth0
    virtual_router_id 51
    priority <NODE_PRIORITY>
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.10.50/24
    }
}

Modificare <NODE_STATE> e <NODE_PRIORITY> come descritto sopra. Abilitare e avviare il servizio keepalived:

sudo systemctl enable keepalived && sudo systemctl start keepalived

Verifica

Per verificare la configurazione, utilizzare il VIP configurato tramite Keepalived e la porta configurata tramite ProxySQL. Controllare, ad esempio, la dimensione del cluster:

mariadb -u test -ptest -h 192.168.10.50 -P6033 -D galtest -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

La risposta prevista deve corrispondere alla verifica di Galera:

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

Ora è possibile riavviare i nodi in modo casuale, verificare le dimensioni del cluster e la disponibilità dei dati.

Conclusione

Questa guida ha illustrato come creare un cluster MariaDB ad alta disponibilità utilizzando la replica Galera, ProxySQL per l’instradamento delle query e Keepalived per la gestione degli IP virtuali su Debian. Questa architettura offre diversi vantaggi chiave, tra cui l’alta disponibilità con failover automatizzato, la coerenza dei dati grazie alla replica sincrona e prestazioni migliorate tramite ProxySQL. Combinando queste tecnologie, è possibile creare un ambiente di database robusto e resiliente, in grado di gestire carichi di lavoro crescenti e ridurre al minimo i tempi di inattività.