Centro di Conoscenza DevOps
Centro di Conoscenza DevOps

Configurazione della Replica Asincrona di MySQL: Guida Passo-Passo

Padroneggia la configurazione della replica asincrona di MySQL con questa guida definitiva passo-passo. Impara a configurare correttamente sia i server Master che Slave regolando le impostazioni di `my.cnf`, stabilendo account utente di replica sicuri ed eseguendo snapshot iniziali critici dei dati utilizzando `mysqldump`. Questo articolo fornisce comandi pratici e suggerimenti essenziali per la risoluzione dei problemi per garantire una sincronizzazione dei dati efficiente e ridurre al minimo la latenza di replica per un'architettura di database scalabile.

43 visualizzazioni

Configurazione della Replica MySQL Asincrona: Una Guida Passo-Passo

La replica MySQL è una funzionalità fondamentale per ottenere alta disponibilità, scalabilità e strategie di backup robuste. La replica asincrona, il tipo più comune, assicura che i dati scritti sul server primario (Master) vengano infine copiati su uno o più server secondari (Slave), senza che il Master attenda la conferma della transazione da parte dello Slave.

Questa guida completa fornisce un tutorial dettagliato, passo dopo passo, per configurare un'installazione standard di replica asincrona Master-Slave utilizzando MySQL. Tratteremo le modifiche di configurazione del server necessarie, la creazione degli utenti e i passaggi critici per l'inizializzazione della sincronizzazione dei dati.

Prerequisiti e Panoramica

Prima di iniziare la configurazione, assicurati di avere:

  1. Due server MySQL funzionanti (Server A: Master, Server B: Slave).
  2. Connettività di rete tra i due server (solitamente la porta TCP 3306 deve essere aperta).
  3. Accesso root o amministrativo per configurare entrambe le istanze MySQL e modificare i file di configurazione my.cnf o my.ini.

Ai fini di questa guida, assumiamo che l'IP del Server Master sia 192.168.1.100 e l'IP del Server Slave sia 192.168.1.101.

Fase 1: Configurazione del Server Master

Il server Master deve essere configurato per registrare tutti gli eventi di modifica dei dati in un file di log binario, che lo Slave leggerà.

Passaggio 1: Modificare il File di Configurazione del Master (my.cnf)

Individua il file di configurazione di MySQL (tipicamente /etc/mysql/my.cnf o /etc/my.cnf) e aggiungi o modifica le seguenti direttive all'interno della sezione [mysqld].

[mysqld]
# 1. ID univoco per questo server (deve essere maggiore di 0)
server-id=1

# 2. Abilita il logging binario
log-bin=mysql-bin

# 3. Elenco dei database da replicare (opzionale, ma consigliato)
# binlog-do-db=mydatabase

# 4. Opzionale: Assicura che la connessione utilizzi TCP/IP, utile per i test
# bind-address=0.0.0.0

Nota: L'server-id deve essere univoco in tutta la topologia di replica.

Passaggio 2: Riavviare MySQL e Verificare il Logging Binario

Dopo aver salvato il file di configurazione, riavvia il servizio MySQL sul server Master.

# Debian/Ubuntu
sudo systemctl restart mysql
# RHEL/CentOS
sudo systemctl restart mysqld

Accedi all'interfaccia a riga di comando di MySQL e verifica che il logging binario sia attivo:

SHOW VARIABLES LIKE 'log_bin';
-- Il valore dovrebbe essere ON

Passaggio 3: Creare l'Utente di Replica

La replica richiede un account utente dedicato sul server Master con privilegi specifici che lo Slave utilizzerà per connettersi e recuperare i log binari. Assicurati che questo utente possa connettersi in remoto dall'indirizzo IP dello Slave (192.168.1.101).

CREATE USER 'repl_user'@'192.168.1.101' IDENTIFIED BY 'secure_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.1.101';
FLUSH PRIVILEGES;

Passaggio 4: Registrare lo Stato Attuale del Master

Prima di procedere, dobbiamo stabilire la posizione esatta (File e Posizione) nel log binario da cui lo Slave deve iniziare a leggere. Questo passaggio è critico per la sincronizzazione.

FLUSH TABLES WITH READ LOCK; -- Interrompe temporaneamente le scritture
SHOW MASTER STATUS;

-- IMPORTANTE: Prendi nota di questi due valori:
-- File: mysql-bin.000001
-- Position: 1234

-- NON SBLOCCARE LE TABELLE SE STAI EFFETTUANDO UNO SNAPSHOT INIZIALE (Passaggio 6)

Fase 2: Configurazione del Server Slave

Passaggio 5: Modificare il File di Configurazione dello Slave (my.cnf)

Configura il server Slave con un ID univoco e impostazioni opzionali.

[mysqld]
# ID univoco per questo server (deve essere diverso dal Master)
server-id=2

# Opzionale: Consigliato per sicurezza
read_only=1

# Opzionale: Abilita il relay logging
relay_log=mysql-relay-bin

Riavvia il servizio MySQL sul server Slave dopo aver salvato le modifiche.

Passaggio 6: Trasferimento Iniziale dei Dati (Snapshot)

Se il server Slave è vuoto, devi popolarlo con la struttura dei dati e il contenuto attuali del Master. Questo snapshot iniziale deve essere acquisito mentre le tabelle del Master sono bloccate (dal Passaggio 4).

Dal server Master, esegui il comando mysqldump. Utilizziamo il flag --master-data=2 per includere automaticamente l'istruzione necessaria CHANGE MASTER TO nel file di dump, il che semplifica il Passaggio 7.

# Esegui sulla console/shell del server Master
mysqldump -u root -p --all-databases --master-data=2 --single-transaction > master_dump.sql

# Ora, torna alla CLI MySQL del Master e rilascia il blocco
UNLOCK TABLES;

Trasferisci master_dump.sql al server Slave e importalo:

# Esegui sulla console/shell del server Slave
mysql -u root -p < master_dump.sql

Best Practice: L'uso di master-data=2 è altamente raccomandato poiché automatizza la cattura della posizione corretta del log binario proprio all'inizio del dump.

Fase 3: Avvio della Replica

Passaggio 7: Definire la Connessione al Master

Sulla riga di comando MySQL del server Slave, esegui il comando CHANGE MASTER TO, sostituendo i valori annotati nel Passaggio 4 e l'utente creato nel Passaggio 3.

CHANGE MASTER TO
    MASTER_HOST='192.168.1.100',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='secure_password',
    MASTER_LOG_FILE='mysql-bin.000001', -- Il File registrato nel Passaggio 4
    MASTER_LOG_POS=1234;              -- La Posizione registrata nel Passaggio 4

Passaggio 8: Avviare la Replica e Verifica

Dopo aver definito i parametri di connessione, avvia i thread di replica dello Slave.

START SLAVE;

Verifica che i thread di replica siano in esecuzione e comunichino correttamente utilizzando il comando SHOW SLAVE STATUS\G:

SHOW SLAVE STATUS\G

Esamina l'output per i seguenti campi critici:

Campo Valore Atteso Descrizione
Slave_IO_Running Yes Lo Slave si sta connettendo con successo al Master.
Slave_SQL_Running Yes Lo Slave sta applicando le transazioni al suo database.
Seconds_Behind_Master 0 o numero basso Indica la latenza di replica. Dovrebbe scendere rapidamente a 0.

Se uno tra Slave_IO_Running o Slave_SQL_Running mostra No, esamina i campi Last_IO_Error o Last_SQL_Error per indizi di risoluzione dei problemi (ad esempio, problemi di firewall, credenziali errate, chiavi duplicate).

Risoluzione dei Problemi e Suggerimenti per la Manutenzione

Gestione degli Errori di Replica

Se lo Slave incontra un errore (ad esempio, tenta di inserire una chiave primaria duplicata), il thread Slave_SQL_Running si interromperà. Di solito è possibile ignorare errori minori e non critici utilizzando:

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

Avvertenza: Utilizza SQL_SLAVE_SKIP_COUNTER con giudizio. Saltare le transazioni può portare a una divergenza dei dati (incoerenza) tra Master e Slave.

Verifica della Coerenza

Sebbene la replica asincrona sia efficiente, non garantisce una coerenza immediata. Per ambienti ad alto rischio, utilizza strumenti come pt-table-checksum di Percona Toolkit per verificare periodicamente la deriva dei dati tra Master e Slave.

Gestione dei Log Binari

I log binari consumano spazio su disco nel tempo. Configura la scadenza dei log sul Master per prevenire un uso eccessivo del disco:

[mysqld]
# Rimuovi i log binari più vecchi di 7 giorni (604800 secondi)
expire_logs_days=7