Configurare la replicazione di MySQL¶

Occorrono almeno due installazioni indipendenti di MySQL, una macchina deve fare da master, le altre da slave. Inoltre non è possibile per fare da slave per master diversi, questo significa che se si devono replicare database che stanno su macchine diverse, queste dovranno essere replicata su istanze diverse.

Prenderemo in considerazione solo il caso elementare di due macchine. Le due istanze devono essere configurate per essere raggiungibili via rete. La replicazione si basa sul configurare il master per creare un log binario con le operazioni che vengono eseguite in scrittura. Lo slave leggendo i file su cui vengono registrate queste operazione le ripete su se stesso per “allinearsi”.

Configurazione del Master¶

Il primo passo è la configurarazione del master, per questo occorre modificare il file /etc/mysql/my.cnf per abilitare la connessione via rete e la scrittura del file di log binario. Le modifiche da effettuare prevedono linseremento delle seguenti configurazioni al posto di quelle installate normalmente dal pacchetto Debian di MySQL:

[...]
bind-address    = 0.0.0.0
# oppure
# bind-address = IP.O.NOME.MASTER 
[...]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
[...]

(qualora si voglia usare un IP specifico per bind-address invece di quello generico, è in genere preferibile utilizzare un nome a dominio opportunamente risolto invece del valore numerico, il valore di server-id è arbitrario, ma deve essere diverso per tutte le istanze).

Qualora si siano fatti tentativi precedenti, per ripartire da zero, è necessario cancellare eventuali vecchi file di log binario, in modo tale che il server crei un log pulito a prova di errore, con:

rm /var/log/mysql/mysql-bin.*

si provveda poi a riavviare il server MySQL, in modo che prenda le nuove configurazioni:

service mysql restart

A questo punto si dovrà impostare MySQL per abilitare un utente con accesso da remoto che possa leggere i log ed eseguire la replicazione, l'utente deve essere definito sul master, e sarà usato dagli slave per connettersi, questo si fa collegandosi con mysql ed eseguendo il codice SQL:

GRANT REPLICATION SLAVE ON *.* TO 'utentereplicazione'@'IP.O.NOME.SLAVE' IDENTIFIED BY 'passwordlungaecomplicata';
FLUSH PRIVILEGES;

Una volta attive le nuove configurazioni occorre trasferire i dati dal master allo slave per l'importazione iniziale. Questi devono essere in uno stato coerente per cui non è possibile eseguire operazioni sul database durante la sincronizzazione iniziale. Pur essendo possibile far eseguire tutta la transazione via rete, per mantenerla in stato coerente questa necessita di mantenere un lock sul database per tutto il tempo impiegato a replicare i dati, che con database popolati significativamente può essere anche molto lungo.

Per questo è in genere preferibile fare un dump ad un certo momento e per ripartire dallo stato in cui lo si era fatto. In questo caso il lock è necessario solo per il tempo, in genere molto minore, in cui si crea il dump. Una volta effettuato il dump si potrà rimuovere il blocco e indicare allo slave, una volta importato il dump, di ripartire dal punto in cui questo era stato fatto usando le informazioni registrate sul file di log mantenuto dal master.

Per far questo si deve collegarsi sulla CLI di MySQL, selezionare il database da replicare e bloccare le tabelle in scrittura, così da avere uno stato coerente dei dati, con le istruzioni:

USE nome_database
FLUSH TABLES WITH READ LOCK;

Si dovrà poi controllare lo stato del master (che ci servirà per stabilire il punto da cui far ripartire la replicazione sullo slave) con il comando SHOW MASTER STATUS, questo darà un risultato del tipo:

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000005 | 13955148 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

A questo punto, senza chiudere la shell di MySQL (per evitare di perdere il lock sulle tabelle), si effettui il dump del database su un file .sql da trasferire sul server slave con:

mysqldump -u root nome_database_da_replicare > dati_database.sql

una volta finita l'esportazione potremo tornare sulla shell di MySQL e sbloccare il lock in lettura con:

UNLOCK TABLES;

A questo punto le operazioni sul master sono terminate, la scrittura riprenderà, ma essendo registrata nel log lo slave sarà in grado di ripartire senza problemi utilizzando il punto di partenza indicato dai risultati di SHOW MASTER STATUS.

Configurazione dello Slave¶

Anche in questo caso occorre riconfigurare il server MySQL, in particolare occorrerà assegnargli un diverso server-id ed inoltre occorrerà spostare tmpdir su una directory il cui contenuto sia garantito in caso di riavvio, in quanto la cancellazione dei file temporanei potrebbe compromettere l'aggiornamento della replicazione. Rispetto al file di configurazione standard occorrerà apportare le seguenti modifiche:

[...]
tmpdir          = /var/tmp
[...]
bind-address    = 0.0.0.0
# oppure
# bind-address = IP.O.NOME.SLAVE 
[...]
server-id = 2
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
replicate_wild_do_table = database_da_replicare.%
replicate_wild_do_table = altrodb_da_replicare.%
[...]

(di nuovo qualora si voglia usare un IP specifico per bind-address è preferibile utilizzare un nome a dominio opportunamente risolto invece del valore numerico, ed il valore di server-id è arbitrario, ma deve essere diverso da quello del master e di altri eventuali slave).

A questo punto si dovrà rendere effettive le nuovo configurazioni riavviando il server MySQL anche sulla macchina slave:

service mysql restart

Per l'importazione iniziale dei dati occorrerà anzitutto creare sullo slave un database con lo stesso nome di quello che vogliamo replicare:

mysqladmin -u root -p create nome_database_da_replicare

a questo punto si potranno caricare i dati dal file con il dump ottenuto sul master con:

mysql nome_database_da_replicare < dati_database.sql

Si verifichi inoltre che l'utente di replicazione impostato sul master sia effettivamente utilizzabile, per questo basterà effettuare una connessione verso il master con:

mysql -h IP.O.NOME.MASTER -u utentereplicazione -p

(usando la password impostata in precedenza).

L'ultimo passo è impostare il server come slave, questo richiede che si usino le credenziali dell'utente creato in precedenza sul master, e che si indichi anche, utilizzando i dati ottenuti dal precedente comando SHOW MASTER STATUS, il riferimento da cui partire nei log per proseguire con la replicazione (questo è essenziale perché lo slave possa sincronizzarsi correttamente). Facendo riferimento a quanto ottenuto nel paragrafo precedente si dovrà pertanto eseguire sulla CLI di MySQL la seguente istruzione:

CHANGE MASTER TO master_host='IP.O.NOME.MASTER', master_user='utentereplicazione', 
master_port=3306, master_password='passwordlungaecomplicata', master_log_file='mysql-bin.000005', 
master_log_pos=13955148;
START SLAVE;

dove appunto mysql-bin.000005 e 13955148 sono rispettivamente il file di log e la posizione riportati da SHOW MASTER STATUS.

Fatto questo si potrà controllare lo status dello slave da MySQL con il comando, e verificare che questo venga aggiornato in corrispondenza a quanto ottenuto con SHOW MASTER STATUS:

SHOW SLAVE STATUS \G;

e rieseguendolo più volte si noterà che in particolare la riga:

...
        Seconds_Behind_Master: 53394
...

avrà un valore in progressiva riduzione via via che la replicazione prosegue fino ad attestarsi ad un valore nullo.

Trasformare lo slave in master¶

Volendo cambiare il nostro server slave nel nuovo master il primo passo da fare è assicurarsi che questo sia il più aggiornato possibile. Se il master è irraggiungibile, questo può essere fatto, nel caso di più slave, selezionando eventualmente quello più aggiornato (se ne esiste uno) verificando il progresso con SHOW SLAVE STATUS \G sulla riga "Read_Master_Log_Pos"; se il master è attivo, occorre anzitutto assicurarsi che vengano scaricati i log pendenti eseguendo su di esso:

FLUSH LOGS;

inoltre occorre eseguire sugli slave:

STOP SLAVE IO_THREAD;

e verificare che nell'output di SHOW PROCESSLIST sia riportato ''Has read all relay log''.

Una volta che si sia fermato il master, o se ne sia comunque bloccata la modifica dei dati, si deve andare a cambiare il file /etc/mysql/my.cnf dello slave controllando che siano abilitate le opzioni di log-bin e disabilitato tutto quello che riguarda i log del tipo slave-updates. Si deve anche verificare che il bind-address sia effettivamente impostato su 0.0.0.0 permettendo così il raggiungimento della macchina dalla rete, la configurazione sarà pertanto qualcosa del tipo:

[...]
bind-address    = 0.0.0.0
[...]
server-id = 2
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
[...]

in particolare è il caso di eliminare le eventuali direttive replicate_wild_do_table inserite per limitare i database da cui si effettua la replicazione, mentre non serve cambiare il valore di server-id.

A questo punto, entrando in MySQL, si può fermate il server slave e reimpostarlo come nuovo master:

STOP SLAVE;
RESET MASTER;

occorrerà infine abilitare un utente per la replicazione in maniera analoga a quanto fatto nella creazione del master con:

GRANT REPLICATION SLAVE ON *.* TO 'utentereplicazione'@'IP.O.NOME.SLAVE' IDENTIFIED BY 'passwordlungaecomplicata';
FLUSH PRIVILEGES;

Volendo reimpostare l'ormai defunto master nel nuovo slave che replichi il nuovo master, dovremo inserire nel suo my.cnf le replicate_wild_do_table tolte dallo slave, e seguire la procedura seguente per riallineare uno slave, facendo riferimento a quello che ora è diventato il nuovo master.

Riallineare uno slave¶

Qualora la replicazione si sia interrotta (cosa che può accadere se ad esempio l'istanza replicata resta ferma per un numero di giorni superiore a quello indicato dalla direttiva expire_logs_days del my.cnf del master) si può effettuare un riallineamento manuale della stessa. La procedura è simile a quella della impostazione iniziale, occorre infatti ripetere un sottoinsieme dei passi.

La prima fase è quella di ottenere, con la stessa procedura descritta in precedenza, un dump dell'istanza principale conoscendo lo stato del master in quel momento: occorrerà pertanto selezionare il database, bloccarne le tabelle con FLUSH TABLES WITH READ LOCK; ed ottenere lo stato corrente del master con SHOW MASTER STATUS; (segnandosi i numeri del file di log e della posizione corrente) mentre al contempo, senza uscire dalla shell di mysql per mantenere il lock sulle tabelle, si eseguirà il dump del database.

Una volta eseguito il dump si potrà rilasciare il lock (o esplicitamente con UNLOCK TABLES o abbandonando la shell). Dopo di che, copiato il dump sull'istanza slave lo si potrà reimportare eliminando i dati correnti. In questo caso si dovrà preventivamente bloccare la replicazione con il comando:

STOP SLAVE;

e poi eseguire il caricamento dei dati allo stato noto con:

mysql nome_database_da_replicare < dump_del_database.sql

e a questo punto basterà ricollegarsi all'istanza secondaria e ripetere una istruzione CHANGE MASTER identica a quella già illustrata usando il file di log e la posizione segnata in precedenza, infine si farà ripartire la replicazione con:

START SLAVE;

e si potrà controllare che tutto sia a posta con SHOW SLAVE STATUS \G verificando che la replicazione stia aggiornando i dati della posizione del master e che la voce ''Seconds_Behind_Master'' si riduca progressivamente fino ad annullarsi.