Nessun risultato trovato
di Alessandro Davanzo
Esistono casi pratici in cui si rende necessario mettere in replica dei server MySQL: in questo tutorial vedremo quali sono e spiegheremo come eseguire le relative operazioni.
Creare la replica di un database MySQL fornisce la sicurezza di avere un backup ed un server MySQL pronto all'uso e perfettamente aggiornato; va comunque ricordato che la replica non sostituisce il backup, che è un’operazione che bisogna continuare a fare. Infatti la replica viene fatta in tempo reale sue due database e se ad esempio facciamo una query che cancella un dato o tramite il sito abbiamo cancellato dei dati o è successo qualcosa per cui sono stati persi dei dati, questi altri vengono cancellati (rimossi) anche dal database di replica.
Quindi il database di replica è semplicemente un duplicato costantemente aggiornato, non un backup e le operazioni eseguite sul server principale MySQl vengono replicate sull’altro.
Quando si esegue la replica di un server abbiamo un server primario e un server slave:
il primario è quello che normalmente si utilizza, mentre la replica entra in gioco (ossia viene attivata) quando occorre.
Fare la replica di un DB MySQL permette quindi di avere, oltre ad un backup, anche un server MySQL di scorta pronto all’uso e perfettamente aggiornato.
Ha senso attivare la replica quando il server primario ha avuto un guasto, ma non quando si è verificata una perdita di dati o per recuperare dei dati vecchi: per questo bisogna usare i backup fatti in precedenza, giacché la replica è sempre in tempo reale.
Vediamo in quali casi bisogna utilizzare la replica del server MySQL: di norma quando c'è stato un “fault” del nostro server master, quindi possiamo organizzarci sul server di replica e usare quello per dare continuità al nostro servizio. In generale le situazioni sono le seguenti.
Per quanto riguarda la situazione disaster recovery, se il database primario si guasta si può dirottare sullo Slave e dare continuità al servizio, magari impostando il server slave in sola lettura, così nel momento in cui riattiviamo il nostro master possiamo riprendere il nostro lavoro da dove si è si era fermato, magari facendo dei restore dal backup in caso dobbiamo ripristinare la macchina, senza dover poi necessariamente interrompere la replica per fare un backup dello Slave, ripristinarlo sul Master e ripartire.
Per quanto riguarda i backup, l’utilizzo della replica si fa apprezzare in termini si scarico del server sottoposto a backup, quindi se possiamo spostare il backup dalla macchina Master sulla Slave, considerando che i due sono aggiornati in tempo reale, se facciamo il backup sulla macchina Slave abbiamo sempre il dato aggiornato e non diamo disservizi perché il server Master continua a rispondere alle query senza rallentamenti.
Quanto all’utilizzo nei bilanciamenti di carico, possiamo avere più di un server Slave e quindi possiamo usare il Master come database in scrittura e gli Slave per il bilanciamento di carico in lettura; considerando che sono sempre tutti allineati in tempo reale (salvo problemi di replica che comunque possiamo tenere sotto controllo) possiamo costruire una nostra applicazione in modo che le query di scrittura le faccia sul master e tutte le query di lettura vadano in esecuzione sugli Slave, anche perché probabilmente saranno più quelle di lettura che quelle di scrittura. Il bilanciatore di carico può essere, ad esempio, HAProxy.
Analizziamo la configurazione Master Slave, che è preferibile perché più affidabile, in quanto la Master Master crea dei problemi, dato che andando a scrivere su due database Master che poi si devono sincronizzare, può esserci qualche difficoltà. Quindi se avete un’esigenza di questo tipo, vale a dire di avere un database MySQL Master messo in replica a un altro Master, suggeriamo di evitare e rivolgersi ad alternative come ad esempio creare un cluster con Galera, che peraltro è gratuito.
La configurazione Master-Slave è abbastanza semplice da fare. Possiamo farla a mano oppure farci aiutare da phpMyAdmin, il quale ci fornirà le informazioni di base per attivare la nostra replica, informazioni che dovremo inserire poi noi a mano nel file di configurazione dei nostri MySQL. Naturalmente questa soluzione implica che le impostazioni andranno poi “tarate” per adattarle al caso specifico.
In questo tutorial optiamo per la configurazione manuale, premettendo che opereremo in ambiente Linux.
Nell’immagine seguente possiamo vedere uno schema di funzionamento, dove abbiamo il server Master che va a scrivere in un binary log tutte le modifiche che vengono fatte e lo Slave che va a leggere i cambiamenti fatti nel binary log e li va a scrivere in un proprio file di log e ad inserire nel database. Questo è il processo che fa la configurazione di tipo Master-Slave.
Vediamo dunque la configurazione da eseguire; per prima cosa bisogna editare il file mysqld.cnf con il comando:
nano /etc/mysql/mysql.conf.d/mysqld.cnf
Fatto questo, all’interno del file inseriamo le istruzioni necessarie, che sono le seguenti:
server-id = 437811log_bin = mysql-bin.loglog_error = mysql-bin.errexpire_logs_days = 1binlog-ignore-db=information_schemabinlog-ignore-db=mysql
Quindi andiamo a dare al nostro server Master un identificativo (server-id) e poi un altro id al server Slave, quindi dobbiamo configurare log_bin e configurare l’eventuale log_error.
Poi definiamo ogni quando scadono questi log, che è importante quando si ha a che fare con dei database grandi; infatti se continuano ad essere fatte modifiche, il numero dei log cresce e se ciascun log è di grandi dimensioni, in breve tempo ci si riempiono le unità disco, quindi poter impostare dopo quanto tempo rimuovere i vecchi log può essere determinante.
La durata dei log si imposta con l’istruzione expire_logs_days = 1 che in questo caso significa che ciascun log viene mantenuto per un giorno, quindi se il nostro server di replica va giù per più di un giorno, purtroppo bisogna ripartire con la replica da zero, quindi impostate un tempo che sia rapportato alle reali necessità e alle dimensioni dei database con cui avete a che fare.
Poi impostate eventuali database da ignorare, vale a dire quelli di cui non vi interessa fare la replica: nel caso dell’esempio l’impostazione corrisponde alle linee binlog-ignore-db; questo è importante in quanto per default con attivata la replica questa riguarda tutti i database e quindi nel momento in cui viene creato un nuovo database, viene fatto altrettanto nel server di replica. Se invece avete un database esistente dovete fare un dump di quel database e un restore di quel database sul server di replica e poi attivare la replica da quel punto.
Nell’immagine seguente è proposta una tipica schermata dell’editor che riporta il file in questione, dove potete vedere impostazioni come il server id (qui impostato a 1) la massima dimensione di binding (impostata a 100 Mbyte) ed altro ancora.
Una cosa importante riguardante la creazione del server master è impostare il bind address in maniera diversa dal default: per esempio sull’IP del server di replica o, come si vede nell’immagine seguente, a 0.0.0.0 che permette di accettare connessioni da tutti.
Infatti il default è 127.0.0.1 e tale impostazione accetterebbe solo connessioni da sé stesso e ovviamente non sarebbe possibile la replica sul server Slave.
Una volta completata la creazione o modifica del file salviamolo e riavviamo il servizio con il comando:
Service mysql restart
Con una configurazione del tipo descritto sinora, nel momento in cui andate a fare modifiche a un database saranno riportate in quello di replica.
Dopo aver effettuato la configurazione Master-Slave del Master dobbiamo creare un utente per la replica, cioè per garantire la replica; per prima cosa configuriamo il server MySQL che sarà il master nella replica.
Colleghiamoci al MySQL e diamo l’accesso in replica al server di slave con questi comandi:
GRANT REPLICATION SLAVE ON *.* TO 'replication'@'%' IDENTIFIED BY 'webinar’;FLUSH PRIVILEGES;
Come vedete c’è la query Grant Replication Slave, impostiamo un utente e una password, quindi resettiamo e aggiorniamo i privilegi senza riavviare e impartiamo il comando:
Show master status;
il quale fa apparire a video la tabella seguente, che indica qual è il file di log.
In esso appare il nome (mysql-bin.0000001) e la sua posizione, che è molto importante; vediamo anche i database ignorati. Salviamo questi dati perché ci serviranno per avviare la replica, ovvero per attivare il nostro server Slave.
Notate che se stiamo operando in un ambiente che sta lavorando, il dato continua a cambiare, però è sufficiente e importante salvarlo all’atto del Dump.
Configurazione Master-Slave: il Server SLAVE
Configuriamo ora il server Slave, impartendo, allo scopo, il seguente comando per editare il file mysqld.cnf:
nano /etc/mysql/mysql.conf.d/mysqld.cnf
La configurazione del server Slave è più semplice di quella del Master, sebbene anche qui dobbiamo definire un id per il server, un log_bin e una scadenza per i log.
server-id = 1523612659log_bin = mysql-bin.logexpire_logs_days = 5
Possiamo anche aggiungere un disco sui nostri database server, su cui andare a inserire i log di replica, per non “caricare” il disco principale durante la replica. Fatto ciò salviamo il file e andiamo a riavviare il server con il comando:
service mysql restart
Ora dobbiamo indicare allo Slave chi è il master e garantirne l’accesso, indicando il file di log che abbiamo recuperato prima con il comando SHOW MASTER STATUS, oltre alla relativa posizione.
Una volta fatta la configurazione del caso dobbiamo attivare la replica tramite una query e qui dobbiamo passare nome utente e la password dell'account di replica. Nella query occorre specificare l’indirizzo IP, che nello specifico deve essere quello del server Master (nell’esempio riportato qui sotto è 10.134.252.210.
Mysql –u root –pCHANGE MASTER TO MASTER_HOST='10.134.252.210',MASTER_USER='replication', MASTER_PASSWORD='webinar', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS= 588;START SLAVE;SHOW SLAVE STATUS\G
Indichiamo anche il MASTER LOG file e la posizione da cui deve partire; questo è importante perché tali dati servono ad esempio se si interrompe la replica per qualsiasi motivo, allorché è possibile risalire al punto da dove far ripartire la replica stessa.
START SLAVE fa partire il servizio e questo si va ad aggiornare; sullo schermo dello Slave apparirà qualcosa di simile a quanto proposto nell’immagine seguente.
Con il comando SHOW SLAVE STATUS\G possiamo vedere qual è lo stato attuale della replica ed anche andare a vedere qual è la posizione che ha replicato, oltre che sapere se la stessa effettivamente viene incrementata; l’esempio proposto dall’immagine seguente ci mostra l’id del Master Server e la scritta Slave has read all relay log; waiting for more updates, la quale significa che il server Slave ha eseguito la replica a seguito della query e che rimane in attesa di aggiornamenti.
Notate che se stiamo iniziando a fare la replica di un database già esistente sul master, dobbiamo fare un dump di quel database e poi ripristinarlo sul server Slave; quindi tutti i nuovi database verranno creati in automatico anche sullo Slave.
Per concludere diamo uno sguardo a phpMyAdmin, utile strumento che ci consente sia di vedere lo stato della replica, sia di creare nuovi utenti per la replica stessa; una volta fatta la login, ci si trova davanti l’interfaccia utente, ovvero la pagina di amministrazione. In essa, dalla tab Database possiamo consultare i database esistenti e attivi, oltre che lo stato dell’eventuale replica.
Per accedere alle impostazioni e alle funzionalità inerenti alla replica bisogna cliccare sulla tab Replicazione e si accede alla pagina proposta dall’immagine seguente.
Nella sezione Replicazione master è riportato il riepilogo del master (vi si accede con il link Mostra lo stato del master) e quello degli Slave al momento connessi (Mostra gli slave connessi); è anche possibile avviare la procedura guidata per l’aggiunta di utenti per la replica su server Slave, semplicemente cliccando su Aggiungi un utente per replicazione slave e seguendo i passaggi indicati. Resta inteso che in questo caso la creazione avviene con una configurazione standard e potrà essere necessario editare e modificare il file di configurazione come spiegato in precedenza.
Quella proposta è la schermata di phpMyAdmin loggandosi sul server Master; infatti la sezione Replicazione slave è vuota e riporta l’indicazione che il server corrispondente non è configurato come slave per la replicazione (è comunque possibile farlo cliccando sull’apposito link).
L’immagine seguente propone la schermata che riporta i server Slave connessi.
Se ci si va a loggare sul server Slave, nella finestra accessibile dalla tab Replicazione avremo attiva la almeno la sezione Replicazione slave e quella Replicazione Master sarà disattivata, almeno per default (sarà comunque possibile modificarla).
Sempre dall’interfaccia di phpMyAdmin possiamo verificare che la replica abbia effetto: loggandoci sul Master e andando a creare, dalla tab Database (dove vediamo lo stato dei database esistenti) un nuovo database (immagine seguente) lo ritroveremo nell’interfaccia utente di phpMyAdmin del server Slave.
