www.MegaLab.it

Il backend è pronto: ora tocca ai programmatori

Ormai è quasi tutto pronto dal punto di vista del backend. Prima di aprire le porte dello slave al pubblico però, è generalmente indispensabile eseguire qualche adattamento al codice dell'applicazione.

In particolare, ricordate che tutte le scritture (quindi inserimenti, aggiornamenti ma anche cancellazioni e modifiche alla struttura del database e della tabelle) dovranno essere rivolte al server master.

Non bisognerà mai operare direttamente sugli slave: come già ricordato, tali server dovranno funzionare unicamente in lettura.

Il codice dovrà essere modificato di conseguenza, utilizzando connessioni differenti per le letture e le scritture.

Attenzione al ritardo!

Nell'adattare l'applicazione al modello replicato, i programmatori dovranno tenere ben presente che non v'è nessuna garanzia in merito ai tempi di replicazione. A meno di carico elevato, il tutto si sbriga generalmente in meno di un secondo... ma il modello asincrono comporta che il ritardo con il quale gli slave ricevono gli update dai client non sia prevedibile a priori.

Sarà quindi necessario fare attenzione a questo aspetto in fase di progettazione e predisporre gli opportuni controlli.

Garantire che gli slave operino in sola-lettura

Suggerisco di garantirsi la certezza che gli slave non subiscano operazioni di scrittura revocando tutti i privilegi di accesso ai vari utenti del database, per poi riconcedere solo quelli di lettura. I comandi utili allo scopo sono:

REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'NomeUtente'@'%'; GRANT SELECT ON miodatabase.* TO 'NomeUtente'@'%';

Tali istruzioni vanno ripetute per ogni account presente sul database.

Due parole sulla sincronizzazione bi-direzionale ("multi-master")

Durante le ricerche necessarie ad approntare questo articolo mi sono imbattuto in alcune guide che suggeriscono come implementare un'infrastruttura ibrida nella quale i server si sincronizzano in maniera bi-direzionale.

Questo ha l'indubbio vantaggio di consentire le scritture su entrambi i sistemi, ma espone anche uno svantaggio significativo: non è una modalità prevista ufficialmente da MySQL.

Di più: il manuale sconsiglia apertamente tale scenario: amenochè non sia la logica dell'applicazione stessa a farsi carico di alcune operazioni di allineamento tutt'altro che banali, vi è il rischio concreto che possa verificarsi una corruzione dei dati.

Chi avesse tale necessità farebbe quindi meglio ad abbandonare la versione standard di MySQL e passare per prima cosa a MySQL Cluster. Fatto ciò, il punto di partenza per la replicazione bidirezionale diviene il capitolo 17.6.10 del manuale ufficiale.

Rescindere il legame

Se, per qualsiasi motivo, avete la necessità di rescindere il legame fra slave e server, è sufficiente lanciare questi comandi sullo slave:

STOP SLAVE; RESET SLAVE;

Ricordate che questo trancia del tutto ogni rapporto fra i due calcolatori. Per ripristinarlo, sarà necessario ripetere nuovamente tutta la configurazione dello slave.Allo scopo, potete comunque ri-utilizzare lo stesso file di dump generato in precedenza, se l'avete conservato.

Riferimenti

Questa guida è solo un'introduzione ad un argomento, quello della replicazione dei dati fra più server MySQL, davvero ampio.

Se siete arrivati fino a qui, avrete ottenuto un'infrastruttura funzionante ed in grado di essere realmente utile in ambienti di produzione, ma che può sicuramente essere perfezionata.

Il punto di partenza per approfondire il discorso è la corposa sezione "Chapter 16. Replication" del manuale ufficiale del software.

In particolare, raccomando di dare un'occhiata al capitolo 16.3.7, nel quale è illustrato come abilitare la connessione crittografata SSL fra master e slave: tale opzione non ha troppo senso se le due macchine fanno parte della stessa LAN, ma può invece risultare importante in caso il master propaghi agli slave dati riservati attraverso Internet.

Un altro capitolo di sicuro interesse è il 16.3.6: in esso viene mostrato come, sebbene non proprio in maniera lineare, "promuovere" uno slave a server principale in caso il master originale divenisse inservibile.