A quick recipe to put back in production 2 MYSQL servers
in a Master-Slave configuration.


DB SNAPSHOTS SUL MASTER E COPIA SULLO SLAVE

Per iniziare mi immagino in una situazione in cui il demone mysqld e' fermo ('stopped') sia sul master che sullo slave.

Perche'? E' la situazione tipica dopo un outage.

Per verificare la situazione basta fare (come root): service mysqld status

Se per caso il demone sul master fosse giu' ma sullo slave girasse allora procedo allo spegnimento sullo slave:
[root@bbr-sqlslave root]# mysqladmin -u root -p shutdown

A questo punto bisogna assicurarsi subito che nessuna transizione/operazione su altri servers (come quelli di import: si vada ad editare
in essi il crontab di bbrxfer) possa partire ed andare a scrivere nei DB durante l'operazione di ripartenza del servizio e della replica.

Per prima cosa bisogna fare ripartire il demone sul master:
[root@bbr-sqlmaster root]# service mysqld [re]start

Se si trova gia' il demone "girare" sul master ma non sullo slave si puo' partire quindi da tale situazione
(purche' comunque si blocchi preventivamente qualsiasi operazione in scrittura).
In tale situazione non e' garantito che la replicazione sia coerente.
Per garantirci una replicazione sicuramente corretta dobbiamo fare degli snapshot dei DB sul master e trasferirli sullo slave.

Scopo di questa ricetta passo-passo e' proprio quello di seguire una procedura (ma non certo l'unica possibile: ce ne sono diverse)
che ci permetta di ristabilire con successo una corretta replicazione dei DB dal master allo slave.

Sul master, accertato (o fatto in modo che) mysqld ci "giri sopra", come root entriamo in mysql:
[root@bbr-sqlmaster root]# mysql -u root -p (chiede la password, ovviamente di root ma relativa a mysql)

A questo punto, da dentro mysql, congeliamo le tavole dei DB:
mysql> FLUSH TABLES WITH READ LOCK;
e si prenda nota del numero identificatore del binlog file corrente e il numero di posizione (le coordinate):
mysql> SHOW MASTER STATUS;

Si lasci la shell aperta, senza dare altri comandi, al solo scopo di mantenere il lock attivo!

Da un'altra shell sul server master si pulisce la directory /sql dai precedenti file tarball (cioe' gli snapshots) di cui abbiamo copia anche sullo slave.

Come utente root procedo a creare i nuovi snapshots (un tarball file per ciascun DB presente in /sql/databases):

[root@bbr-sqlmaster databases]# tar -cvf /sql/bbkr14-snapshot.tar ./bbkr14
ed analogamente per gli altri DB (bbkr18, bbrora,...)

Questi snapshots vanno copiati sullo slave in /sql/databases :
[root@bbr-sqlmaster sql]#scp *.tar bbr-sqlslave:/sql/databases

Si verifichi che i tarball appartengono all'utente mysql. Altrimenti procedere:
[root@bbr-sqlslave databases]#chown mysql:mysql *.tar

Nella directory sullo slave dove sono stati copiati, si spacchettino i tarball (non c'e' veramente bisogno di cancellare i DB esistenti perche' vengono sovrascritti:
[root@bbr-sqlslave databases]# tar -xvf bbkr14-snapshot.tar

Vanno poi spostati, sempre sullo slave, in /sql (da intendere come repository) sovrascrivendo i vecchi snapshots:
[root@bbr-sqlslave databases]# mv bbkr14-snapshot.tar /sql/bbkr14-snapshot.tar

Si vada ora sulla prima shell sul master e si sblocchi i DB:
mysql> UNLOCK TABLES;


RICONFIGURAZIONE E RIPARTENZA DELLA REPLICAZIONE

Qui scegliamo anche, per estrema pulizia e sicurezza, di pulire i vecchi binlog file (sul master):
mysql> RESET MASTER;

In questo caso quindi bisogna riprendere nota delle coordinate:
mysql> SHOW MASTER STATUS;

A questo punto si lascia aperta ancora la shell sul master perche' servira' alla fine per controllo;
Tutte le restanti operazioni saranno pero' fatte sullo slave.

Si fa partire il demone sullo slave con:
[root@bbr-sqlslave root]#service mysql start

Adesso, essendo partito il demone, posso entrare in mysql (da root):
[root@bbr-sqlslave root]#mysql -u root -p (chiede la password)
e settare le indicazioni necessarie per la replica (il master-binlog file di partenza e la posizione):

mysql> CHANGE MASTER TO MASTER_LOG_FILE='[master-binlog.xxx]', MASTER_LOG_POS='[#]';
dove nome del file e numero di posizione son quelli di cui si e' preso nota precedentemente.

N.B.: mysql> SLAVE START; e' inutile farlo sullo slave: e' gia' partito col demone (per come e' configurato).


CONTROLLO DEL FUNZIONAMENTO DELLA REPLICAZIONE

Con il comando
mysql> 'SHOW PROCESSLIST;
si vede lo stato dei thread della replicazione, sia sul master che sullo slave!


Questa ricetta e' coerente con la versione di mysql sui server del CNAF.
Alternative altrettanto valide, se non migliori, sono possibili in generale.
Autore: Alexis Pompili (dicembre-2006). Per osservazioni e commenti: pompili@ba.infn.it