MariaDB Galera Cluster - Limitazioni note

Questo articolo illustra i problemi noti e le limitazioni di MariaDB Galera Cluster.

Limitazioni da codership.com:

• Al momento la replica funziona solo con lo Storage Engine InnoDB. Tutte le modifiche su tabelle di altri tipi, comprese quelle di sistema (mysql.*), non vengono replicate (questo non riguarda le istruzioni del DDL che modificano implicitamente le tabelle mysql.* — tali istruzioni vengono replicate). Vi è comunque un supporto sperimentale a MyISAM - si veda la variabile di sistema wsrep_replicate_myisam).

• Non è supportato il locking esplicito, compresi LOCK TABLES, FLUSH TABLES {lista tabelle esplicita} WITH READ LOCK, (GET_LOCK(), RELEASE_LOCK(), …). Un uso appropriato delle transazioni dovrebbe aggirare queste limitazioni. Le istruzioni per il locking globale, come FLUSH TABLES WITH READ LOCK, sono supportate.

• L'operazione DELETE non è supportata per le tabelle sprovviste di chiave primaria. Inoltre le righe nelle tabelle senza chiave potrebbero essere memorizzate in ordine differente sui diversi nodi. Non bisogna usare tabelle senza chiave primaria.

• Il log delle query non può essere diretto a una tabella. Se si abilita il log delle query, occorre indirizzarlo a un file: log_output=FILE.

• Le transazioni XA non possono essere supportate.

• Dimensioni delle transazioni. Nonostante Galera non limiti esplicitamente le dimensioni delle transazioni, ogni insieme di modifiche viene elaborato in un singolo buffer residente in memoria e di conseguenza le transazioni molto grandi (per esempio LOAD DATA) potrebbero influenzare negativamente le prestazioni dei nodi. Per evitare ciò, le variabili wsrep_max_ws_rows e wsrep_max_ws_size limitano le righe che compongono le transazioni a 128K e le dimensioni delle transazioni a 1Gb, per default. Se necessario, l'utente può incrementare questi limiti. Le versioni future supporteranno la frammentazione delle transazioni.

Limitazioni da altre fonti:

• La cache delle query non deve essere utilizzata con Galera Cluster (fonte: Gruppo Google di Codership)

Altre osservazioni in ordine sparso:

• Se si intende utilizzare mysqldump per trasferire lo stato, ma esso fallisce per una qualsiasi ragione (per esempio se l'account che tenta di utilizzare per la connessione non esiste, oppure non ha i permessi necessari), si ottiene un errore di tipo SQL SYNTAX nel log degli errori. Non bisogna lasciarsi ingannare, è soltanto un modo elegante per comunicare un messaggio (la pseudo-istruzione in SQL contiene il messaggio di errore effettivo).

• MDEV-421: Non si utilizzino binlog-do-db e binlog-ignore-db — sono supportati solo per il DML, ma non per il DDL, perciò si formerebbe rapidamente una discrepanza e la replica abortirebbe.

• Non vanno usate transazioni di dimensioni importanti. Solo per inserire 100K righe, il server potrebbe necessitare di 200-300 Mb aggiuntivi. In situazioni meno fortunate potrebbero essere necessari 1.5 Gb per 500K righe, o 3.5 Gb per 1M righe. Si veda MDEV-466 per conoscere altri numeri (il bug è effettivamente chiuso, ma non perché sia stato risolto).

• Il lock è permissivo per quando riguarda il DDL. Per esempio, se una transazione DML utilizza una tabella e intanto viene lanciato un altro comando parallelo DDL, nella normale configurazione di MySQL questo dovrebbe attendere il rilascio del lock sui metadati, mentre in Galera viene eseguiro direttamente. Ciò è vero anche se è in esecuzione un solo nodo, purché questo sia configurato come nodo cluster. Si veda anche MDEV-468. Tale caratteristica potrebbe essere causa di vari effetti collaterali, per il momento le conseguenze non sono state studiate. E' meglio evitare questo genere di parallelismo.

• Non bisogna fare affidamento sulla sequenzialità dei valori auto-increment. Galera si serve di un meccanismo basato su un incremento che produce sequenze univoche e non conflittuali, pertanto in ogni singolo nodo le sequenza hanno dei gap. Si veda http://codership.blogspot.com/2009/02/managing-auto-increments-with-multi.html

• Di tanto in tanto, all'avvio di un nodo potrebbe verificarsi l'errore 'Unknown command' su quasi tutte le istruzioni ad eccezione di SHOW e forse alcuni altri comandi di servizio. Ciò accade quando c'è il sospetto che un cluster sia diviso, e che il nodo si trovi in una parte più piccola — per esempio, se a causa di un problema di rete i nodi temporaneamente non siano in grado di comunicare. L'errore è inquietante ma non significa che il server è impazzito, semplicemente pensa di esserlo. E' stato notato che tale problema si verifica quando un nodo trasferisce lo stato ad un altro nodo.

• Dopo un problema di rete temporaneo, se la parte 'buona' del cluster è ancora raggiungibile e il suo stato è rimasto immutato, avviene una resincronizzazione. Durante tale operazione i nodi della parte 'cattiva' del cluster chiudono le connessioni verso i client. Questo evento potrebbe risultare inaspettato, soprattutto se un client era in idle e non sapeva nemmeno che qualcosa fosse andato storto. Si noti che dopo il riprisino della connessione al nodo isolato, se vi è un flusso nel nodo, la sincronizzazione può richiedere molto tempo, durante il quale il nodo "buono" dice che il cluster ha già le dimensioni normali ed è sincronizzato, mentre il nodo che si sta riunendo dice di essersi solo riunito (ma non sincronizzato). Le connessioni intanto continuano a ricevere l'errore 'unknown command'. Alla fine dovrebbero smettere.

• binlog_format viene verificato all'avvio e deve essere impostato a ROW, però potrebbe essere modificato a runtime. NON si modifichi binlog_format a runtime, perché non solo è probabile che ciò causi un fallimento nella replica, ma porterebbe a un crash di tutti gli altri nodi.

• Se si utilizza rsync per trasferire lo stato e un nodo crasha prima che il trasferimento sia terminato, il processo di rsync potrebbe rimanere in attesa per sempre, occupando la porta e non impedendo il riavvio del nodo. Il problema è indicato come 'port in use', nel log degli errori del server. Occorre allora trovare il processo resync orfano e terminarlo manualmente.

• Prestazioni: per una scelta di progettazione, le prestazioni del cluster non possono essere superiori a quelle del nodo più lento; tuttavia, anche se si ha un solo nodo, le sue performance potrebbero essere considerevolmente più basse di quelle che si otterrebbero facendo girare il server in modalità standalone (senza un provider wsrep). Ciò è vero soprattutto per le transazioni più grandi (anche quelle che si trovano abbondantemente nei limiti indicati sopra).

• Windows non è supportato.