MySQL Serie 14 MySQL Hochverfügbarkeitsimplementierung

1. MHA

Durch die Überwachung des Masterknotens kann ein automatisches Failover auf andere Slaveknoten erreicht werden. Durch die Beförderung eines Slaveknotens zu einem neuen Masterknoten ist basierend auf der Master-Slave-Replikation auch die Zusammenarbeit der Clients erforderlich. Derzeit unterstützt MHA hauptsächlich eine Architektur mit einem Master und mehreren Slaves. Um MHA aufzubauen, muss ein Replikationscluster mindestens drei Datenbankserver haben, einen Master und zwei Slaves, d. h. einer fungiert als Master, einer als Standby-Master und der andere als Slave.

1. Funktionsprinzip von MHA

• Speichern von Binärprotokollereignissen von einem abgestürzten Master
• Identifizieren Sie den Slave mit dem neuesten Update
• Wenden Sie das Differenz-Relay-Protokoll auf andere Slaves an
• Anwenden von binären Protokollereignissen, die vom Master gespeichert wurden
• Einen Sklaven zum neuen Meister befördern

2. MHA-Software

Die MHA-Software besteht aus zwei Teilen: dem Manager-Toolkit und dem Node-Toolkit;

Das Manager-Toolkit umfasst hauptsächlich die folgenden Tools:

masterha_check_ssh Überprüfen Sie die SSH-Konfiguration von MHAmasterha_check_repl Überprüfen Sie den MySQL-Replikationsstatusmasterha_manger Starten Sie MHAmasterha_check_status Überprüfen Sie den aktuellen MHA-Laufstatusmasterha_master_monitor Überprüfen Sie, ob der Master ausgefallen istmasterha_master_switch Failover (automatisch oder manuell)masterha_conf_host Fügen Sie konfigurierte Serverinformationen hinzu oder löschen Sie sie

Node-Toolkit: Diese Tools werden normalerweise durch das MHA-Manager-Skript ausgelöst und erfordern keine menschliche Bedienung.

save_binary_logs speichert und kopiert das Binärprotokoll des Masters. apply_diff_relay_logs identifiziert differenzielle Relay-Protokollereignisse und wendet die differenziellen Ereignisse auf andere Slaves an. filter_mysqlbinlog entfernt unnötige ROLLBACK-Ereignisse (MHA verwendet dieses Tool nicht mehr). purge_relay_logs löscht Relay-Protokolle (blockiert den SQL-Thread nicht).

Tipp: Um Datenverluste durch Hardwareschäden und Ausfallzeiten der Masterdatenbank zu minimieren, wird empfohlen, bei der Konfiguration von MHA die halbsynchrone Replikation von MySQL 5.5 zu konfigurieren.

Benutzerdefinierte Erweiterungen:

secondary_check_script: Überprüfen Sie die Verfügbarkeit des Masters über mehrere Netzwerkroutenmaster_ip_ailover_script: Aktualisieren Sie die von Anwendungen verwendete Master-IPshutdown_script: Erzwingen Sie das Herunterfahren des Masterknotensreport_script: Senden Sie einen Berichtinit_conf_load_script: Laden Sie die anfänglichen Konfigurationsparametermaster_ip_online_change_script: Aktualisieren Sie die IP-Adresse des Masterknotens

Download-Adresse: https://code.google.com/archive/p/mysql-master-ha/downloads

3. Umsetzung von MHA

Umgebung: Basierend auf der Schlüsselauthentifizierung, siehe: https://www.cnblogs.com/L-dongf/p/9058265.html, die Zeit muss synchronisiert werden, ausführen: ntpdate cn.pool.ntp.org

1) Manager-Knoten

[root@manager ~]# yum install mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-node-0.56-0.el6.noarch.rpm -y #MHA-Software installieren [root@manager ~]# scp mha4mysql-node-0.56-0.el6.noarch.rpm 192.168.0.7:
[root@manager ~]# scp mha4mysql-node-0.56-0.el6.noarch.rpm 192.168.0.8:
[root@manager ~]# scp mha4mysql-node-0.56-0.el6.noarch.rpm 192.168.0.9:
[root@manager ~]# mkdir /etc/mha/
[root@manager ~]# vim /etc/mha/cluster1.cnf
[Serverstandard]
Benutzer=mhauser
Passwort=mhapass
manager_workdir=/data/mastermha/cluster1/
manager_log=/data/mastermha/cluster1/manager.log
remote_workdir=/data/mastermha/cluster1/
ssh_user=root
repl_user=Erneuter
repl_password=replpass
ping_interval=1 #Einmal pro Sekunde prüfen [server1]
Hostname = 192.168.0.7
candidates_master=1 #Kann der Masterknoten werden [server2]
Hostname = 192.168.0.8
candidates_master=1 #Kann der Masterknoten werden [server3]
Hostname = 192.168.0.9
[root@manager ~]# masterha_check_ssh --conf=/etc/mha/cluster1.cnf #SSH-Schlüsselumgebung prüfen. Alle SSH-Verbindungstests wurden erfolgreich bestanden.
[root@manager ~]# masterha_check_repl --conf=/etc/mha/cluster1.cnf #MySQL-Status prüfen. Die Integrität der MySQL-Replikation ist in Ordnung.
[root@manager ~]# yum install screen -y
[root@manager ~]# screen -S mha #mha ist ein Prozess, der im Vordergrund arbeitet und nicht in Echtzeit über das Terminal erkannt werden kann [root@manager ~]# masterha_manager --conf=/etc/mha/cluster1.cnf #Überwachung starten

2) Masterknoten

[root@master ~]# yum install mha4mysql-node-0.56-0.el6.noarch.rpm -y #Node-Paket installieren [root@master ~]# vim /etc/my.cnf
[mysqld]
server_id=1
log_bin
binlog_format=Zeile
skip_name_resolve
[root@master ~]# systemctl starte mariadb
MariaDB [(keine)]> GRANT REPLICATION SLAVE ON *.* TO repluser@'192.168.0.%' IDENTIFIED BY 'replpass'; #Erstellen Sie ein Master-Slave-Replikationskonto. Dieses Konto kann für jeden Knoten erstellt werden, der zum Master wechselt. MariaDB [(keine)]> SHOW MASTER LOGS;
+--------------------+-----------+
| Protokollname | Dateigröße |
+--------------------+-----------+
| mariadb-bin.000001 | 401 |
+--------------------+-----------+
MariaDB [(keine)]> GRANT ALL ON *.* TO mhauser@'192.168.0.%' IDENTIFIED BY 'mhapass'; #Erstellen Sie einen mha-Verwaltungsbenutzer und stellen Sie sicher, dass alle Knoten dieses Konto synchronisiert haben

3) Slave-Knoten

[root@slave ~]# yum installiere mha4mysql-node-0.56-0.el6.noarch.rpm -y
[root@slave ~]# vim /etc/my.cnf
[mysqld]
schreibgeschützt=1
log_bin
binlog_format=Zeile
server_id=2
relay_log_purge=0
skip_name_resolve=1
[root@slave ~]# systemctl starte mariadb
MariaDB [(keine)]> GRANT REPLICATION SLAVE ON *.* TO repluser@'192.168.0.%' IDENTIFIZIERT DURCH 'replpass';
MariaDB [(keine)]> ÄNDERN SIE MASTER IN
    -> MASTER_HOST='192.168.0.7', #Der Masterknoten ist 0.7
    -> MASTER_USER='repluser',
    -> MASTER_PASSWORD='replpass',
    -> MASTER_PORT=3306,
    -> MASTER_LOG_FILE='mariadb-bin.000001',
    -> MASTER_LOG_POS=401,
    -> MASTER_CONNECT_RETRY=10;
MariaDB [(keine)]> START SLAVE;

4) Slave2-Knoten

[root@slave2 ~]# yum installiere mha4mysql-node-0.56-0.el6.noarch.rpm -y
[root@slave2 ~]# vim /etc/my.cnf
[mysqld]
server_id=3
schreibgeschützt=1
relay_log_purge=0
skip_name_resolve=1
[root@slave2 ~]# systemctl starte mariadb
MariaDB [(keine)]> ÄNDERN SIE MASTER IN
    -> MASTER_HOST='192.168.0.7',
    -> MASTER_USER='repluser',
    -> MASTER_PASSWORD='replpass',
    -> MASTER_PORT=3306,
    -> MASTER_LOG_FILE='mariadb-bin.000001',
    -> MASTER_LOG_POS=401,
    -> MASTER_CONNECT_RETRY=10;
MariaDB [(keine)]> START SLAVE;

4) Testen

Wenn der Master-Dienst stoppt: [root@master ~]# systemctl stop mariadb

Führen Sie den MariaDB-Befehl [(none)]> SHOW SLAVE STATUS\G auf Slave2 aus und sehen Sie sich die Master_Server_Id an: 2

Beschreibung: Umschaltung erfolgreich

4. Die MHA-Überwachung ist wieder online

Reparieren Sie den ausgefallenen Master, bringen Sie ihn wieder online und konfigurieren Sie ihn manuell als Slave des aktuellen Masterknotens [root@master ~]# systemctl start mariadb
MariaDB [(keine)]> ÄNDERN SIE MASTER IN
    -> MASTER_HOST='192.168.0.8', #Der Master-Host ist 0.8
    -> MASTER_USER='repluser',
    -> MASTER_PASSWORD='replpass',
    -> MASTER_PORT=3306,
    -> MASTER_LOG_FILE='mariadb-bin.000001',
    -> MASTER_LOG_POS=482,
    -> MASTER_CONNECT_RETRY=10;
MariaDB [(keine)]> START SLAVE;

Verwaltungsknoten:
[root@manager ~]# Bildschirm -S mha
[root@manager ~]# masterha_manager --conf=/etc/mha/cluster1.cnf #Überwachung neu starten

2. Galera-Cluster

Galera Cluster: Ein MySQL-Cluster mit integriertem Galera-Plug-in ist eine neue Art von Hochverfügbarkeitslösung ohne Datenfreigabe und mit hoher Redundanz. Derzeit gibt es zwei Versionen von Galera Cluster, Percona Xtradb Cluster und MariaDB Cluster. Galera selbst verfügt über Multi-Master-Funktionen, d. h. es verwendet eine Multi-Master-Cluster-Architektur. Es handelt sich um eine Hochverfügbarkeitslösung, die sowohl robust ist als auch eine hervorragende Leistung in Bezug auf Datenkonsistenz, Integrität und hohe Leistung bietet.

Die drei Knoten bilden einen Cluster. Anders als bei der üblichen Master-Slave-Architektur können sie alle Masterknoten sein. Die drei Knoten sind gleich, was als Multi-Master-Architektur bezeichnet wird. Wenn ein Client Daten schreiben oder lesen möchte, spielt es keine Rolle, mit welcher Instanz er sich verbindet. Die gelesenen Daten sind dieselben. Nach dem Schreiben auf einen bestimmten Knoten synchronisiert der Cluster die neuen Daten mit anderen Knoten. Diese Architektur teilt keine Daten und ist eine hochredundante Architektur.

Merkmal:

• Multi-Master-Architektur: Ein echter Mehrpunkt-Lese-/Schreibcluster, bei dem die Lese- und Schreibdaten jederzeit auf dem neuesten Stand sind;
• Synchrone Replikation: Daten werden ohne Verzögerung zwischen verschiedenen Knoten im Cluster synchronisiert. Bei einem Datenbankausfall gehen keine Daten verloren.
• Gleichzeitige Replikation: Beim Anwenden von Daten von einem Slave-Knoten wird die parallele Ausführung unterstützt, was zu einer besseren Leistung führt;
• Umschalten bei Fehlern: Wenn ein Datenbankfehler auftritt, ist das Umschalten einfach, da Mehrpunktschreiben unterstützt wird.
• Hot-Plug: Sollte es während des Betriebs zu einem Datenbankabsturz kommen, ist die Ausfallzeit sehr kurz, sofern das Überwachungsprogramm dies schnell genug erkennt. Bei einem Knotenausfall hat der Knoten selbst nur sehr geringe Auswirkungen auf den Cluster.
• Automatisches Klonen von Knoten: Beim Hinzufügen neuer Knoten oder Herunterfahren zu Wartungszwecken müssen inkrementelle Daten oder Basisdaten nicht manuell gesichert werden. Galera Cluster ruft automatisch Online-Knotendaten ab, und der Cluster wird schließlich konsistent.

Funktionsprinzip:

Siehe die offizielle Dokumentation:

http://galeracluster.com/documentation-webpages/galera-documentation.pdf

http://galeracluster.com/documentation-webpages/index.html

https://mariadb.com/kb/en/mariadb/erste-schritte-mit-mariadb-galera-cluster/

Es werden mindestens drei Knoten benötigt. Das MariaDB-Server-Paket kann nicht installiert werden. Es muss ein spezielles Paket installiert werden.

Implementierung des Galera-Clusters

Quelle des Open-Source-Mirrors von Tsinghua: https://mirrors.tuna.tsinghua.edu.cn/mariadb/mariadb-5.5.60/yum/centos7-amd64/

# vim /etc/yum.repos.d/mariadb_galera_server.repo
[Mariadb]
Name=mariadb_galera_server.repo
Basis-URL = https://mirrors.tuna.tsinghua.edu.cn/mariadb/mariadb-5.5.60/yum/centos7-amd64/
gpgcheck=0
# yum installiere MariaDB-Galera-server -y

1) mysql-1

[root@mysql-1 ~]# vim /etc/my.cnf.d/server.cnf
[Galerie]
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://192.168.0.7,192.168.0.8,192.168.0.9" #Definieren Sie alle IPs hier binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
Bindeadresse = 0.0.0.0
wsrep_cluster_name = "mein_wsrep_cluster"
wsrep_node_name = "Knoten1"
wsrep_node_address = "192.168.0.7"

2) MySQL-2

[root@mysql-2 ~]# vim /etc/my.cnf.d/server.cnf
[Galerie]
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://192.168.0.7,192.168.0.8,192.168.0.9"
binlog_format=Zeile
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
Bindeadresse = 0.0.0.0
wsrep_cluster_name = "mein_wsrep_cluster"
wsrep_node_name = "Knoten2"
wsrep_node_address = "192.168.0.8"

3) MySQL-3

[root@mysql-3 ~]# vim /etc/my.cnf.d/server.cnf
[Galerie]
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://192.168.0.7,192.168.0.8,192.168.0.9"
binlog_format=Zeile
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
Bindeadresse = 0.0.0.0
wsrep_cluster_name = "mein_wsrep_cluster"
wsrep_node_name = "Knoten3"
wsrep_node_address = "192.168.0.9"

4) Starten

[root@mysql-1 ~]# /etc/init.d/mysql start --wsrep-new-cluster #Fügen Sie diesen Parameter für den ersten Start hinzu [root@mysql-2 ~]# /etc/init.d/mysql start #Nachfolgende Dienste können direkt gestartet werden [root@mysql-3 ~]# /etc/init.d/mysql start

5) Testen

​Wenn die Datenbank auf einem beliebigen Knoten ausgeführt wird, werden die anderen Knoten synchron ausgeführt. Wenn derselbe Datensatz gleichzeitig ausgeführt wird, ist nur ein Knoten erfolgreich.

6) Überprüfen Sie den Arbeitsstatus

MariaDB [(keine)]> VARIABLEN WIE 'wsrep_%' ANZEIGEN\G
MariaDB [(keine)]> STATUS ANZEIGEN WIE 'wsrep_%'\G
MariaDB [(keine)]> STATUS ANZEIGEN WIE 'wsrep_cluster_size';
+--------------------+----------+
| Variablenname | Wert |
+--------------------+----------+
| wsrep_cluster_size | 3 | #Im Cluster sind drei Knoten online+--------------------+-------+

Damit ist der Artikel zur MySQL-Reihe 14: MySQL-Hochverfügbarkeitsimplementierung abgeschlossen. Weitere Informationen zur MySQL-Hochverfügbarkeitsimplementierung finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!