Replica MySQL con SSL su CentOS 5.4

Questo tutorial mostra come impostare la replica di MySQL (master→slave) su CentOS 5.4 usando connessioni SSL per cifrare il traffico tra i server. Fornisce comandi step-by-step per creare certificati, abilitare SSL, configurare master e slave, trasferire dati e risolvere problemi comuni.

Important: la replica non è un backup. Un comando DELETE sul master viene replicato sullo slave.

Intento primario e varianti correlate

Intento primario: configurare replica MySQL con SSL su CentOS 5.4 Varianti correlate: replica MySQL SSL, replica MySQL CentOS, replica master-slave MySQL, cifratura connessioni MySQL, configurare ssl mysql, mysqld replication ssl

Panoramica e termini chiave

Definizione rapida: la replica MySQL copia le modifiche dal server master a uno o più server slave, mantenendo i dati sincronizzati. Breve glossario (1 riga ciascuno):

Master: server principale che scrive i cambiamenti.
Slave: server che riceve e applica i cambiamenti dal master.
Binlog: file di log binario sul master che registra le modifiche.
SSL: Secure Sockets Layer, qui usato per cifrare la connessione MySQL.

1 Premessa

In questo esempio replichiamo il database exampledb dal server server1.example.com (master, IP 192.168.0.100) al server server2.example.com (slave, IP 192.168.0.101). Entrambi usano CentOS 5.4. Il database exampledb esiste già sul master e non sullo slave. Tutti i comandi qui indicati vengono eseguiti con privilegi root.

Note importanti sulle versioni: i comandi funzionano con le build standard di MySQL 5 su CentOS 5.x. Alcune distribuzioni o versioni più recenti possono richiedere adattamenti (per esempio gestione systemd, percorsi dei file di configurazione o parametri di sicurezza aggiuntivi).

2 Installare MySQL 5 e abilitare SSL

Se MySQL non è installato su server1 e server2, installalo:

server1/server2:

yum install mysql mysql-devel mysql-server

Crea i collegamenti di avvio del servizio e avvia MySQL:

chkconfig –levels 235 mysqld on
/etc/init.d/mysqld start

Imposta la password di root di MySQL (esegui sul server1 e server2):

server1:

mysqladmin -u root password yourrootsqlpassword
mysqladmin -h server1.example.com -u root password yourrootsqlpassword

server2:

mysqladmin -u root password yourrootsqlpassword
mysqladmin -h server2.example.com -u root password yourrootsqlpassword

Verifica che MySQL supporti SSL:

mysql -u root -p

Poi nel prompt MySQL:

show variables like '%ssl%';

Se trovi have_openssl e have_ssl impostati a DISABLED significa che il server è compilato con supporto SSL ma non è attivo. Esci dal prompt:

quit;

Apri /etc/my.cnf e aggiungi la direttiva ssl nella sezione [mysqld]:

vi /etc/my.cnf

E aggiungi (o modifica) in [mysqld]:

[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

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

Riavvia MySQL:

/etc/init.d/mysqld restart

Rientra in MySQL e verifica nuovamente:

mysql -u root -p
show variables like '%ssl%';

Dovresti vedere have_openssl e have_ssl impostati a YES.

3 Configurare il master (server1)

Creare la directory per i binlog:

server1:

mkdir /var/log/mysql
chown mysql:mysql /var/log/mysql

Creare CA, certificati del server e del client

Creiamo i certificati in /etc/mysql/newcerts:

mkdir -p /etc/mysql/newcerts && cd /etc/mysql/newcerts

Crea la CA:

openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem > ca-cert.pem

Crea il certificato del server:

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem > server-req.pem
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem

Crea il certificato del client (usato dallo slave per l’autenticazione SSL al master):

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem > client-req.pem
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem

Esempio di output atteso (ls -l):

[root@server1 newcerts]# ls -l
total 32
-rw-r--r-- 1 root root 1375 Feb  8 17:37 ca-cert.pem
-rw-r--r-- 1 root root 1679 Feb  8 17:37 ca-key.pem
-rw-r--r-- 1 root root 1119 Feb  8 17:37 client-cert.pem
-rw-r--r-- 1 root root 1675 Feb  8 17:37 client-key.pem
-rw-r--r-- 1 root root  968 Feb  8 17:37 client-req.pem
-rw-r--r-- 1 root root 1119 Feb  8 17:37 server-cert.pem
-rw-r--r-- 1 root root 1679 Feb  8 17:37 server-key.pem
-rw-r--r-- 1 root root  968 Feb  8 17:37 server-req.pem
[root@server1 newcerts]#

Trasferire i certificati necessari allo slave

Sul server2 crea la directory:

server2:

mkdir -p /etc/mysql/newcerts

Sul server1 trasferisci ca-cert.pem, client-cert.pem e client-key.pem verso server2 (usando scp):

server1:

scp /etc/mysql/newcerts/ca-cert.pem [email protected]:/etc/mysql/newcerts
scp /etc/mysql/newcerts/client-cert.pem [email protected]:/etc/mysql/newcerts
scp /etc/mysql/newcerts/client-key.pem [email protected]:/etc/mysql/newcerts

Nota: non trasferire la server-key.pem o la ca-key.pem allo slave. La private key della CA (ca-key.pem) deve restare sicura sul master o in un luogo di gestione certificati dedicato.

Configurare mysqld sul master per usare i certificati

Apri /etc/my.cnf e aggiungi i riferimenti a ssl-ca, ssl-cert e ssl-key nella sezione [mysqld]:

vi /etc/my.cnf

Aggiungi/modifica come segue:

[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
ssl-ca=/etc/mysql/newcerts/ca-cert.pem
ssl-cert=/etc/mysql/newcerts/server-cert.pem
ssl-key=/etc/mysql/newcerts/server-key.pem

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

Riavvia MySQL:

/etc/init.d/mysqld restart

Creare l’utente di replica che richiede SSL

Accedi a MySQL sul master:

mysql -u root -p

Esegui:

GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password' REQUIRE SSL;
FLUSH PRIVILEGES;
quit;

Nota: la clausola REQUIRE SSL impone che lo slave usi connessioni SSL. Se la rimuovi, lo slave potrà connettersi anche senza SSL.

Configurare binlog e server-id sul master

Apri /etc/my.cnf e aggiungi/aggiorna i parametri per la replica nella sezione [mysqld]:

vi /etc/my.cnf

Aggiungi i parametri per replicare exampledb:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
old_passwords=1
ssl
ssl-ca=/etc/mysql/newcerts/ca-cert.pem
ssl-cert=/etc/mysql/newcerts/server-cert.pem
ssl-key=/etc/mysql/newcerts/server-key.pem
server-id               = 1
log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
binlog_do_db            = exampledb

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

Riavvia MySQL:

/etc/init.d/mysqld restart

Creare snapshot coerente del database exampledb e annotare lo stato del master

Sul master:

mysql -u root -p

Nel prompt MySQL esegui:

USE exampledb;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Annota i valori File e Position mostrati da SHOW MASTER STATUS; servono per far partire lo slave dallo stesso punto del binlog.

Non uscire dal prompt MySQL (mantenere il lock). In una seconda shell sul master crea il dump e trasferiscilo allo slave:

server1 (seconda shell):

cd /tmp
mysqldump -u root -pyourrootsqlpassword --opt exampledb > snapshot.sql
scp snapshot.sql [email protected]:/tmp

Dopo il trasferimento puoi sbloccare le tabelle e uscire dal prompt della prima shell:

server1 (prima shell):

UNLOCK TABLES;
quit;

4 Configurare lo slave (server2)

Depositare i certificati: assicurati che su server2 siano presenti i file trasferiti in /etc/mysql/newcerts: ca-cert.pem, client-cert.pem, client-key.pem.
Aggiornare /etc/my.cnf sullo slave per abilitare SSL e identificare lo slave

Esempio di configurazione minimale nella sezione [mysqld]:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
old_passwords=1
ssl
ssl-ca=/etc/mysql/newcerts/ca-cert.pem
ssl-cert=/etc/mysql/newcerts/client-cert.pem
ssl-key=/etc/mysql/newcerts/client-key.pem
server-id=2

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

Riavvia MySQL:

/ect/init.d/mysqld restart

(Nota: il percorso esatto del comando di riavvio è /etc/init.d/mysqld restart; inseriscilo correttamente.)

Importare lo snapshot su server2

cd /tmp
mysql -u root -p exampledb < /tmp/snapshot.sql

Configurare e avviare la replica sullo slave

Accedi a MySQL su server2:

mysql -u root -p

Esegui i comandi di CHANGE MASTER TO usando i valori File e Position presi da SHOW MASTER STATUS sul master. Esempio (sostituisci file e posizione reali):

CHANGE MASTER TO
  MASTER_HOST='server1.example.com',
  MASTER_USER='slave_user',
  MASTER_PASSWORD='slave_password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=3096416,
  MASTER_PORT=3306,
  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';

START SLAVE;

SHOW SLAVE STATUS\G

Controlla i campi ‘Slave_IO_Running’ e ‘Slave_SQL_Running’. Entrambi devono essere Yes per indicare che la replica è attiva.

Se hai usato REQUIRE SSL quando hai creato lo user di replica, MASTER_SSL=1 e i riferimenti ai certificati sono obbligatori.

5 Verifiche e troubleshooting comuni

Controlli rapidi:

Sul master: STATUS del binlog con SHOW MASTER STATUS.
Sullo slave: SHOW SLAVE STATUS\G e verifica Slave_IO_Running/Slave_SQL_Running.
Controlla i log dei mysqld su /var/log/mysqld.log e /var/log/mysql per messaggi di errore.

Problemi comuni e soluzioni:

Errore di connessione SSL: verifica permessi dei file .pem e percorsi su disco; MySQL deve poter leggere le chiavi e i certificati.
Permessi errati: imposta owner root:root e permessi 600 su file privati (client-key.pem, server-key.pem). Non esporre la private key.
Errore ‘Could not find CA certificate’: verifica MASTER_SSL_CA path e che il file sia leggibile dall’utente mysql.
Differenze di versione MySQL: alcuni parametri di CHANGE MASTER TO o opzioni SSL possono cambiare tra versioni; consulta la documentazione della versione esatta.

Comandi utili per debug:

show variables like '%ssl%';
SHOW MASTER STATUS;
SHOW SLAVE STATUS\G
tail -n 200 /var/log/mysqld.log

6 Sicurezza e buone pratiche

Conserva ca-key.pem e server-key.pem in un luogo sicuro. Non trasferire mai la ca-key.pem allo slave.
Usa password robuste per l’account di replica e limita l’accesso host-based (evita ‘%’ se possibile).
Imposta permessi stretti sui file delle chiavi (600) e proprietà root:mysql o root:root come richiesto.
Valuta l’uso di un sistema di gestione certificati (PKI) se hai molti server.
Mantieni aggiornati MySQL e sistema operativo per patch di sicurezza.
Monitoring: monitora lag di replica e alert per Slave_IO_Running/Slave_SQL_Running.

7 Alternative e confronti

Se SSL integrato non è fattibile o vuoi un’ulteriore protezione di rete, considera:

VPN tra i data center (IPsec/OpenVPN) — cifratura a livello di rete.
SSH tunnel per la porta MySQL — semplice ma meno scalabile.
Replica tramite canali privati in cloud (VPC peering, interconnessioni private).

Pro e contro SSL integrato:

Pro: cifratura end-to-end a livello applicazione, integrato in MySQL.
Contro: gestione certificati, rotazione e permessi; su sistemi legacy potrebbe richiedere ricompilazione o opzioni addizionali.

8 Esempi di checklist per ruoli

Sysadmin (pre-deploy)

Backup completo del master.
Installare MySQL su master e slave.
Creare directory /etc/mysql/newcerts su entrambi.
Generare certificati su master.
Trasferire solo i file necessari allo slave.
Configurare my.cnf con server-id e binlog.
Aprire porte firewall se necessario (3306) solo tra host autorizzati.

DBA (deploy e validazione)

Creare utente di replica con REQUIRE SSL.
Generare dump coerente e importarli nello slave.
Avviare replica e verificare SHOW SLAVE STATUS.
Testare failover plan (procedura di promozione dello slave se previsto).

9 Cheatsheed comandi rapidi

Installazione e avvio:

yum install mysql mysql-devel mysql-server
chkconfig --levels 235 mysqld on
/etc/init.d/mysqld start

Controllo SSL:

mysql -u root -p -e "show variables like '%ssl%';"

Generazione certificati (esempio):

cd /etc/mysql/newcerts
openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem > ca-cert.pem

Dump e trasferimento:

mysqldump -u root -pyourrootsqlpassword --opt exampledb > snapshot.sql
scp snapshot.sql [email protected]:/tmp

Configurazione replica (esempio CHANGE MASTER TO):

CHANGE MASTER TO
  MASTER_HOST='server1.example.com',
  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';

START SLAVE;

10 Rotazione e manutenzione dei certificati

Pianifica la rotazione dei certificati prima della scadenza (nell’esempio sono usati -days 1000). Scegli una scadenza coerente con la tua policy di sicurezza.
Aggiorna prima ca-cert.pem su master e poi distribuisci i certificati client aggiornati agli slave.
Testa la validità dei nuovi certificati in ambiente di staging prima di distribuirli in produzione.

11 Gestione SELinux e firewall su CentOS

SELinux può bloccare l’accesso ai file dei certificati. Se SELinux è abilitato, assegna il contesto corretto o usa semanage/restorecon per i file in /etc/mysql/newcerts.
Assicurati che il firewall iptables o firewalld permetta il traffico sulla porta 3306 solo tra master e slave (regola basata su IP).

12 Casi in cui la replica non è una soluzione adatta

Non sostituisce il backup: se cancelli accidentalmente dati sul master, la cancellazione si propaga.
Non garantisce consistenza trasversale fra più database non replicati insieme.
Non è una soluzione a prova di corruzione logica se l’errore applicativo si propaga dal master.

13 Esempi di test di accettazione (acceptance)

Dopo aver avviato lo slave, creare una tabella di test su master e verificare che compaia sullo slave.
Inserire 100 righe di prova e verificare che il conteggio delle righe sullo slave corrisponda.
Arrestare temporaneamente lo slave e poi riavviarlo: verificare che la replica riprenda e non perda eventi.

14 Riepilogo

Abbiamo creato e distribuito certificati, abilitato SSL su master e slave, creato l’utente di replica che richiede SSL, generato uno snapshot coerente del database e avviato la replica SSL.
Verifica sempre SHOW SLAVE STATUS per controllare lo stato della replica e monitora i log.

Notes