Im vorherigen Blogbeitrag haben wir Ihnen einige grundlegende Schritte zum Bereitstellen und Verwalten eines eigenständigen MySQL-Servers sowie zum Einrichten der MySQL-Replikation mit dem MySQL-Puppet-Modul gezeigt. In dieser zweiten Installation werden wir ähnliche Schritte behandeln, aber jetzt mit einem Galera-Cluster-Setup.
Galera-Cluster mit Puppe
Wie Sie vielleicht wissen, hat Galera Cluster drei Hauptanbieter:
- MySQL Galera-Cluster (Codership)
- Percona XtraDB-Cluster (Percona)
- MariaDB Cluster (von MariaDB in MariaDB Server eingebettet)
Eine gängige Praxis bei Galera-Cluster-Bereitstellungen besteht darin, eine zusätzliche Schicht auf dem Datenbank-Cluster für Lastausgleichszwecke zu haben. Dies ist jedoch ein komplexer Vorgang, der einen eigenen Beitrag verdient.
In Puppet Forge sind eine Reihe von Puppet-Modulen verfügbar, die zum Bereitstellen eines Galera-Clusters verwendet werden können. Hier sind einige davon..
- puppetlabs/mysql - nur MariaDB Galera
- fraenki/galera - Percona XtraDB Cluster und MySQL Galera von Codership
- edetecd/mariadb - Nur MariaDB-Cluster
- filiadata/percona - Percona XtraDB-Cluster
Da unser Ziel darin besteht, ein grundlegendes Verständnis dafür zu vermitteln, wie man ein Manifest schreibt und die Bereitstellung für den Galera-Cluster automatisiert, werden wir die Bereitstellung des MariaDB Galera-Clusters mit dem Modul puppetlabs/mysql behandeln. Für andere Module können Sie jederzeit einen Blick in die jeweilige Dokumentation werfen, um Anweisungen oder Tipps zur Installation zu erhalten.
Im Galera-Cluster ist die Reihenfolge beim Starten des Knotens entscheidend. Um einen neuen Cluster ordnungsgemäß zu starten, muss ein Knoten als Referenzknoten eingerichtet werden. Dieser Knoten wird mit einer leeren Host-Verbindungszeichenfolge (gcomm://) gestartet, um den Cluster zu initialisieren. Dieser Vorgang wird Bootstrapping genannt.
Nach dem Start wird der Knoten zu einer primären Komponente und die verbleibenden Knoten können mit dem standardmäßigen mysql-Startbefehl gestartet werden (systemctl start mysql oder service mysql start ) gefolgt von einer vollständigen Host-Verbindungszeichenfolge (gcomm://db1,db2,db3). Bootstrapping ist nur erforderlich, wenn keine primäre Komponente von einem anderen Knoten im Cluster gehalten wird (überprüfen Sie dies mit wsrep_cluster_status Status).
Der Cluster-Startvorgang muss explizit vom Benutzer durchgeführt werden. Das Manifest selbst darf den Cluster NICHT bei der ersten Ausführung starten (beliebigen Knoten booten), um das Risiko eines Datenverlusts zu vermeiden. Denken Sie daran, dass das Puppet-Manifest so geschrieben werden muss, dass es so idempotent wie möglich ist. Das Manifest muss sicher sein, damit es mehrmals ausgeführt werden kann, ohne die bereits laufenden MySQL-Instanzen zu beeinträchtigen. Das bedeutet, dass wir uns hauptsächlich auf die Repository-Konfiguration, die Paketinstallation, die vorlaufende Konfiguration und die SST-Benutzerkonfiguration konzentrieren müssen.
Die folgenden Konfigurationsoptionen sind für Galera obligatorisch:
- wsrep_on :Ein Flag zum Aktivieren der Writeset-Replikations-API für Galera Cluster (nur MariaDB).
- wsrep_cluster_name :Der Clustername. Muss auf allen Knoten identisch sein, die Teil desselben Clusters sind.
- wsrep_cluster_address :Die Galera-Kommunikationsverbindungszeichenfolge mit dem Präfix gcomm:// und gefolgt von der Knotenliste, getrennt durch Kommas. Eine leere Knotenliste bedeutet Cluster-Initialisierung.
- wsrep_provider :Der Pfad, in dem sich die Galera-Bibliothek befindet. Der Pfad kann je nach Betriebssystem unterschiedlich sein.
- bind_address :MySQL muss von außen erreichbar sein, daher ist der Wert '0.0.0.0' obligatorisch.
- wsrep_sst_method :Für MariaDB ist die bevorzugte SST-Methode mariabackup.
- wsrep_sst_auth :MySQL-Benutzer und -Passwort (durch Doppelpunkt getrennt) zum Durchführen der Snapshot-Übertragung. Üblicherweise geben wir einen Benutzer an, der die Möglichkeit hat, eine vollständige Sicherung zu erstellen.
- wsrep_node_address :IP-Adresse für Galera-Kommunikation und Replikation. Verwenden Sie Puppet Factor, um die richtige IP-Adresse auszuwählen.
- wsrep_node_name :Hostname des FQDN. Verwenden Sie den Puppet-Faktor, um den richtigen Hostnamen auszuwählen.
Bei Debian-basierten Bereitstellungen versucht das Nachinstallationsskript, den MariaDB-Server automatisch zu starten. Wenn wir wsrep_on=ON (Flag zum Aktivieren von Galera) mit der vollständigen Adresse in wsrep_cluster_address konfiguriert haben Variable, würde der Server während der Installation fehlschlagen. Dies liegt daran, dass es keine primäre Komponente hat, mit der eine Verbindung hergestellt werden kann.
Um einen Cluster in Galera ordnungsgemäß zu starten, muss der erste Knoten (genannt Bootstrap-Knoten) mit einer leeren Verbindungszeichenfolge (wsrep_cluster_address =gcomm://) konfiguriert werden, um den Knoten als primäre Komponente zu initiieren. Sie können auch das bereitgestellte Bootstrap-Skript namens galera_new_cluster ausführen, das im Grunde etwas Ähnliches im Hintergrund macht.
Bereitstellung des Galera-Clusters (MariaDB)
Die Bereitstellung des Galera-Clusters erfordert eine zusätzliche Konfiguration auf der APT-Quelle, um das bevorzugte MariaDB-Versions-Repository zu installieren.
Beachten Sie, dass die Galera-Replikation in MariaDB Server eingebettet ist und keine zusätzlichen Pakete installiert werden müssen. Allerdings ist ein zusätzliches Flag erforderlich, um Galera mit wsrep_on=ON zu aktivieren. Ohne dieses Flag fungiert MariaDB als eigenständiger Server.
In unserer Debian-basierten Umgebung kann die Option wsrep_on nur im Manifest angezeigt werden, nachdem die erste Bereitstellung abgeschlossen ist (wie weiter unten in den Bereitstellungsschritten gezeigt). Dadurch soll sichergestellt werden, dass der erste Start als eigenständiger Server für Puppet fungiert, um den Knoten bereitzustellen, bevor er vollständig bereit ist, ein Galera-Knoten zu sein.
Beginnen wir damit, den Inhalt des Manifests wie folgt vorzubereiten (modifizieren Sie den Abschnitt mit den globalen Variablen, falls erforderlich):
# 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';
}An dieser Stelle bedarf es einer kleinen Erklärung. „wsrep_node_address“ muss auf dieselbe IP-Adresse verweisen wie die, die in wsrep_cluster_address deklariert wurde. In dieser Umgebung haben unsere Hosts zwei Netzwerkschnittstellen und wir möchten die zweite Schnittstelle (namens enp0s8) für die Galera-Kommunikation verwenden (mit der das Netzwerk 192.168.0.0/24 verbunden ist). Aus diesem Grund verwenden wir Puppet-Faktor, um die Informationen vom Knoten abzurufen und auf die Konfigurationsoption anzuwenden. Der Rest ist ziemlich selbsterklärend.
Führen Sie auf jedem MariaDB-Knoten den folgenden Befehl aus, um den Katalog als Root-Benutzer anzuwenden:
$ puppet agent -tDer Katalog wird zur Installation und Vorbereitung auf jeden Knoten angewendet. Sobald dies erledigt ist, müssen wir die folgende Zeile in unser Manifest unter dem Abschnitt „override_options => mysqld“ hinzufügen:
'wsrep_on' => 'ON',Das Obige erfüllt die Galera-Anforderung für MariaDB. Wenden Sie dann den Katalog erneut auf jeden MariaDB-Knoten an:
$ puppet agent -tSobald dies erledigt ist, können wir unseren Cluster booten. Da dies ein neuer Cluster ist, können wir einen beliebigen Knoten als Referenzknoten, auch bekannt als Bootstrap-Knoten, auswählen. Lassen Sie uns db1.local (192.168.0.161) auswählen und den folgenden Befehl ausführen:
$ galera_new_cluster #db1Sobald der erste Knoten gestartet ist, können wir den verbleibenden Knoten mit dem Standard-Startbefehl starten (ein Knoten nach dem anderen):
$ systemctl restart mariadb #db2 and db3Werfen Sie nach dem Start einen Blick in das MySQL-Fehlerprotokoll unter /var/log/mysql/error.log und vergewissern Sie sich, dass das Protokoll mit der folgenden Zeile endet:
2019-06-10 4:11:10 2 [Note] WSREP: Synchronized with group, ready for connectionsDas Obige sagt uns, dass die Knoten mit der Gruppe synchronisiert sind. Wir können dann den Status mit dem folgenden Befehl überprüfen:
$ mysql -uroot -e 'show status like "wsrep%"'Stellen Sie auf allen Knoten sicher, dass die wsrep_cluster_size , wsrep_cluster_status und wsrep_local_state_comment sind 3, "Primär" bzw. "Synchronisiert".
MySQL-Verwaltung
Dieses Modul kann verwendet werden, um eine Reihe von MySQL-Verwaltungsaufgaben durchzuführen...
- Konfigurationsoptionen (ändern, anwenden, benutzerdefinierte Konfiguration)
- Datenbankressourcen (Datenbank, Benutzer, Zuschüsse)
- Sicherung (erstellen, planen, Benutzer sichern, speichern)
- einfache Wiederherstellung (nur mysqldump)
- Installation/Aktivierung von Plugins
Dienststeuerung
Der sicherste Weg bei der Bereitstellung von Galera-Clustern mit Puppet besteht darin, alle Dienststeuerungsvorgänge manuell durchzuführen (überlassen Sie dies nicht Puppet). Für einen einfachen rollierenden Neustart des Clusters würde der Standarddienstbefehl ausreichen. Führen Sie den folgenden Befehl Knoten für Knoten aus.
$ systemctl restart mariadb # Systemd
$ service mariadb restart # SysVinitFalls jedoch eine Netzwerkpartitionierung stattfindet und keine primäre Komponente verfügbar ist (überprüfen Sie dies mit wsrep_cluster_status ), muss der aktuellste Knoten gebootet werden, um den Cluster ohne Datenverlust wieder betriebsbereit zu machen. Sie können die im obigen Bereitstellungsabschnitt gezeigten Schritte ausführen. Um mehr über den Bootstrapping-Prozess mit Beispielszenarien zu erfahren, haben wir dies ausführlich in diesem Blogbeitrag behandelt, How to Bootstrap MySQL or MariaDB Galera Cluster.
Datenbankressource
Verwenden Sie die mysql::db-Klasse, um sicherzustellen, dass eine Datenbank mit zugehörigen Benutzern und Berechtigungen vorhanden ist, zum Beispiel:
# make sure the database and user exist with proper grant
mysql::db { 'mynewdb':
user => 'mynewuser',
password => 'passw0rd',
host => '192.168.0.%',
grant => ['SELECT', 'UPDATE']
} Die obige Definition kann jedem Knoten zugewiesen werden, da jeder Knoten in einem Galera-Cluster ein Master ist.
Sichern und Wiederherstellen
Da wir einen SST-Benutzer mit der xtrabackup-Klasse erstellt haben, konfiguriert Puppet alle Voraussetzungen für den Backup-Job – Erstellen des Backup-Benutzers, Vorbereiten des Zielpfads, Zuweisen von Besitz und Berechtigungen, Einrichten des Cron-Jobs und Einrichten der zu verwendenden Backup-Befehlsoptionen im bereitgestellten Backup-Skript. Jeder Knoten wird mit zwei Backup-Jobs konfiguriert (einer für wöchentliche vollständige und einer für tägliche inkrementelle) standardmäßig auf 23:05 Uhr, wie Sie der crontab-Ausgabe entnehmen können:
$ 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` --backupWenn Sie stattdessen mysqldump planen möchten, verwenden Sie die Klasse mysql::server::backup, um die Sicherungsressourcen vorzubereiten. Angenommen, wir haben die folgende Deklaration in unserem 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'
}Das Obige weist Puppet an, das Backup-Skript unter /usr/local/sbin/mysqlbackup.sh zu konfigurieren und es jeden Tag um 23:30 Uhr zu planen. Wenn Sie eine sofortige Sicherung erstellen möchten, rufen Sie einfach auf:
$ mysqlbackup.shFür die Wiederherstellung unterstützt das Modul nur die Wiederherstellung mit der Sicherungsmethode mysqldump, indem die SQL-Datei mithilfe der Klasse mysql::db direkt in die Datenbank importiert wird, zum Beispiel:
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
}Die SQL-Datei wird nur einmal und nicht bei jedem Durchlauf geladen, es sei denn, force_sql => true wird verwendet.
Konfigurationsverwaltung
In diesem Beispiel haben wir manage_config_file => true mit override_options verwendet, um unsere Konfigurationszeilen zu strukturieren, die später von Puppet ausgegeben werden. Jede Änderung an der Manifestdatei spiegelt nur den Inhalt der Ziel-MySQL-Konfigurationsdatei wider. Dieses Modul lädt weder die Konfiguration in die Laufzeit noch startet es den MySQL-Dienst neu, nachdem es die Änderungen in die Konfigurationsdatei gepusht hat. Es liegt in der Verantwortung des Systemadministrators, den Dienst neu zu starten, um die Änderungen zu aktivieren.
Um eine benutzerdefinierte MySQL-Konfiguration hinzuzufügen, können wir zusätzliche Dateien in "includedir" platzieren, standardmäßig /etc/mysql/conf.d. Dadurch können wir Einstellungen überschreiben oder zusätzliche hinzufügen, was hilfreich ist, wenn Sie override_options nicht in der Klasse mysql::server verwenden. Die Verwendung der Puppet-Vorlage wird hier dringend empfohlen. Platzieren Sie die benutzerdefinierte Konfigurationsdatei im Modulvorlagenverzeichnis (standardmäßig , /etc/puppetlabs/code/environments/production/modules/mysql/templates) und fügen Sie dann die folgenden Zeilen in das Manifest ein:
# 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
Wussten Sie, dass Sie die Bereitstellung von MySQL oder MariaDB Galera auch automatisieren können, indem Sie ClusterControl verwenden? Sie können das ClusterControl Puppet-Modul verwenden, um es zu installieren, oder es einfach von unserer Website herunterladen.
Im Vergleich zu ClusterControl können Sie folgende Unterschiede erwarten:
- Eine kleine Lernkurve, um Puppet-Syntaxen, -Formatierungen und -Strukturen zu verstehen, bevor Sie Manifeste schreiben können.
- Manifest muss regelmäßig getestet werden. Es kommt sehr häufig vor, dass Sie einen Kompilierungsfehler im Code erhalten, besonders wenn der Katalog zum ersten Mal angewendet wird.
- Puppet geht davon aus, dass die Codes idempotent sind. Die Bedingung test/check/verify fällt in die Verantwortung des Autors, um zu vermeiden, dass ein laufendes System durcheinandergebracht wird.
- Puppet erfordert einen Agenten auf dem verwalteten Knoten.
- Abwärtsinkompatibilität. Einige alte Module liefen auf der neuen Version nicht korrekt.
- Datenbank-/Hostüberwachung muss separat eingerichtet werden.
Der Bereitstellungsassistent von ClusterControl leitet den Bereitstellungsprozess:
Alternativ können Sie die ClusterControl-Befehlszeilenschnittstelle namens „s9s“ verwenden, um ähnliche Ergebnisse zu erzielen. Der folgende Befehl erstellt einen Percona XtraDB-Cluster mit drei Knoten (vorausgesetzt, dass für alle Knoten zuvor kein Kennwort konfiguriert wurde):
$ 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' \
--logDarüber hinaus unterstützt ClusterControl die Bereitstellung von Load Balancern für Galera Cluster – HAproxy, ProxySQL und MariaDB MaxScale – zusammen mit einer virtuellen IP-Adresse (bereitgestellt von Keepalived), um jeden einzelnen Fehlerpunkt für Ihren Datenbankdienst zu eliminieren.
Nach der Bereitstellung können Knoten/Cluster von ClusterControl überwacht und vollständig verwaltet werden, einschließlich automatischer Fehlererkennung, automatischer Wiederherstellung, Backup-Management, Load-Balancer-Management, Anhängen asynchroner Slaves, Konfigurationsmanagement und so weiter. All dies ist in einem Produkt gebündelt. Im Durchschnitt ist Ihr Datenbank-Cluster innerhalb von 30 Minuten betriebsbereit. Was es braucht, ist nur passwortloses SSH zu den Zielknoten.
Sie können auch einen bereits laufenden Galera-Cluster importieren, der von Puppet (oder auf andere Weise) in ClusterControl bereitgestellt wird, um Ihren Cluster mit all den damit verbundenen coolen Funktionen aufzuladen. Die Community Edition (für immer kostenlos!) bietet Bereitstellung und Überwachung.
In der nächsten Folge führen wir Sie durch die Bereitstellung des MySQL-Load-Balancers mit Puppet. Bleiben Sie dran!
