This is a read-only copy of the MariaDB Knowledgebase generated on 2024-11-14. For the latest, interactive version please visit https://mariadb.com/kb/.

Primi passi con MariaDB Galera Cluster

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

Attualmente MariaDB Galera Cluster supporta solo lo Storage Engine InnoDB/XtraDB.

Scaricare e installare MariaDB Galera Cluster

Due cose sono necessarie:

  1. MariaDB Galera Cluster
  1. 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.

Si usi un indirizzo gcomm: vuoto solo quando si intende creare un nuovo cluster. Non bisogna farlo mai per riconnettersi a uno già 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.

Trasferimento dello Snapshot dello Stato

Vi sono due modalità concettualmente diverse per trasferire uno stato da un server MariaDB a un altro:

  1. Usare mysqldump. Richiede che il server ricevente sia già inizializzato e pronto ad accettare connessioni prima del trasferimento. Questo metodo è bloccante per definizione, in quanto impedisce al server donatore di modificare il proprio stato per tutta la durata del trasferimento. E' inoltre il metodo più lento di tutti, il che potrebbe essere un problema in un cluster carico di lavoro.
  1. Copiare direttamente i file dei dati. Richiede che il server ricevente venga inizializzato dopo il trasferimento. rsync, xtrabackup e altri metodi ricadono in questa categoria. Tali metodi sono molto più rapidi di mysqldump, ma hanno alcune limitazioni. Per esempio, possono essere utilizzati soltanto all'avvio del server, e la configurazione del server ricevente deve essere simile a quella del donatore (per esempio innodb_file_per_table dovrebbe avere lo stesso valore, e così via). Alcuni di questi metodi (come xtrabackup) potenzialmente potrebbero essere resi non-bloccanti sul donatore. Essi sono implementati attraverso un'interfaccia programmabile con degli script.

Script SST

MariaDB Galera Cluster contiene i seguenti script SST:

mysqldump

E' il metodo predefinito. Questo script viene eseguito solo sul lato del donatore e indirizza l'output di mysqldump a un client mysql connesso al server ricevente. Come spiegato qui, mysqldump ha richiede che una coppia nome utente/password sia impostata nella variabile wsrep_sst_auth per poter funzionare.

rsync/rsync_wan

Questo è probabilmente il metodo più veloce per trasferire un'istantanea di stato da un server a un altro. Lo script viene eseguito sia sul lato del donatore, sia su quello del ricevente. Sul lato del ricevente avvia rsync in modalità client e invia i contenuti alla directory dei dati di MariaDB che si trova nel nodo che si sta connettendo. Questo metodo è bloccante, ma molto più rapido di mysqldump. rsync_wan è ottimizzato per trasferire gli stati attraverso una WAN, minimizzando l'ammontare di dati trasferiti.

Per specificare quale metodo di trasferimento deve essere utilizzato, si imposti (su un nodo che si sta unendo al cluster) la variabile wsrep_sst_method con il nome del metodo, in questo modo:

wsrep_sst_method=rsync_wan

Fallimento del trasferimento di stato

E' facile capire che un fallimento nel trasferimento di stato generalmente rende il nodo ricevente inutilizzabile. Perciò, se viene rilevato un fallimento, il trasferimento viene abortito. Per riavviare un nodo dopo un fallimento di mysqldump potrebbe essere necessario recuperare manualmente le tabelle amministrative. Il metodo rsync non ha questo svantaggio perchè non richiede che il server sia operativo durante il trasferimento.

Dimensioni minime del cluster

Per evitare una condizione split-brain, si raccomanda che nel cluster vi siano almeno 3 nodi. I trasferimenti di stato bloccanti sono un ulteriore motivo per avere almeno 3 nodi, per potersi avvalere della disponibilità del servizio nel caso in cui uno dei membri fallisca e debba essere riavviato. Mentre due dei membri saranno impegnati nel trasferimento di stato, il membro restante potrà continuare a servire le richieste dei client.

Configurazione e Monitoring

Anche se sono stati compiuti tutti gli sforzi per far sì che i nodi MySQL/Galera funzionino in situazioni reali, è necessario che alcuni parametri siano impostati in un certo modo.

Impostazioni obbligatorie:

  1. wsrep_provider — path della libreria Galera
  2. wsrep_cluster_addressURL per la connessione al cluster
  3. binlog_format=ROW
  4. default_storage_engine=InnoDB
  5. innodb_autoinc_lock_mode=2
  6. innodb_locks_unsafe_for_binlog=1

Se si utilizza un provider Galera versione >= 2.0, innodb_doublewrite deve sempre essere impostato a 1 (predefinito).

Impostazioni opzionali

Queste ottimizzazioni sono rese relativamente sicure dalla replica sincrona — in caso di problemi, si recupera da un altro nodo.

  1. innodb_flush_log_at_trx_commit=2

Configurazione

Monitoring

  1. Le variabili di stato relative a wsrep nei server MariaDB Galera Cluster possono essere interrogate con il comando standard:
mysql> SHOW STATUS LIKE 'wsrep_%';
  1. query. Si veda questa pagina per una spiegazione dettagliata delle variabili.
  1. Si può definire un comando di notifica da invocare quando cambiano i membri del cluster o lo stato del nodo. In tal modo si può comunicare l'evento a un agente di monitoring.

Vedi anche

Note a piè di pagina

  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
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.