Nel precedente post del blog, abbiamo mostrato alcuni passaggi di base per distribuire e gestire un server MySQL autonomo, nonché l'impostazione della replica MySQL utilizzando il modulo MySQL Puppet. In questa seconda installazione tratteremo passaggi simili, ma ora con una configurazione di Galera Cluster.
Galera Cluster con pupazzo
Come forse saprai, Galera Cluster ha tre fornitori principali:
- Gruppo MySQL Galera (codership)
- Percona XtraDB Cluster (Percona)
- Cluster MariaDB (incorporato in MariaDB Server da MariaDB)
Una pratica comune con le distribuzioni di Galera Cluster consiste nell'avere un livello aggiuntivo posizionato sopra il cluster di database per scopi di bilanciamento del carico. Tuttavia, si tratta di un processo complesso che merita un post a parte.
Ci sono un certo numero di moduli Puppet disponibili nella Puppet Forge che possono essere usati per schierare un Cluster Galera. Eccone alcuni..
- puppetlabs/mysql - solo MariaDB Galera
- fraenki/galera - Cluster Percona XtraDB e MySQL Galera da Codership
- edestecd/mariadb - Solo cluster MariaDB
- filiadata/percona - Cluster Percona XtraDB
Poiché il nostro obiettivo è fornire una comprensione di base di come scrivere manifest e automatizzare la distribuzione per Galera Cluster, tratteremo la distribuzione di MariaDB Galera Cluster utilizzando il modulo puppetlabs/mysql. Per gli altri moduli, puoi sempre dare un'occhiata alla rispettiva documentazione per istruzioni o suggerimenti su come installare.
In Galera Cluster, l'ordinamento all'avvio del nodo è fondamentale. Per avviare correttamente un nuovo cluster, è necessario configurare un nodo come nodo di riferimento. Questo nodo verrà avviato con una stringa di connessione host vuota (gcomm://) per inizializzare il cluster. Questo processo è chiamato bootstrap.
Una volta avviato, il nodo diventerà un componente primario e i nodi rimanenti potranno essere avviati utilizzando il comando standard mysql start (systemctl start mysql o service mysql start ) seguito da una stringa di connessione host completo (gcomm://db1,db2,db3). Il bootstrap è richiesto solo se non ci sono componenti primari conservati da nessun altro nodo nel cluster (controlla con wsrep_cluster_status stato).
Il processo di avvio del cluster deve essere eseguito in modo esplicito dall'utente. Il manifest stesso NON deve avviare il cluster (bootstrap di qualsiasi nodo) alla prima esecuzione per evitare qualsiasi rischio di perdita di dati. Ricorda, il manifest di Puppet deve essere scritto per essere il più idempotente possibile. Il manifest deve essere sicuro per poter essere eseguito più volte senza influire sulle istanze MySQL già in esecuzione. Ciò significa che dobbiamo concentrarci principalmente sulla configurazione del repository, sull'installazione del pacchetto, sulla configurazione pre-esecuzione e sulla configurazione dell'utente SST.
Le seguenti opzioni di configurazione sono obbligatorie per Galera:
- wsrep_on :un flag per attivare l'API di replica writeset per Galera Cluster (solo MariaDB).
- wsrep_cluster_name :il nome del cluster. Deve essere identico su tutti i nodi che fanno parte dello stesso cluster.
- wsrep_cluster_address :La stringa di connessione di comunicazione Galera, preceduta da gcomm:// e seguita dall'elenco dei nodi, separata da virgola. L'elenco dei nodi vuoto indica l'inizializzazione del cluster.
- wsrep_provider :Il percorso dove risiede la biblioteca Galera. Il percorso potrebbe essere diverso a seconda del sistema operativo.
- bind_address :MySQL deve essere raggiungibile esternamente, quindi il valore '0.0.0.0' è obbligatorio.
- wsrep_sst_method :Per MariaDB, il metodo SST preferito è mariabackup.
- wsrep_sst_auth :Utente e password MySQL (separati da due punti) per eseguire il trasferimento di istantanee. Di solito, specifichiamo un utente che ha la possibilità di creare un backup completo.
- wsrep_node_address :indirizzo IP per la comunicazione e la replica Galera. Usa Puppet facter per scegliere l'indirizzo IP corretto.
- wsrep_node_name :nome host dell'FQDN. Usa Puppet facter per scegliere il nome host corretto.
Per le implementazioni basate su Debian, lo script post-installazione tenterà di avviare automaticamente il server MariaDB. Se abbiamo configurato wsrep_on=ON (flag per abilitare Galera) con l'indirizzo completo in wsrep_cluster_address variabile, il server non funzionerebbe durante l'installazione. Questo perché non ha un componente principale a cui connettersi.
Per avviare correttamente un cluster in Galera, il primo nodo (chiamato bootstrap node) deve essere configurato con una stringa di connessione vuota (wsrep_cluster_address =gcomm://) per avviare il nodo come componente principale. Puoi anche eseguire lo script bootstrap fornito, chiamato galera_new_cluster, che sostanzialmente fa una cosa simile ma in background.
Distribuzione del Cluster Galera (MariaDB)
La distribuzione di Galera Cluster richiede una configurazione aggiuntiva sull'origine APT per installare il repository della versione MariaDB preferito.
Si noti che la replica Galera è incorporata all'interno di MariaDB Server e non richiede l'installazione di pacchetti aggiuntivi. Detto questo, è necessario un flag aggiuntivo per abilitare Galera usando wsrep_on=ON. Senza questo flag, MariaDB fungerà da server autonomo.
Nel nostro ambiente basato su Debian, l'opzione wsrep_on può essere presente nel manifest solo dopo il completamento della prima distribuzione (come mostrato più in basso nei passaggi di distribuzione). Questo per garantire che il primo avvio iniziale agisca come un server autonomo per Puppet per eseguire il provisioning del nodo prima che sia completamente pronto per essere un nodo Galera.
Iniziamo preparando il contenuto del manifest come di seguito (modificare la sezione delle variabili globali se necessario):
# Puppet manifest for Galera Cluster MariaDB 10.3 on Ubuntu 18.04 (Puppet v6.4.2)
# /etc/puppetlabs/code/environments/production/manifests/galera.pp
# global vars
$sst_user = 'sstuser'
$sst_password = 'S3cr333t$'
$backup_dir = '/home/backup/mysql'
$mysql_cluster_address = 'gcomm://192.168.0.161,192.168.0.162,192.168.0.163'
# node definition
node "db1.local", "db2.local", "db3.local" {
Apt::Source['mariadb'] ~>
Class['apt::update'] ->
Class['mysql::server'] ->
Class['mysql::backup::xtrabackup']
}
# apt module must be installed first: 'puppet module install puppetlabs-apt'
include apt
# custom repository definition
apt::source { 'mariadb':
location => 'http://sfo1.mirrors.digitalocean.com/mariadb/repo/10.3/ubuntu',
release => $::lsbdistcodename,
repos => 'main',
key => {
id => 'A6E773A1812E4B8FD94024AAC0F47944DE8F6914',
server => 'hkp://keyserver.ubuntu.com:80',
},
include => {
src => false,
deb => true,
},
}
# Galera configuration
class {'mysql::server':
package_name => 'mariadb-server',
root_password => '[email protected]#',
service_name => 'mysql',
create_root_my_cnf => true,
remove_default_accounts => true,
manage_config_file => true,
override_options => {
'mysqld' => {
'datadir' => '/var/lib/mysql',
'bind_address' => '0.0.0.0',
'binlog-format' => 'ROW',
'default-storage-engine' => 'InnoDB',
'wsrep_provider' => '/usr/lib/galera/libgalera_smm.so',
'wsrep_provider_options' => 'gcache.size=1G',
'wsrep_cluster_name' => 'galera_cluster',
'wsrep_cluster_address' => $mysql_cluster_address,
'log-error' => '/var/log/mysql/error.log',
'wsrep_node_address' => $facts['networking']['interfaces']['enp0s8']['ip'],
'wsrep_node_name' => $hostname,
'innodb_buffer_pool_size' => '512M',
'wsrep_sst_method' => 'mariabackup',
'wsrep_sst_auth' => "${sst_user}:${sst_password}"
},
'mysqld_safe' => {
'log-error' => '/var/log/mysql/error.log'
}
}
}
# force creation of backup dir if not exist
exec { "mkdir -p ${backup_dir}" :
path => ['/bin','/usr/bin'],
unless => "test -d ${backup_dir}"
}
# create SST and backup user
class { 'mysql::backup::xtrabackup' :
xtrabackup_package_name => 'mariadb-backup',
backupuser => "${sst_user}",
backuppassword => "${sst_password}",
backupmethod => 'mariabackup',
backupdir => "${backup_dir}"
}
# /etc/hosts definition
host {
'db1.local': ip => '192.168.0.161';
'db2.local': ip => '192.169.0.162';
'db3.local': ip => '192.168.0.163';
}Un po' di spiegazione è necessaria a questo punto. 'wsrep_node_address' deve essere puntato allo stesso indirizzo IP dichiarato in wsrep_cluster_address. In questo ambiente i nostri host hanno due interfacce di rete e vogliamo usare la seconda interfaccia (chiamata enp0s8) per la comunicazione Galera (a cui è collegata la rete 192.168.0.0/24). Ecco perché utilizziamo Puppet facter per ottenere le informazioni dal nodo e applicarle all'opzione di configurazione. Il resto è abbastanza autoesplicativo.
Su ogni nodo MariaDB, esegui il seguente comando per applicare il catalogo come utente root:
$ puppet agent -tIl catalogo verrà applicato a ciascun nodo per l'installazione e la preparazione. Una volta fatto, dobbiamo aggiungere la seguente riga nel nostro manifest nella sezione "override_options => mysqld":
'wsrep_on' => 'ON',Quanto sopra soddisferà il requisito Galera per MariaDB. Quindi, applica ancora una volta il catalogo su ogni nodo MariaDB:
$ puppet agent -tUna volta terminato, siamo pronti per eseguire il bootstrap del nostro cluster. Poiché si tratta di un nuovo cluster, possiamo scegliere qualsiasi nodo come nodo di riferimento, noto anche come nodo di bootstrap. Prendiamo db1.local (192.168.0.161) ed eseguiamo il seguente comando:
$ galera_new_cluster #db1Una volta avviato il primo nodo, possiamo avviare il nodo rimanente con il comando di avvio standard (un nodo alla volta):
$ systemctl restart mariadb #db2 and db3Una volta avviato, dai un'occhiata al log degli errori di MySQL in /var/log/mysql/error.log e assicurati che il log finisca con la seguente riga:
2019-06-10 4:11:10 2 [Note] WSREP: Synchronized with group, ready for connectionsQuanto sopra ci dice che i nodi sono sincronizzati con il gruppo. Possiamo quindi verificare lo stato utilizzando il seguente comando:
$ mysql -uroot -e 'show status like "wsrep%"'Assicurati che su tutti i nodi, wsrep_cluster_size , wsrep_cluster_status e wsrep_local_state_comment sono rispettivamente 3, "Primario" e "Sincronizzato".
Gestione MySQL
Questo modulo può essere utilizzato per eseguire una serie di attività di gestione di MySQL...
- opzioni di configurazione (modifica, applica, configurazione personalizzata)
- risorse del database (database, utente, sovvenzioni)
- backup (creazione, pianificazione, backup utente, archiviazione)
- ripristino semplice (solo mysqldump)
- Installazione/attivazione plugin
Controllo del servizio
Il modo più sicuro durante il provisioning di Galera Cluster con Puppet consiste nel gestire manualmente tutte le operazioni di controllo del servizio (non lasciare che sia Puppet a gestirle). Per un semplice riavvio in sequenza del cluster, andrebbe bene il comando di servizio standard. Esegui il comando seguente un nodo alla volta.
$ systemctl restart mariadb # Systemd
$ service mariadb restart # SysVinitTuttavia, nel caso in cui si verifichi una partizione di rete e nessun componente primario sia disponibile (controlla con wsrep_cluster_status ), è necessario eseguire il bootstrap del nodo più aggiornato per riportare il cluster operativo senza perdita di dati. È possibile seguire i passaggi come mostrato nella sezione di distribuzione sopra. Per saperne di più sul processo di bootstrap con scenari di esempio, ne abbiamo parlato in dettaglio in questo post del blog, How to Bootstrap MySQL o MariaDB Galera Cluster.
Risorsa database
Usa la classe mysql::db per assicurarti che sia presente un database con utente e privilegi associati, ad esempio:
# make sure the database and user exist with proper grant
mysql::db { 'mynewdb':
user => 'mynewuser',
password => 'passw0rd',
host => '192.168.0.%',
grant => ['SELECT', 'UPDATE']
} La definizione di cui sopra può essere assegnata a qualsiasi nodo poiché ogni nodo in un Cluster Galera è un master.
Backup e ripristino
Poiché abbiamo creato un utente SST utilizzando la classe xtrabackup, Puppet configurerà tutti i prerequisiti per il processo di backup:creazione dell'utente di backup, preparazione del percorso di destinazione, assegnazione di proprietà e autorizzazione, impostazione del processo cron e configurazione delle opzioni del comando di backup da utilizzare nello script di backup fornito. Ogni nodo verrà configurato con due processi di backup (uno per completo settimanale e un altro per incrementale giornaliero) per impostazione predefinita alle 23:05, come puoi vedere dall'output di crontab:
$ crontab -l
# Puppet Name: xtrabackup-weekly
5 23 * * 0 /usr/local/sbin/xtrabackup.sh --target-dir=/home/backup/mysql --backup
# Puppet Name: xtrabackup-daily
5 23 * * 1-6 /usr/local/sbin/xtrabackup.sh --incremental-basedir=/home/backup/mysql --target-dir=/home/backup/mysql/`date +%F_%H-%M-%S` --backupSe invece desideri pianificare mysqldump, usa la classe mysql::server::backup per preparare le risorse di backup. Supponiamo di avere la seguente dichiarazione nel nostro manifest:
# Prepare the backup script, /usr/local/sbin/mysqlbackup.sh
class { 'mysql::server::backup':
backupuser => 'backup',
backuppassword => 'passw0rd',
backupdir => '/home/backup',
backupdirowner => 'mysql',
backupdirgroup => 'mysql',
backupdirmode => '755',
backuprotate => 15,
time => ['23','30'], #backup starts at 11:30PM everyday
include_routines => true,
include_triggers => true,
ignore_events => false,
maxallowedpacket => '64M'
}Quanto sopra dice a Puppet di configurare lo script di backup su /usr/local/sbin/mysqlbackup.sh e di programmarlo ogni giorno alle 23:30. Se vuoi fare un backup immediato, invoca semplicemente:
$ mysqlbackup.shPer il ripristino, il modulo supporta solo il ripristino con metodo di backup mysqldump, importando il file SQL direttamente nel database utilizzando la classe mysql::db, ad esempio:
mysql::db { 'mydb':
user => 'myuser',
password => 'mypass',
host => 'localhost',
grant => ['ALL PRIVILEGES'],
sql => '/home/backup/mysql/mydb/backup.gz',
import_cat_cmd => 'zcat',
import_timeout => 900
}Il file SQL verrà caricato solo una volta e non a ogni esecuzione, a meno che non venga utilizzato force_sql => true.
Gestione della configurazione
In questo esempio, abbiamo usato manage_config_file => true con override_options per strutturare le nostre linee di configurazione che in seguito verranno espulse da Puppet. Qualsiasi modifica al file manifest rifletterà solo il contenuto del file di configurazione MySQL di destinazione. Questo modulo non caricherà la configurazione in runtime né riavvierà il servizio MySQL dopo aver inserito le modifiche nel file di configurazione. È responsabilità dell'amministratore di sistema riavviare il servizio per attivare le modifiche.
Per aggiungere una configurazione MySQL personalizzata, possiamo inserire file aggiuntivi in "includedir", predefinito su /etc/mysql/conf.d. Questo ci consente di sovrascrivere le impostazioni o aggiungerne altre, il che è utile se non usi override_options nella classe mysql::server. L'utilizzo del modello Puppet è altamente raccomandato qui. Posiziona il file di configurazione personalizzato nella directory del modello del modulo (impostazione predefinita , /etc/puppetlabs/code/environments/production/modules/mysql/templates) e quindi aggiungi le seguenti righe nel manifest:
# Loads /etc/puppetlabs/code/environments/production/modules/mysql/templates/my-custom-config.cnf.erb into /etc/mysql/conf.d/my-custom-config.cnf
file { '/etc/mysql/conf.d/my-custom-config.cnf':
ensure => file,
content => template('mysql/my-custom-config.cnf.erb')
}Puppet vs ClusterControl
Sapevi che puoi anche automatizzare la distribuzione di MySQL o MariaDB Galera utilizzando ClusterControl? Puoi utilizzare il modulo ClusterControl Puppet per installarlo o semplicemente scaricandolo dal nostro sito Web.
Rispetto a ClusterControl, puoi aspettarti le seguenti differenze:
- Un po' di curva di apprendimento per comprendere le sintassi, la formattazione e le strutture dei pupazzi prima di poter scrivere manifest.
- Il manifesto deve essere testato regolarmente. È molto comune ricevere un errore di compilazione sul codice soprattutto se il catalogo viene applicato per la prima volta.
- Il burattino presume che i codici siano idempotenti. La condizione di test/verifica/verifica rientra nella responsabilità dell'autore per evitare di incasinare un sistema in esecuzione.
- Il pupazzo richiede un agente sul nodo gestito.
- Incompatibilità a ritroso. Alcuni vecchi moduli non funzionerebbero correttamente sulla nuova versione.
- Il monitoraggio del database/dell'host deve essere impostato separatamente.
La procedura guidata di distribuzione di ClusterControl guida il processo di distribuzione:
In alternativa, è possibile utilizzare l'interfaccia della riga di comando ClusterControl denominata "s9s" per ottenere risultati simili. Il comando seguente crea un cluster Percona XtraDB a tre nodi (a condizione che tutti i nodi siano configurati senza password):
$ s9s cluster --create \
--cluster-type=galera \
--nodes='192.168.0.21;192.168.0.22;192.168.0.23' \
--vendor=percona \
--cluster-name='Percona XtraDB Cluster 5.7' \
--provider-version=5.7 \
--db-admin='root' \
--db-admin-passwd='$ecR3t^word' \
--logInoltre, ClusterControl supporta l'implementazione di sistemi di bilanciamento del carico per Galera Cluster - HAproxy, ProxySQL e MariaDB MaxScale - insieme a un indirizzo IP virtuale (fornito da Keepalived) per eliminare ogni singolo punto di errore per il servizio database.
Dopo l'implementazione, i nodi/cluster possono essere monitorati e gestiti completamente da ClusterControl, incluso il rilevamento automatico degli errori, il ripristino automatico, la gestione del backup, la gestione del bilanciamento del carico, il collegamento di slave asincroni, la gestione della configurazione e così via. Tutti questi sono raggruppati in un unico prodotto. In media, il tuo cluster di database sarà attivo e funzionante entro 30 minuti. Ciò di cui ha bisogno è solo SSH senza password per i nodi di destinazione.
Puoi anche importare un cluster Galera già in esecuzione, distribuito da Puppet (o qualsiasi altro mezzo) in ClusterControl per potenziare il tuo cluster con tutte le fantastiche funzionalità che ne derivano. L'edizione community (gratuita per sempre!) offre distribuzione e monitoraggio.
Nel prossimo episodio, ti guideremo attraverso la distribuzione del bilanciamento del carico MySQL utilizzando Puppet. Resta sintonizzato!
