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).

• LOCK/UNLOCK TABLES non possono essere supportati nella replica master-master. Le funzioni sui lock (GET_LOCK(), RELEASE_LOCK()...) non 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.

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-400: Se si sta eseguendo un server di debug e un nodo non è stato in grado di connettersi al cluster all'avvio, questo potrebbe crashare con uno strano errore che dice 'debugger aborting because missing DBUG_RETURN or DBUG_VOID_RETURN macro in function "?func"'. Non si faccia caso al crash, ci si concentri sul fatto che non è riuscito a conettersi, perché è questo il problema da risolvere.

• 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.

• MDEV-443: Non si imposti character_set_server a utf16 o utf32 o ucs2, almeno se si utilizza rsync come metodo per il trasferimento dello stato. Il server crasherebbe.

• Do not use transactions of any essential size. Just to insert 100K rows, the server might require additional 200-300 Mb. In a less fortunate scenario it can be 1.5 Gb for 500K rows, or 3.5 Gb for 1M rows. See MDEV-466 for some numbers (you'll see that it's closed, but it's not closed because it was fixed).

• Locking is lax when DDL is involved. For example, if your DML transaction uses a table, and a parallel DDL statement is started, in the normal MySQL setup it would have waited for the metadata lock, but in Galera context it will be executed right away. It happens even if you are running a single node, as long as you configured it as a cluster node. See also MDEV-468. This behavior might cause various side-effects, the consequences have not been investigated yet. Try to avoid such parallelism.

• Do not rely on auto-increment values to be sequential. Galera uses a mechanism based on autoncrement increment to produce unique non-conflicting sequences, so on every single node the sequence will have gaps. See http://codership.blogspot.com/2009/02/managing-auto-increments-with-multi.html

• Every now and then, a node might start producing 'Unknown command' errors on pretty much every statement except for SHOW and maybe some other service commands. It happens when a cluster is suspected to be split, and the node is in a smaller part — for example, during a network glitch, when nodes temporarily lose each other. The error is scary, but it does not mean the server got crazy, it only means it thinks it might be. It was also noticed to happen when a node transfers state to another node.

• After a temporary split, if the 'good' part of the cluster was still reachable and its state was modified, resynchronization occurs. As a part of it, nodes of the 'bad' part of the cluster drop all client connections. It might be quite unexpected, especially if the client was idle and did not even know anything wrong was happening. Please also note that after the connection to the isolated node is restored, if there is a flow on the node, it takes a long time for it to synchronize, during which the "good" node says that the cluster is already of the normal size and synced, while the rejoining node says it's only joined (but not synced). The connections keep getting 'unknown command'. It should pass eventually.

• While binlog_format is checked on startup and can only be ROW, it can be changed at runtime. Do NOT change binlog_format at runtime, it is likely not only cause replication failure, but make all other nodes crash.

• If you are using rsync for state transfer, and a node crashes before the state transfer is over, rsync process might hang forever, occupying the port and not allowing to restart the node. The problem will show up as 'port in use' in the server error log. Find the orphan rsync process and kill it manually.

• Performance: by design performance of the cluster cannot be higher than performance of the slowest node; however, even if you have only one node, its performance can be considerably lower comparing to running the same server in a standalone mode (without wsrep provider). It is particularly true for big enough transactions (even those which are well within current limitations on transaction size quoted above).

• Windows is not supported.