Replica Master/Master in MySQL

Fino ad ora abbiamo analizzato come implementare una replica in MySQl tra un server master e uno o più server slave. Sebbene questo sia il tipo di replica più utilizzato in questo ambito, MySQL ci permette di impostare anche una replica in cui due server diversi sono posti allo stesso livello nell'accettare dati in scrittura.

In questo caso il risultato principale che si cerca di raggiungere è quello di ottenere una ridondanza dei dati permettendo all'infrastruttura di supportare la perdita di una delle macchine, senza per questo perdere i dati memorizzati nel database o interrompere i servizi che necessitano dell'accesso ai dati. Questa configurazione è paragonabile ad un RAID-1: esistono due copie dello stesso dato su due macchine diverse, e se una macchina va in down l'altra compensa.

In analogia con i livelli RAID, nell'ambito dei database, esiste anche un tipo di replica master in cui ogni macchina accetta dati in scrittura ma questi non vengono copiati interamente su tutti i server presenti nel cluster. In quest'ambito un cluster è un gruppo di server collegati tra di loro che cooperano avendo conoscenza l'uno dell'altro. In questo caso non stiamo cercando di ottenere la ridondanza dei dati, quanto di aumentare la quantità di dati memorizzabili senza perdita di prestazioni: questa situazione è paragonabile ad un RAID-0. MySQL non è progettato per supportare questo tipo di replica, che invece è presente in numerosi server NoSQL.

Configurazione dei server

Per impostare questo tipo di replica in un sistema a due server dobbiamo procedere per step. Per prima cosa impostiamo una replica master/slave in modo da avere un server master sul quale avremo creato un utente autorizzato alle operazioni necessarie alla replicazione dei dati. A questo punto copiamo le tabelle da sincronizzare sul server slave come spiegato nella lezione precedente, e configuriamo il server slave per leggere i dati dal master.

Fatto questo ci troveremo nella situazione di avere una replica master/slave funzionante per cui i dati presenti sul server A (master) verranno trasferiti automaticamente sul server B (slave). Siamo a metà della strada, dato che noi stiamo cercando anche di fare in modo che una modifica dei dati sul server B venga riportata sul server A, e la situazione attuale non lo permette.

Di fatto quello che stiamo cercando di ottenere è un rapporto master/slave incrociato, ed è esattamente questo che dovremo impostare. Quindi, per prima cosa, dobbiamo impostare il server B come un possibile master:

• impostiamo l'IP di ascolto su 0.0.0.0 tramite bind-address, in modo che il server accetti connessioni dall'esterno;
• assicuriamoci che la direttiva server-id sia diversa rispetto a quanto impostato sul server A;
• creiamo l'utente con i poteri di replica sul server B.

Come illustrato nelle lezioni precedenti dobbiamo collegarci al server B con l'utente root tramite una shell, ed eseguire la seguente query:

GRANT REPLICATION SLAVE ON *.* TO 'user_replica'@'%' IDENTIFIED BY 'password';

Non è necessario che questo utente abbia lo stesso nome o la stessa password di quello creato sul server A, ma ciò non è neanche vietato.

A questo punto dobbiamo ottenere la posizione di replica del server B. Quindi, sempre tramite la shell sul server B, digitiamo la seguente query e prendiamo nota dei parametri Position e File riportati.

SHOW MASTER STATUS;

Per completare la replica, dobbiamo ora spostarci sul server A (il nostro ex master) e fare in modo che si aggiorni ad ogni modifica effettuata su B. Quindi da una shell mysql con utente root eseguiamo queste query avendo cura di inserire i dati che abbiamo ottenuto dal server B (l'indirizzo IP reale, il nome utente per la replica, la password dell'utente, il nome del file di log e la posizione riportati dal passaggio precedente):

STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='xxx.xxx.xxx.xxx', MASTER_USER='user_replica', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=151;
START SLAVE;

Testing

Fatto questo, la nostra replica master/master è configurata e non ci resta altro da fare che provarla. Per effettuare un test idoneo, è necessario provare la replica in entrambe le direzioni. A tale scopo possiamo creare una tabella sul server A, vedere se è stata creata sul server B, cancellarla dal server B e vedere se è stata cancellata dal server B.

Se tutte le operazioni sono andate a buon fine ci troviamo nella situazione di avere due macchine con i dati in copia 1 a 1, e possiamo quindi migliorare le performance in scrittura su quella che precedentemente era una macchina slave.

La replica multi-master

Come detto all'inizio della lezione, in genere la configurazione fin qui descritta utilizza due server. È tuttavia altresì possibile aumentare il numero di server coinvolti. Per farlo, è necessario creare un anello di macchine per cui ognuna diventa master per la successiva ma slave per la precedente:

• Server A è master di Server B e slave di Server C
• Server B è master di Server C e slave di Server A
• Server C è master di Server A e slave di Server B

In questo modo una modifica effettuata sul Server A passa sul Server B e da qui al Server C. Chiaramente ogni passaggio richiede del tempo ed essendo configurazioni in serie (e non in parallelo), il tempo totale per la replica aumenta all'aumentare dei nodi e della distanza tra di loro. Per questa ragione in MySQL la replica Master/Master è in genere limitata a due macchine, per evitare problemi di desincronizzazione nonchè perdite di performance.