Nella progettazione di un cluster è sempre bene tenere in considerazione che potranno presentarsi vari tipi di problemi durante l'utilizzo del sistema, dovuti essenzialmente alla complessità del progetto. Causa di problemi può essere la distanza fisica tra due macchine dello stesso cluster: pensando alle prestazioni, la situazione ideale è ovviamente avere a disposizione nodi fisicamente nella stessa server farm; ma dal punto di vista del disaster recovery è meglio distribuire geograficamente i nodi del cluster.
Nel seguito vedremo alcune criticità legate proprio all'uso dei cluster MySQL, e qualche escamotage per limitarle.
Opzioni delle API wsrep utili per evitare errori
La direttiva wsrep_slave_threads imposta il numero di thread che il server MySQL può usare per le operazioni di replica. Un valore più alto permette di velocizzare i trasferimenti necessari a portare un nodo in stato synced, ma al tempo stesso aumenta il rischio di generare problemi di consistenza, soprattutto se la latenza tra i nodi è alta. Per questo motivo è consigliabile aumentare in maniera non eccessiva questo valore, verificare che non si verifichino problemi e casomai incrementare ulteriormente.
Concretamente, la replica dei dati da un nodo donatore ad uno ricevente tramite il sistema IST avviene mediante un pacchetto di dati o writeset. Maggiore è la dimensione di questo pacchetto di dati e maggiore sarà il tempo di trasferimento totale, con possibili ripercussioni sull'adesione del nodo ricevente al cluster. Per questo motivo, è possibile usare le direttive wsrep_max_ws_rows e wsrep_max_ws_size per impostare rispettivamente il numero massimo di righe e la dimensione massima di dati che possono essere accettati con ogni writeset. Questo valore non viene comunicato al server donatore, per cui serve esclusivamente per decidere se applicare un writeset o scartarlo. Impostare dei valori bassi potrebbe causare l'uscita del nodo ricevente dalla sincronia con il cluster.
Nel momento in cui una macchina deve essere messa in stato di manutenzione, o quando è necessario eseguire un backup, è possibile utilizzare la direttiva wsrep_reject_queries impostandola su on in modo che vengano rifiutate le query dai client, al contrario delle operazioni di replica SST o IST che continuano ad essere applicate.
Ulteriori impostazioni per un controllo fine della funzionalità del cluster possono essere attivate tramite la direttiva wsrep_provider_options. Il valore di questa direttiva è una stringa di testo disposta su una singola linea, che racchiude in realtà ulteriori direttive concatenate secondo il formato seguente (in cui il carattere ; è usato come separatore):
direttiva_1=valore_direttiva_1;direttiva_2=valore_direttiva_2;direttiva_3=valore_direttiva_3Inserimenti univoci
Le principali criticità per un sistema con una replica attiva (repliche master/master o cluster galera) sono legate alla gestione degli inserimenti univoci. Nell'utilizzo dei server MySQL, l'utilizzo di ID primari autoincrementali è infatti una consuetudine molto comune, e non comporta problemi significativi fintanto che l'utilizzo è limitato ad una macchina. Tuttavia, nel momento in cui introduciamo ulteriori punti di inserimento dati (server abilitati alla scrittura), è possibile incappare in una coincidenza accidentale nell'ID generato, con conseguente interruzione della sincronia.
In questo caso abbiamo infatti un inserimento concorrenziale, e il sistema nel complesso non è in grado di gestirlo senza una perdita di dati. Come abbiamo visto in precedenza, è possibile utilizzare le direttive auto_increment_increment e auto_increment_offset per permettere ad ogni macchina di generare un proprio set di ID senza rischio di coincidenza. In questo caso, una macchina genererà ad esempio gli ID 1, 4, 7, 10, eccetera, mentre un'altra utilizzerà la sequenza 2, 5, 8, 11, e così via.
Il punto negativo di questa tecnica risiede nella mancanza di sequenzialità degli ID complessivamente inseriti nel database, considerando che anche le singole sequenze non verranno rispettate totalmente. Il risultato finale quindi potrebbe essere una sequenza combinata tipo 1, 2, 5, 7, 10, 11, rispetto agli esempi precedenti.
Con questa tecnica, inoltre, gli ID verranno calcolati dal server (e quindi il client, che esegue l'operazione di inserimento, deve interrogare nuovamente il database per poter scoprire l'ID utilizzato). Nel caso di un cluster di dimensione dinamica, in cui cioè i nodi possono essere aggiunti o eliminati sulla base delle necessità contingenti, Galera ci viene incontro ed è in grado di calcolare e impostare autonomamente queste due direttive in modo da evitare le collisioni. Questo funzionamento può essere disabilitato, anche se si tratta di una pratica sconsigliata, tramite la direttiva wsrep_auto_increment_control che accetta come valore un booleano.
La direttiva wsrep_drupal_282555_workaround, invece, evita collisioni nei campi auto_increment se i record vengono inseriti con il valore auto_increment di default. Il nome derivata dal fatto che tale soluzione è stata inizialmente proposta per il progetto Drupal.
Possiamo utilizzare anche una seconda soluzione: lo standard UUID (Universally Unique IDentifier), in cui la generazione dell'ID viene demandata al client. Il client infatti crea un ID composto da 32 caratteri esadecimali (più 4 caratteri - utilizzati come spaziatori, per un totale di 36 caratteri) in modo da avere un totale teorico di codici generabili superiore a 10 alla 38esima potenza, rendendo praticamente impossibile ottenere una collisione tra ID. Ovviamente il lato negativo di questa tecnica è rappresentato dalla necessità di modificare il software in modo da generare autonomamente gli identificativi senza affidarsi al server MySQL per questo scopo.