Configurare lo slave MySQL con replica SSL

Questo articolo spiega passo passo come configurare uno slave MySQL che si connette via SSL al master. Troverai i comandi da inserire, il file di configurazione /etc/my.cnf, come importare lo snapshot SQL, come eseguire CHANGE MASTER TO e come verificare lo stato della replica. Inclusi checklist operativi, risoluzione dei problemi e un runbook per incidenti.

Intento primario e varianti rilevanti

Intento primario: configurare uno slave MySQL
Varianti: replica MySQL SSL, CHANGE MASTER TO, SHOW SLAVE STATUS, replicate-do-db, import snapshot MySQL

Prerequisiti

Accesso root sui server master e slave.
Utente replicazione sul master con i privilegi GRANT necessari.
File snapshot.sql creato dal master o da un backup coerente.
Certificati SSL già generati e copiati nello slave (es. /etc/mysql/newcerts/).
MySQL installato su entrambi i server.

1. Preparare il file di configurazione dello slave

Apri /etc/my.cnf sul server2 e assicurati che nella sezione [mysqld] ci siano le impostazioni essenziali: server-id, master-connect-retry e replicate-do-db.

server2:

vi /etc/my.cnf

Inserisci o verifica il blocco di configurazione seguente (adattalo se necessario):

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
ssl
server-id=2
master-connect-retry=60
replicate-do-db=exampledb

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Nota importante: il valore di server-id deve essere univoco e differente rispetto a quello del master!

Poi riavvia MySQL sullo slave:

/etc/init.d/mysqld restart

2. Creare il database vuoto sullo slave e importare lo snapshot

Prima di iniziare la replica, crea un database vuoto exampledb su server2:

mysql -u root -p

All’interno della shell MySQL:

CREATE DATABASE exampledb;
quit;

Spegni eventuali slave in esecuzione, spostati nella directory temporanea e importa lo snapshot.sql:

/usr/bin/mysqladmin --user=root --password=yourrootsqlpassword stop-slave
cd /tmp
mysql -u root -pyourrootsqlpassword exampledb < snapshot.sql

Quindi riconnettiti a MySQL:

mysql -u root -p

3. Eseguire CHANGE MASTER TO (configurazione della replica)

Esegui il comando CHANGE MASTER TO sullo slave per puntare al master. È fondamentale sostituire i valori con quelli ottenuti su server1 eseguendo SHOW MASTER STATUS; sul master.

CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_USER='slave_user', MASTER_PASSWORD='slave_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=3096416, MASTER_SSL=1, MASTER_SSL_CA = '/etc/mysql/newcerts/ca-cert.pem', MASTER_SSL_CERT = '/etc/mysql/newcerts/client-cert.pem', MASTER_SSL_KEY = '/etc/mysql/newcerts/client-key.pem';

Spiegazione rapida dei parametri:

MASTER_HOST: IP o nome host del master (es. 192.168.0.100).
MASTER_USER: utente creato sul master per la replica.
MASTER_PASSWORD: password di MASTER_USER sul master.
MASTER_LOG_FILE e MASTER_LOG_POS: valori restituiti da SHOW MASTER STATUS; sul master.
MASTER_SSL: imposta su 1 per usare SSL tra slave e master.
MASTER_SSL_CA / MASTER_SSL_CERT / MASTER_SSL_KEY: percorsi dei certificati sullo slave.

4. Avviare lo slave e verificare lo stato

Avvia il processo di replica con:

START SLAVE;

Controlla lo stato dello slave:

SHOW SLAVE STATUS \G

È fondamentale che i campi Slave_IO_Running e Slave_SQL_Running risultino entrambi “Yes”. Se uno dei due non è “Yes”, la replica non funziona correttamente e va investigata.

Esempio di output atteso (sullo slave):

mysql> SHOW SLAVE STATUS \G
************************* 1. row *************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.100
Master_User: slave_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 3096416
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 235
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: exampledb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 3096416
Relay_Log_Space: 235
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
Master_SSL_CA_File: /etc/mysql/newcerts/ca-cert.pem
Master_SSL_CA_Path:
Master_SSL_Cert: /etc/mysql/newcerts/client-cert.pem
Master_SSL_Cipher:
Master_SSL_Key: /etc/mysql/newcerts/client-key.pem
Seconds_Behind_Master: 0
1 row in set (0.00 sec)

mysql>

Dopo le verifiche, esci dalla shell MySQL sullo slave:

quit;

Ora, ogni volta che exampledb viene aggiornato sul master, le modifiche verranno replicate su exampledb dello slave.

Risoluzione problemi comuni

Slave_IO_Running = No:
- Verifica connettività di rete tra slave e master.
- Controlla MASTER_HOST, MASTER_USER e MASTER_PASSWORD.
- Verifica che il firewall e SELinux non blocchino la porta 3306.
Slave_SQL_Running = No:
- Controlla eventuali errori eseguendo SHOW SLAVE STATUS \G e leggendo Last_Error.
- Potrebbe essere necessario applicare manualmente uno o più eventi o usare SET GLOBAL sql_slave_skip_counter per casi particolari (usare con cautela).
Errori SSL:
- Verifica i percorsi di MASTER_SSL_CA, MASTER_SSL_CERT e MASTER_SSL_KEY.
- Controlla permessi file e che i certificati siano validi.
Posizioni non corrispondenti (MASTER_LOG_POS):
- Assicurati di aver importato lo snapshot corrispondente alla posizione indicata dal master quando hai creato lo snapshot.

Controlla i log di sistema e i log MySQL (/var/log/mysqld.log o /var/log/mysql/error.log) per messaggi dettagliati.

Criteri di accettazione

Slave avviato e raggiungibile dal master.
SHOW SLAVE STATUS \G mostra Slave_IO_Running: Yes e Slave_SQL_Running: Yes.
Replicate_Do_DB contiene il database target (exampledb) e non sono presenti errori in Last_Error.
Seconds_Behind_Master è 0 o un valore coerente con il carico e la latenza di rete.

Checklist operativa (DBA / DevOps)

Per il DBA:

Verificare che l’utente di replica esista sul master e abbia GRANT REPLICATION SLAVE.
Prendere lo snapshot coerente o usare mysqldump –master-data.
Comunicare la finestra di manutenzione se l’importazione richiede downtime.

Per il DevOps / Systems:

Assicurarsi che il firewall permetta la porta 3306 tra server.
Copiare i certificati SSL in /etc/mysql/newcerts/ con permessi corretti.
Monitorare spazio su disco per relay-log e binlog.

Runbook di incidente rapido (se la replica si ferma)

Eseguire SHOW SLAVE STATUS \G e annotare Last_Error, Last_Errno, Slave_IO_Running, Slave_SQL_Running.
Se Slave_IO_Running = No, testare con telnet MASTER_HOST 3306 o nc -vz MASTER_HOST 3306.
Se errore di autenticazione, verificare user/password sul master e/o reimpostare la password.
Se errore dovuto a file di log (MASTER_LOG_FILE/MASTER_LOG_POS mismatch), verificare snapshot e, se necessario, ricreare snapshot coerente.
Se errore SQL durante l’applicazione degli eventi, analizzare Last_Error e correggere la riga problematica sullo slave, quindi START SLAVE.
Se serve rollback rapido, STOP SLAVE; prendere backup dei relay-log, eseguire le correzioni e poi START SLAVE.

Important: evitare di usare soluzioni come RESET SLAVE o CHANGE MASTER senza comprendere l’impatto sui dati; documentare sempre i passaggi e i backup.

Note di sicurezza e conformità

Proteggi i certificati SSL con permessi restrittivi (es. 640) e proprietario mysql o root.
Non inserire password in chiaro in script non protetti; usa credenziali sicure e gestione dei segreti dove possibile.
Se i dati contengono informazioni personali, valuta l’impatto GDPR: crittografia in transito (SSL) è obbligatoria; considera anche cifratura a riposo e controlli di accesso.

Alternative e miglioramenti

Replica binlog-based vs statement-based: valuta il formato binlog (ROW o MIXED) in base al carico e ai requisiti di coerenza.
Replica asincrona vs semi-sincrona: la replica semi-sincrona può ridurre il rischio di perdita dati, ma aumenta la latenza.
Utilizzare orchestratori (Percona XtraDB Cluster, Galera, Group Replication) per alta disponibilità se serve failover automatico.

Suggerimenti di test

Esegui inserimenti/aggiornamenti sul master e verifica che compaiano sullo slave.
Simula latenza di rete o interruzione del master per vedere come si comporta la replica.
Controlla l’uso di risorse (CPU/I/O) durante i grandi batch di scrittura.

Piccola cassetta degli attrezzi (comandi utili)

Riavvia MySQL: /etc/init.d/mysqld restart
Avvia replica: START SLAVE;
Ferma replica: STOP SLAVE;
Controlla stato: SHOW SLAVE STATUS \G
Creare DB: CREATE DATABASE exampledb;
Import snapshot: mysql -u root -pyourrootsqlpassword exampledb < snapshot.sql

Riepilogo

Configurare lo slave richiede: impostare server-id unico, creare il database vuoto, importare uno snapshot coerente, eseguire CHANGE MASTER TO con i parametri corretti (compresi i percorsi SSL) e avviare la replica. Verifica sempre SHOW SLAVE STATUS \G e monitora Slave_IO_Running e Slave_SQL_Running.

Link utili