Primi passi con MariaDB Galera Cluster

MariaDB Galera Cluster è MariaDB più la patch MySQL-wsrep di Codership.

Scaricare e installare MariaDB Galera Cluster

Due cose sono necessarie:

1. MariaDB Galera Cluster

2. Il provider Galera wsrep

Si scarichi e si installi i binari di MariaDB Galera Cluster come se fossero i normali eseguibili di MariaDB. Se si compila MariaDB Galera Cluster dal tarball dei sorgenti, si imposti: -DWITH_WSREP=ON and -DWITH_INNODB_DISALLOW_WRITES=1.

La pagina dei download del provider Galera wsrep contiene i pacchetti per Debian/Ubuntu e RedHat/CentOS. E' anche possibile scaricare, compilare e installare il codice sorgente.

Prerequisiti

Requisiti delle dimensioni dello Swap

Durante le normali operazioni, un nodo MariaDB Galera non consuma molta più memoria di un comune server MariaDB. Il consumo aumenta per l'indice della certificazione e gli insiemi di modifiche, ma normalmente un'applicazione tipica non dovrebbe notare la differenza. C'è però un'eccezione:

1. Caching degli insieme delle modifiche durante il trasferimento di stato. Quando un nodo riceve un trasferimento di stato non può elaborare e applicare gli insiemi di modifiche in entrata perché non ha ancora uno stato sul quale applicarle. A seconda del meccanismo del trasferimento (per esempio mysqldump) anche il nodo che lo invia potrebbe non essere in grado di applicare gli insiemi di modifiche. Pertanto è necessario scrivere in una cache quelle modifiche per una successiva fare catch-up. Attualmente gli insiemi delle modifiche vengono scritti in una cache e, se il sistema consuma tutta la memoria disponibile, o il trasferimento di stato fallisce oppure il cluster si blocca aspettando che il trasferimento termini.

Per controllare l'utilizzo della memoria durante il caching degli insiemi delle modifiche, si possono usare i parametri di Galera: gcs.recv_q_hard_limit, gcs.recv_q_soft_limit e gcs.max_throttle.

Primi passi

Bootstrap di un nuovo cluster

Per eseguire il bootstrap di un nuovo cluster occorre avviare il primo server mysqld specificado un URL vuoto nel file my.cnf o nella riga di comando, in questo modo:

$ mysqld --wsrep_cluster_address=gcomm://

Questo implica per il server che non esiste ancora alcun cluster al quale connettersi, e crea un nuovo UUID nella cronologia.

Riavviando il server con questa stessa impostazione si fa sì che esso crei di nuovo un UUID nella cronologia, e non si riconnnetterà al vecchio cluster. Si veda la prossima sezione per sapere come riconnettersi a un cluster esistente.

Aggiungere un nuovo nodo a un cluster

Se si ha un cluster funzionante e si desidera aggiungere o riconnettere un nodo, occorre fornire l'URL di uno degli altri nodi come indirizzo del cluster. Per esempio, se il primo nodo ha come indirizzo 192.168.0.1, per aggiungerne un secondo si può fare quanto segue:

$ mysqld --wsrep_cluster_address=gcomm://192.168.0.1  # funzionano anche i nomi DNS

Il nuovo nodo ha solo bisogno di collegarsi a uno dei membri già esistenti. Esso rileva automaticamente la mappa del cluster e si riconnette agli altri nodi.

Dopo che tutti i membri accettano la sua entrata, viene iniziato un trasferimento di stato durante il quale il nuovo nodo verrà informato appunto dello stato del cluster. Se il suo stato è differente da quello del cluster (il che normalmente è vero) richiederà uno snapshot (un'istantanea) di tale stato^[1]) e lo installa, per poter poi essere utilizzabile.

State Snapshot Transfer

There are two conceptually different ways to transfer a state from one MariaDB server to another:

1. Using mysqldump. This requires the receiving server to be fully initialized and ready to accept connections before the transfer. This method is, by definition, blocking, in that it blocks the donor server from modifying its own state for the duration of the transfer. It is also the slowest of all, and that might be an issue in a loaded cluster.

2. Copying data files directly. This requires that the receiving server is initialized after the transfer. rsync, xtrabackup, and other methods fall into this category. These methods are much faster than mysqldump, but they have certain limitations. For example, they can be used only on server startup and the receiving server must be configured very similarly to the donor (e.g. innodb_file_per_table should be the same and so on). Some of these methods (e.g. xtrabackup) can be potentially made non-blocking on the donor. Such methods are supported via a scriptable interface.

SST Scripts

MariaDB Galera Cluster comes with the following following SST scripts:

mysqldump

This is a default method. This script runs only on the sending side and pipes mysqldump output to mysql client connected to receiving server. As noted here, mysqldump needs a username/password pair set in the wsrep_sst_auth variable in order to get the dump.

rsync/rsync_wan

This is probably the fastest way to transfer server state snapshot from one server to another. The script runs on both sending and receiving sides. On receiving side it starts rsync in server mode and waits for connection from sender. On the sender side it starts rsync in client mode and sends contents of the MySQL data directory to the joining node. This method is also blocking but is much faster than mysqldump. rsync_wan method is optimized for transfers over WAN by minimizing the amount of data transferred.

To use a particular state transfer method set (on a joining node) the wsrep_sst_method variable to the name of the method, like:

wsrep_sst_method=rsync_wan

State transfer failure

It is easy to see that a failure in state transfer generally renders the receiving node unusable. Therefore, should the failure be detected, it will abort. Restarting node after a mysqldump failure may require manual restoration of the administrative tables. The rsync method does not have this issue since it does not need the server to be in an operational state.

Minimal cluster size

In order to avoid a split-brain condition, the minimum recommended number of nodes in a cluster is 3. Blocking state transfer is yet another reason to require a minimum of 3 nodes in order to enjoy service availability in case one of the members fails and needs to be restarted. While two of the members will be engaged in state transfer, the remaining member(s) will be able to keep on serving client requests.

Configuration and Monitoring

While every effort is made to get MySQL/Galera node to work out of the box, still few parameters need to be set to get it working.

Mandatory settings:

1. wsrep_provider — path to the Galera library
2. wsrep_cluster_address — cluster connection URL
3. binlog_format=ROW
4. default_storage_engine=InnoDB
5. innodb_autoinc_lock_mode=2
6. innodb_locks_unsafe_for_binlog=1

Optional settings

These are just optimizations made relatively safe by synchronous replication — you always recover from another node.

1. innodb_flush_log_at_trx_commit=2

Configuration

• 0.8 series MySQL options

Monitoring

1. Wsrep-related status variables in MariaDB Galera Cluster server can be queried with the standard

mysql> SHOW STATUS LIKE 'wsrep_%';

1. query. See this page for a detailed variable description.

2. The notification command can be defined to be invoked when cluster membership or node status changes. It can communicate the event to a some monitoring agent.

See also

• What is MariaDB Galera Cluster?
• About Galera Replication
• Galera Use Cases
• Codership: Using Galera Cluster

Footnotes

1. ↑ Il cluster sceglierà il donatore di stato più comodo o, in alternativa, si può specificare all'avvio quale nodo si desidera che assuma tale ruolo