So konfigurieren Sie eine Cluster-zu-Cluster-Replikation für Percona XtraDB-Cluster oder MariaDB-Cluster

In einem früheren Blog haben wir eine neue ClusterControl 1.7.4-Funktion namens Cluster-zu-Cluster-Replikation angekündigt. Es automatisiert den gesamten Prozess der Einrichtung eines DR-Clusters außerhalb Ihres primären Clusters mit dazwischenliegender Replikation. Nähere Informationen entnehmen Sie bitte dem oben genannten Blogeintrag.

In diesem Blog werfen wir nun einen Blick darauf, wie diese neue Funktion für einen vorhandenen Cluster konfiguriert wird. Für diese Aufgabe gehen wir davon aus, dass Sie ClusterControl installiert haben und der Master-Cluster damit bereitgestellt wurde.

Anforderungen für das Mastercluster

Der Master-Cluster muss einige Anforderungen erfüllen, damit er funktioniert:

Percona XtraDB Cluster Version 5.6.x und höher oder MariaDB Galera Cluster Version 10.x und höher.
GTID aktiviert.
Binäre Protokollierung auf mindestens einem Datenbankknoten aktiviert.
Die Backup-Anmeldedaten müssen im Master-Cluster und im Slave-Cluster gleich sein.

Master-Cluster vorbereiten

Der Master-Cluster muss auf die Verwendung dieser neuen Funktion vorbereitet werden. Es erfordert eine Konfiguration sowohl von der ClusterControl- als auch von der Datenbankseite.

ClusterControl-Konfiguration

Überprüfen Sie im Datenbankknoten die Anmeldedaten des Sicherungsbenutzers, die in /etc/my.cnf.d/secrets-backup.cnf (für RedHat-basierte Betriebssysteme) oder in /etc/mysql/secrets-backup gespeichert sind .cnf (für Debian-basierte Betriebssysteme).

$ cat /etc/my.cnf.d/secrets-backup.cnf

# Security credentials for backup.

[mysqldump]

user=backupuser

password=cYj0GFBEdqdreZEl



[xtrabackup]

user=backupuser

password=cYj0GFBEdqdreZEl



[mysqld]

wsrep_sst_auth=backupuser:cYj0GFBEdqdreZEl

Bearbeiten Sie im ClusterControl-Knoten die Konfigurationsdatei /etc/cmon.d/cmon_ID.cnf (wobei ID die Cluster-ID-Nummer ist) und stellen Sie sicher, dass sie dieselben Anmeldeinformationen enthält, die in secrets-backup gespeichert sind. cnf.

$ cat /etc/cmon.d/cmon_8.cnf

backup_user=backupuser

backup_user_password=cYj0GFBEdqdreZEl

basedir=/usr

cdt_path=/

cluster_id=8

...

Jede Änderung an dieser Datei erfordert einen Neustart des cmon-Dienstes:

$ service cmon restart

Überprüfen Sie die Datenbank-Replikationsparameter, um sicherzustellen, dass GTID und Binärprotokollierung aktiviert sind.

Datenbankkonfiguration

Überprüfen Sie im Datenbankknoten die Datei /etc/my.cnf (für RedHat-basierte Betriebssysteme) oder /etc/mysql/my.cnf (für Debian-basierte Betriebssysteme), um die Konfiguration in Bezug auf zu sehen Replikationsprozess.

Percona XtraDB:

$ cat /etc/my.cnf

# REPLICATION SPECIFIC

server_id=4002

binlog_format=ROW

log_bin = /var/lib/mysql-binlog/binlog

log_slave_updates = ON

gtid_mode = ON

enforce_gtid_consistency = true

relay_log = relay-log

expire_logs_days = 7

MariaDB Galera-Cluster:

$ cat /etc/my.cnf

# REPLICATION SPECIFIC

server_id=9000

binlog_format=ROW

log_bin = /var/lib/mysql-binlog/binlog

log_slave_updates = ON

relay_log = relay-log

wsrep_gtid_domain_id=9000

wsrep_gtid_mode=ON

gtid_domain_id=9000

gtid_strict_mode=ON

gtid_ignore_duplicates=ON

expire_logs_days = 7

Wenn Sie die Konfigurationsdateien überprüfen, können Sie überprüfen, ob sie in der ClusterControl-Benutzeroberfläche aktiviert sind. Gehen Sie zu ClusterControl -> Cluster auswählen -> Knoten. Dort sollten Sie so etwas haben:

Die im ersten Knoten hinzugefügte „Master“-Rolle bedeutet, dass die binäre Protokollierung aktiviert ist.

Binäre Protokollierung aktivieren

Wenn Sie die binäre Protokollierung nicht aktiviert haben, gehen Sie zu ClusterControl -> Cluster auswählen -> Knoten -> Knotenaktionen -> Binäre Protokollierung aktivieren.

Dann müssen Sie die Aufbewahrung des Binärprotokolls und den Speicherpfad angeben es. Sie sollten auch angeben, ob ClusterControl den Datenbankknoten nach der Konfiguration neu starten soll, oder ob Sie es vorziehen, ihn selbst neu zu starten.

Beachten Sie, dass das Aktivieren der binären Protokollierung immer einen Neustart des Datenbankdienstes erfordert .

Erstellen des Slave-Clusters aus der ClusterControl-GUI

Um einen neuen Slave-Cluster zu erstellen, gehen Sie zu ClusterControl -> Cluster auswählen -> Cluster-Aktionen -> Slave-Cluster erstellen.

Der Slave-Cluster kann durch Streaming von Daten aus dem aktuellen Master-Cluster oder erstellt werden indem Sie ein vorhandenes Backup verwenden.

In diesem Abschnitt müssen Sie auch den Master-Knoten des aktuellen Clusters auswählen aus der die Daten repliziert werden.

Wenn Sie zum nächsten Schritt gehen, müssen Sie User, Key or angeben Passwort und Port, um sich per SSH mit Ihren Servern zu verbinden. Außerdem benötigen Sie einen Namen für Ihr Slave-Cluster und wenn Sie möchten, dass ClusterControl die entsprechende Software und Konfigurationen für Sie installiert.

Nachdem Sie die SSH-Zugangsinformationen eingerichtet haben, müssen Sie den Datenbankanbieter und definieren Version, Datadir, Datenbankport und das Admin-Passwort. Stellen Sie sicher, dass Sie den gleichen Anbieter/die gleiche Version und die gleichen Anmeldeinformationen wie vom Master-Cluster verwenden. Sie können auch angeben, welches Repository verwendet werden soll.

In diesem Schritt müssen Sie dem neuen Slave-Cluster Server hinzufügen. Für diese Aufgabe können Sie sowohl die IP-Adresse als auch den Hostnamen jedes Datenbankknotens eingeben.

Sie können den Status der Erstellung Ihres neuen Slave-Clusters von überwachen ClusterControl-Aktivitätsmonitor. Sobald die Aufgabe abgeschlossen ist, können Sie den Cluster auf dem Hauptbildschirm von ClusterControl sehen.

Verwalten der Cluster-zu-Cluster-Replikation mithilfe der ClusterControl-GUI

Jetzt haben Sie Ihre Cluster-zu-Cluster-Replikation eingerichtet und ausgeführt, es gibt verschiedene Aktionen, die Sie mit ClusterControl für diese Topologie ausführen können.

Aktiv-Aktiv-Cluster konfigurieren

Wie Sie sehen können, ist der Slave-Cluster standardmäßig im schreibgeschützten Modus eingerichtet. Es ist möglich, das Read-Only-Flag auf den Knoten nacheinander über die ClusterControl-Benutzeroberfläche zu deaktivieren, aber denken Sie daran, dass Active-Active-Clustering nur empfohlen wird, wenn Anwendungen nur disjunkte Datensätze auf beiden Clustern berühren, da MySQL/MariaDB dies nicht tut Konflikterkennung oder -lösung anbieten.

Um den Read-Only-Modus zu deaktivieren, gehen Sie zu ClusterControl -> Select Slave Cluster -> Knoten. Wählen Sie in diesem Abschnitt jeden Knoten aus und verwenden Sie die Option „Schreibgeschützt deaktivieren“.

Neuaufbau eines Slave-Clusters

Um Inkonsistenzen zu vermeiden, wenn Sie einen Slave-Cluster neu erstellen möchten, muss dies ein Read-Only-Cluster sein, das bedeutet, dass alle Knoten im Read-Only-Modus sein müssen.

Gehen Sie zu ClusterControl -> Select Slave Cluster -> Nodes -> Choose the Mit dem Master-Cluster verbundener Knoten -> Knotenaktionen -> Replikations-Slave neu erstellen.

Topologieänderungen

Wenn Sie die folgende Topologie haben:

Und aus irgendeinem Grund möchten Sie den Replikationsknoten im Master ändern Cluster. Es ist möglich, den vom Slave-Cluster verwendeten Master-Knoten zu einem anderen Master-Knoten im Master-Cluster zu ändern.

Um als Master-Knoten betrachtet zu werden, muss die binäre Protokollierung aktiviert sein .

Gehen Sie zu ClusterControl -> Select Slave Cluster -> Nodes -> Choose the Mit dem Master-Cluster verbundener Knoten -> Knotenaktionen -> Slave stoppen/Slave starten.

Replikations-Slave stoppen/starten

Mit ClusterControl können Sie Replikations-Slaves auf einfache Weise stoppen und starten.

Gehen Sie zu ClusterControl -> Select Slave Cluster -> Nodes -> Choose the Mit dem Master-Cluster verbundener Knoten -> Knotenaktionen -> Slave stoppen/Slave starten.

Replikations-Slave zurücksetzen

Mit dieser Aktion können Sie den Replikationsprozess mit RESET SLAVE oder RESET SLAVE ALL zurücksetzen. Der Unterschied zwischen ihnen besteht darin, dass RESET SLAVE keine Replikationsparameter wie Master-Host, Port und Anmeldeinformationen ändert. Um diese Informationen zu löschen, müssen Sie RESET SLAVE ALL verwenden, das die gesamte Replikationskonfiguration entfernt, sodass bei Verwendung dieses Befehls die Cluster-zu-Cluster-Replikationsverbindung zerstört wird.

Bevor Sie diese Funktion verwenden, müssen Sie den Replikationsprozess stoppen (siehe vorherige Funktion).

Gehen Sie zu ClusterControl -> Select Slave Cluster -> Nodes -> Choose the Mit dem Master-Cluster verbundener Knoten -> Knotenaktionen -> Slave zurücksetzen/Alle Slaves zurücksetzen.

Cluster-zu-Cluster-Replikation mit der ClusterControl-CLI verwalten

Im vorherigen Abschnitt konnten Sie sehen, wie Sie eine Cluster-zu-Cluster-Replikation mithilfe der ClusterControl-Benutzeroberfläche verwalten. Sehen wir uns nun an, wie Sie dies über die Befehlszeile tun.

Hinweis:Wie bereits zu Beginn dieses Blogs erwähnt, gehen wir davon aus, dass Sie ClusterControl installiert haben und der Master-Cluster damit bereitgestellt wurde.

Erstelle den Slave-Cluster

Sehen wir uns zunächst einen Beispielbefehl zum Erstellen eines Slave-Clusters mithilfe der ClusterControl-CLI an:

$ s9s cluster --create --cluster-name=Galera1rep --cluster-type=galera  --provider-version=10.4 --nodes="192.168.100.166;192.168.100.167;192.168.100.168"  --os-user=root --os-key-file=/root/.ssh/id_rsa --db-admin=root --db-admin-passwd=xxxxxxxx --vendor=mariadb --remote-cluster-id=11 --log

Nun haben Sie Ihren Prozess zum Erstellen von Slaves ausgeführt, sehen wir uns jeden verwendeten Parameter an:

Cluster:Zum Auflisten und Bearbeiten von Clustern.
Erstellen:Erstellen und installieren Sie einen neuen Cluster.
Cluster-Name:Der Name des neuen Slave-Clusters.
Clustertyp:Der Typ des zu installierenden Clusters.
Provider-Version:Die Software-Version.
Nodes:Liste der neuen Nodes im Slave-Cluster.
Os-user:Der Benutzername für die SSH-Befehle.
Os-key-file:Die Schlüsseldatei, die für die SSH-Verbindung verwendet werden soll.
Db-admin:Der Benutzername des Datenbankadministrators.
Db-admin-passwd:Das Passwort für den Datenbankadministrator.
Remote-cluster-id:Master-Cluster-ID für die Cluster-zu-Cluster-Replikation.
Log:Jobmeldungen abwarten und überwachen.

Mit dem Flag --log können Sie die Protokolle in Echtzeit sehen:

Verifying job parameters.

Checking ssh/sudo on 3 hosts.

All 3 hosts are accessible by SSH.

192.168.100.166: Checking if host already exists in another cluster.

192.168.100.167: Checking if host already exists in another cluster.

192.168.100.168: Checking if host already exists in another cluster.

192.168.100.157:3306: Binary logging is enabled.

192.168.100.158:3306: Binary logging is enabled.

Creating the cluster with the following:

wsrep_cluster_address = 'gcomm://192.168.100.166,192.168.100.167,192.168.100.168'

Calling job: setupServer(192.168.100.166).

192.168.100.166: Checking OS information.

…

Caching config files.

Job finished, all the nodes have been added successfully.

Aktiv-Aktiv-Cluster konfigurieren

Wie Sie bereits gesehen haben, können Sie den Nur-Lesen-Modus im neuen Cluster deaktivieren, indem Sie ihn in jedem Knoten deaktivieren. Sehen wir uns also an, wie das über die Befehlszeile geht.

$ s9s node --set-read-write --nodes="192.168.100.166" --cluster-id=16 --log

Sehen wir uns jeden Parameter an:

Knoten:Zur Behandlung von Knoten.
Set-read-write:Versetzt den Knoten in den Read-Write-Modus.
Knoten:Der Knoten, an dem er geändert werden soll.
Cluster-id:Die ID des Clusters, in dem sich der Knoten befindet.

Dann sehen Sie:

192.168.100.166:3306: Setting read_only=OFF.

Neuaufbau eines Slave-Clusters

Sie können einen Slave-Cluster mit dem folgenden Befehl neu aufbauen:

$ s9s replication --stage --master="192.168.100.157:3306" --slave="192.168.100.166:3306" --cluster-id=19 --remote-cluster-id=11 --log

Die Parameter sind:

Replikation:Zur Überwachung und Steuerung der Datenreplikation.
Stufe:Stufe/Wiederaufbau eines Replikations-Slaves.
Master:Der Replikations-Master im Master-Cluster.
Slave:Der Replikations-Slave im Slave-Cluster.
Cluster-id:Die Slave-Cluster-ID.
Remote-cluster-id:Die Master-Cluster-ID.
Log:Jobmeldungen abwarten und überwachen.

Das Auftragsprotokoll sollte diesem ähneln:

Rebuild replication slave 192.168.100.166:3306 from master 192.168.100.157:3306.

Remote cluster id = 11

Shutting down Galera Cluster.

192.168.100.166:3306: Stopping node.

192.168.100.166:3306: Stopping mysqld (timeout=60, force stop after timeout=true).

192.168.100.166: Stopping MySQL service.

192.168.100.166: All processes stopped.

192.168.100.166:3306: Stopped node.

192.168.100.167:3306: Stopping node.

192.168.100.167:3306: Stopping mysqld (timeout=60, force stop after timeout=true).

192.168.100.167: Stopping MySQL service.

192.168.100.167: All processes stopped.

…

192.168.100.157:3306: Changing master to 192.168.100.166:3306.

192.168.100.157:3306: Changed master to 192.168.100.166:3306

192.168.100.157:3306: Starting slave.

192.168.100.157:3306: Collecting replication statistics.

192.168.100.157:3306: Started slave successfully.

192.168.100.166:3306: Starting node

Writing file '192.168.100.167:/etc/mysql/my.cnf'.

Writing file '192.168.100.167:/etc/mysql/secrets-backup.cnf'.

Writing file '192.168.100.168:/etc/mysql/my.cnf'.

Topologieänderungen

Sie können Ihre Topologie ändern, indem Sie einen anderen Knoten im Master-Cluster verwenden, von dem die Daten repliziert werden, sodass Sie beispielsweise Folgendes ausführen können:

$ s9s replication --failover --master="192.168.100.161:3306" --slave="192.168.100.163:3306" --cluster-id=10 --remote-cluster-id=9 --log

Überprüfen wir die verwendeten Parameter.

Replikation:Zur Überwachung und Steuerung der Datenreplikation.
Failover:Übernehmen Sie die Rolle des Masters von einem ausgefallenen/alten Master.
Master:Der neue Replikations-Master im Master-Cluster.
Slave:Der Replikations-Slave im Slave-Cluster.
Cluster-id:Die ID des Slave-Clusters.
Remote-Cluster-id:Die ID des Master-Clusters.
Log:Jobmeldungen abwarten und überwachen.

Sie werden dieses Protokoll sehen:

192.168.100.161:3306 belongs to cluster id 9.

192.168.100.163:3306: Changing master to 192.168.100.161:3306

192.168.100.163:3306: My master is 192.168.100.160:3306.

192.168.100.161:3306: Sanity checking replication master '192.168.100.161:3306[cid:9]' to be used by '192.168.100.163[cid:139814070386698]'.

192.168.100.161:3306: Executing GRANT REPLICATION SLAVE ON *.* TO 'cmon_replication'@'192.168.100.163'.

Setting up link between  192.168.100.161:3306 and 192.168.100.163:3306

192.168.100.163:3306: Stopping slave.

192.168.100.163:3306: Successfully stopped slave.

192.168.100.163:3306: Setting up replication using MariaDB GTID: 192.168.100.161:3306->192.168.100.163:3306.

192.168.100.163:3306: Changing Master using master_use_gtid=slave_pos.

192.168.100.163:3306: Changing master to 192.168.100.161:3306.

192.168.100.163:3306: Changed master to 192.168.100.161:3306

192.168.100.163:3306: Starting slave.

192.168.100.163:3306: Collecting replication statistics.

192.168.100.163:3306: Started slave successfully.

192.168.100.160:3306: Flushing logs to update 'SHOW SLAVE HOSTS'

Replikations-Slave stoppen/starten

Sie können die Replikation der Daten vom Master-Cluster auf diese Weise stoppen:

$ s9s replication --stop --slave="192.168.100.166:3306" --cluster-id=19 --log

Sie werden Folgendes sehen:

192.168.100.166:3306: Ensuring the datadir '/var/lib/mysql' exists and is owned by 'mysql'.

192.168.100.166:3306: Stopping slave.

192.168.100.166:3306: Successfully stopped slave.

Und jetzt können Sie es erneut starten:

$ s9s replication --start --slave="192.168.100.166:3306" --cluster-id=19 --log

Sie werden also sehen:

192.168.100.166:3306: Ensuring the datadir '/var/lib/mysql' exists and is owned by 'mysql'.

192.168.100.166:3306: Starting slave.

192.168.100.166:3306: Collecting replication statistics.

192.168.100.166:3306: Started slave successfully.

Nun überprüfen wir die verwendeten Parameter.

Replikation:Zur Überwachung und Steuerung der Datenreplikation.
Stop/Start:Damit der Slave die Replikation stoppt/startet.
Slave:Der Replikations-Slave-Knoten.
Cluster-id:Die ID des Clusters, in dem sich der Slave-Knoten befindet.
Log:Jobmeldungen abwarten und überwachen.

Replikations-Slave zurücksetzen

Mit diesem Befehl können Sie den Replikationsprozess mit RESET SLAVE oder RESET SLAVE ALL zurücksetzen. Weitere Informationen zu diesem Befehl finden Sie im vorherigen Abschnitt über die ClusterControl-Benutzeroberfläche.

Bevor Sie diese Funktion verwenden, müssen Sie den Replikationsprozess stoppen (siehe vorherigen Befehl).

SLAVE ZURÜCKSETZEN:

$ s9s replication --reset  --slave="192.168.100.166:3306" --cluster-id=19 --log

Das Protokoll sollte wie folgt aussehen:

192.168.100.166:3306: Ensuring the datadir '/var/lib/mysql' exists and is owned by 'mysql'.

192.168.100.166:3306: Executing 'RESET SLAVE'.

192.168.100.166:3306: Command 'RESET SLAVE' succeeded.

SLAVE ALLE ZURÜCKSETZEN:

$ s9s replication --reset --force  --slave="192.168.100.166:3306" --cluster-id=19 --log

Und dieses Protokoll sollte sein:

192.168.100.166:3306: Ensuring the datadir '/var/lib/mysql' exists and is owned by 'mysql'.

192.168.100.166:3306: Executing 'RESET SLAVE /*!50500 ALL */'.

192.168.100.166:3306: Command 'RESET SLAVE /*!50500 ALL */' succeeded.

Sehen wir uns die verwendeten Parameter für RESET SLAVE und RESET SLAVE ALL an.

Replikation:Zur Überwachung und Steuerung der Datenreplikation.
Reset:Setzt den Slave-Knoten zurück.
Force:Mit diesem Flag verwenden Sie den Befehl RESET SLAVE ALL auf dem Slave-Knoten.
Slave:Der Replikations-Slave-Knoten.
Cluster-id:Die Slave-Cluster-ID.
Log:Jobmeldungen abwarten und überwachen.

Fazit

Mit dieser neuen ClusterControl-Funktion können Sie schnell eine Cluster-zu-Cluster-Replikation erstellen und diese auf einfache und benutzerfreundliche Weise verwalten. Diese Umgebung verbessert Ihre Datenbank-/Cluster-Topologie und wäre nützlich für einen Notfallwiederherstellungsplan, eine Testumgebung und noch mehr Optionen, die im Übersichtsblog erwähnt werden.