Schritte zum Erstellen der MHA-Architekturbereitstellung in MySQL

Inhaltsverzeichnis

1. Einführung in die MAH-Architektur
2. Anwendbare Szenarien
3. Funktionsprinzip von MHA
4. Zusammensetzung von MHA
5. MHA-Funktionen

Bereitstellung der MHA-Architektur

1. Topologiediagramm
2: Datenbankinstallation
3: Datenbankkonfiguration Master-Slave-Synchronisation
4: MHA-Software installieren
Fünf: Konfigurieren Sie die kennwortlose Authentifizierung
6. MHA konfigurieren
7. Gesundheitscheck
8: Zeigen Sie die VIP-Adresse von Master1 an
9. Starten Sie MHA und überprüfen Sie den Status

Fehlersimulation und -behebung

1. Fehlersimulation
2. Fehlerbehebung

MAH

1. Einführung in die MAH-Architektur

MHA (Master High Availability) ist derzeit eine relativ ausgereifte Lösung für MySQL-Hochverfügbarkeit. Es wurde vom japanischen Unternehmen Youshimaton entwickelt und ist eine hervorragende Hochverfügbarkeitssoftware für Failover und Master-Slave-Promotion in MySQL-Hochverfügbarkeitsumgebungen. Während des MySQL-Failover-Prozesses kann MHA den Datenbank-Failover-Vorgang automatisch innerhalb von 0 bis 30 Sekunden abschließen und während des Failover-Prozesses die Konsistenz der Datenbank weitestgehend sicherstellen, um eine wirklich hohe Verfügbarkeit zu erreichen.
MHA besteht aus zwei Teilen: MHA Manager (Verwaltungsknoten) und MHANode (Datenknoten). MHA Manager kann unabhängig auf einer separaten Maschine bereitgestellt werden, um mehrere Master-Slave-Cluster zu verwalten, oder er kann auf einem Slave bereitgestellt werden. Wenn der Master ausfällt, kann er den Slave mit den neuesten Daten automatisch zum neuen Master befördern und dann alle anderen Slaves zum neuen Master umleiten. Der gesamte Failover-Prozess ist für die Anwendung völlig transparent.

2. Anwendbare Szenarien

Derzeit unterstützt MHA hauptsächlich die Architektur eines Masters und mehrerer Slaves. Um MHA zu erstellen, 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. Aus Kostengründen hat Taobao auf dieser Basis Änderungen vorgenommen. Derzeit unterstützt der von Taobao entwickelte TMHA bereits einen Master und einen Slave.

3. Funktionsprinzip von MHA

1. Speichern Sie das Binärprotokollereignis vom abgestürzten Master.

2. Identifizieren Sie den Slave mit dem neuesten Update;

3. Wenden Sie das Differenz-Relay-Protokoll auf andere Slaves an.

4. Wenden Sie die vom Master gespeicherten Binärprotokollereignisse an.

5. Befördern Sie einen Slave zum neuen Master;

6. Stellen Sie sicher, dass sich andere Slaves zur Replikation mit dem neuen Master verbinden.

4. Zusammensetzung von MHA

Manager-Toolkit
Knoten-Toolkit

1: Manager-Toolkit

masterha_check_ssh: Überprüfen Sie die SSH-Konfiguration von MHA
masterha_check_repl: MySQL-Replikationsstatus prüfen
masterha_manager: MHA starten
masterha_check_status: Überprüfen Sie den aktuellen MHA-Laufstatus
masterha_master_monitor: erkennt, ob der Master ausgefallen ist
masterha_master_switch: steuert Failover (automatisch oder manuell)
masterha_conf_host: konfigurierte Serverinformationen hinzufügen oder löschen

2: Knoten-Toolkit

Wird normalerweise durch das MHA Manager-Skript ausgelöst, es ist kein manueller Vorgang erforderlich

save_binary_logs: Speichern und kopieren Sie die Binärprotokolle des Masters
apply_diff_relay_logs: Identifizieren Sie die Zwischenprotokollzeiten der Unterschiede und wenden Sie sie auf andere Slaves an
filter_mysqlbinlog: unnötige ROOLBACK-Ereignisse entfernen (veraltet)
purge_relay_logs: Relay-Protokolle löschen (ohne den SQL-Thread zu blockieren)

5. MHA-Funktionen

Während des automatischen Failover-Prozesses versucht MHA, das Binärprotokoll vom ausgefallenen primären Server zu speichern, um Datenverlust möglichst zu vermeiden.
Durch die Verwendung einer halbsynchronen Replikation kann das Risiko eines Datenverlusts erheblich verringert werden
Derzeit unterstützt MHA eine Ein-Master-Mehrere-Slave-Architektur mit mindestens drei Servern, d. h. einem Master und zwei Slaves.

Bereitstellung der MHA-Architektur

1. Topologiediagramm

Bildbeschreibung hier einfügen

2: Datenbankinstallation

MySQL-Version 5.6.36, cmake-Version 2.8.6

1: Installieren Sie die von der Kompilierung abhängige Umgebung

[root@master ~]# yum -y install ncurses-devel gcc-c++ perl-Modul-Install

2. Installieren Sie die Kompilierungssoftware gmake

[root@master ~]# tar zxvf cmake-2.8.6.tar.gz
[root@master ~]# cd cmake-2.8.6
[root@master cmake-2.8.6]# ./konfigurieren
[root@master cmake-2.8.6]# gmake && gmake installieren

3: MySQL-Datenbank installieren

[root@master ~]# tar -zxvf mysql-5.6.36.tar.gz
[root@master ~]# cd mysql-5.6.36
[root@master mysql-5.6.36]# cmake -DCMAKE_INSTALL_PREFIX=/usr/local/mysql -DDEFAULT_CHARSET=utf8 -DDEFAULT_COLLATION=utf8_general_ci -DWITH_EXTRA_CHARSETS=alle -DSYSCONFDIR=/etc
[root@master mysql-5.6.36]# make && make install
[root@master mysql-5.6.36]# cp support-files/my-default.cnf /etc/my.cnf
[root@master mysql-5.6.36]# cp support-files/mysql.server /etc/rc.d/init.d/mysqld
[root@master ~]# chmod +x /etc/rc.d/init.d/mysqld
[root@master ~]# chkconfig --add mysqld
[root@master ~]# echo "PATH=$PATH:/usr/local/mysql/bin" >> /etc/profile
[root@master ~]# Quelle /etc/Profil
chown -R mysql.mysql /usr/local/mysql groupadd mysql
[root@master ~]# useradd -M -s /sbin/nologin mysql -g mysql
[root@master ~]# chown -R mysql.mysql /usr/local/mysql
[root@master ~]# mkdir -p /data/mysql
[root@master ~]# /usr/local/mysql/scripts/mysql_install_db --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --user=mysql

4: Ändern Sie die Hauptkonfigurationsdatei des Masters /etc/my.cnf

Löschen Sie alle ursprünglichen Konfigurationen

[root@master ~]# vi /etc/my.cnf
[Kunde]
Port = 3306
Socket = /usr/local/mysql/mysql.sock

[mysql]
Port = 3306
Socket = /usr/local/mysql/mysql.sock

[mysqld]
Benutzer = MySQL
basedir = /usr/local/mysql
Datenverzeichnis = /usr/local/mysql/data
Port = 3306
pid-Datei = /usr/local/mysql/mysqld.pid
Socket = /usr/local/mysql/mysql.sock
Server-ID = 1
log_bin = Master-Bin
log-slave-updates = wahr

sql_mode=KEINE_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES,KEIN_AUTO_CREATE_USER,KEIN_AUTO_VALUE_ON_ZERO,KEINE_ZERO_IN_DATE,KEIN_ZERO_DATE,FEHLER_FÜR_DIVISION_DURCH_ZERO,PIPES_AS_CONCAT,ANSI_QUOTES

Die anderen beiden Slave-Datenbanken

Die Server-ID der drei Server darf nicht gleich sein, die anderen sind gleich und können normal geschrieben werden

Server-ID = 2
log_bin = Master-Bin
Relais-Protokoll = Relais-Protokoll-Bin 
Relais-Log-Index = Slave-Relay-Bin.Index

Server-ID = 3
log_bin = Master-Bin
Relais-Protokoll = Relais-Protokoll-Bin 
Relais-Log-Index = Slave-Relay-Bin.Index

5: Erstellen Sie für jede der drei Datenbanken zwei Softlinks. Die Softlinks sind für HMA-Dienste.

[root@master ~]# ln -s /usr/local/mysql/bin/mysql /usr/sbin/
[root@master ~]# ln -s /usr/local/mysql/bin/mysqlbinlog /usr/sbin/

6: MySQL auf drei Datenbanken starten

[root@master ~]# /usr/local/mysql/bin/mysqld_safe --user=mysql &
[root@master ~]# service mysqld restart 
MySQL wird heruntergefahren.. ERFOLGREICH! 
MySQL wird gestartet. ERFOLGREICH!

3: Datenbankkonfiguration Master-Slave-Synchronisation

Anmeldung bei der Datenbank

[root@master ~]#mysql

1: Autorisieren Sie zwei Benutzer auf allen Datenbankknoten, einen für die Slave-Synchronisierung und den anderen für die Manager-Verwendung

mysql> gewähre Replikations-Slave auf *.* an 'myslave'@'20.0.0.%', identifiziert durch '123';
mysql> gewähre 'mha'@'20.0.0.%', identifiziert durch 'manager', alle Privilegien für *.*;
mysql> Berechtigungen leeren;

2: Theoretisch müssen die folgenden drei Autorisierungen nicht hinzugefügt werden. Beim Durchführen der Fallexperimentumgebung wurde jedoch beim Überprüfen des MySQL-Master-Slaves über MHA ein Fehler gemeldet, der meldete, dass die beiden Slave-Datenbanken über den Hostnamen keine Verbindung zur Master-Datenbank herstellen konnten. Daher wurden allen Datenbanken die folgenden Autorisierungen hinzugefügt.

mysql> gewähre 'mha'@'master', identifiziert durch 'manager', alle Privilegien für *.*;
mysql> gewähre 'mha'@'slave1', identifiziert durch 'manager', alle Privilegien auf *.*;
mysql> gewähre 'mha'@'slave2', identifiziert durch 'manager', alle Privilegien auf *.*;

3: Binärdateien und Synchronisierungspunkte auf dem Master-Host anzeigen

mysql> Masterstatus anzeigen;
+-------------------+----------+--------------+------------------+-------------------+
| Datei | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------+----------+--------------+------------------+-------------------+
| master-bin.000001 | 608 | | | |
+-------------------+----------+--------------+------------------+-------------------+
1 Zeile im Satz (0,00 Sek.)

4: Führen Sie die Synchronisierung jeweils auf Slave1 und Slave2 durch

mysql> ändere Master in master_host='20.0.0.10',master_user='myslave',master_password='123',master_log_file='master-bin.000001',master_log_pos=608
mysql> Slave starten;

5: Überprüfen Sie, ob sowohl IO- als auch SQL-Threads „Ja“ sind, um anzuzeigen, ob die Synchronisierung normal ist.

mysql> Slave-Status anzeigen\G;
*************************** 1. Reihe ***************************
    Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
     Master_Host: 20.0.0.10
     Master_User: meinSlave
     Master_Port: 3306
    Verbindungswiederholung: 60
    Master_Log_File: master-bin.000001
   Read_Master_Log_Pos: 608
    Relay-Log-Datei: relay-log-bin.000002
    Relay_Log_Pos: 284
  Relay_Master_Log_File: master-bin.000001
    Slave_IO_Running: Ja
   Slave_SQL_Running: Ja
    Replicate_Do_DB: 
   Replikat_Ignorieren_DB:

Beide Slaves müssen auf Nur-Lese-Modus eingestellt sein

mysql> global schreibgeschützt auf 1 setzen;

6: Fügen Sie zwei Datensätze in die Masterdatenbank ein, um zu testen, ob sie synchronisiert sind

mysql> Datenbank test_db erstellen;
Abfrage OK, 1 Zeile betroffen (0,00 Sek.)
mysql> test_db verwenden;
Datenbank geändert
mysql> Tabelle erstellen Test (ID int);
Abfrage OK, 0 Zeilen betroffen (0,13 Sek.)
mysql> in Test(ID)-Werte einfügen (1);
Abfrage OK, 1 Zeile betroffen (0,03 Sek.)

7: Fragen Sie die beiden Slave-Bibliotheken wie unten gezeigt separat ab, um anzuzeigen, dass die Master-Slave-Synchronisierung normal ist

mysql> wähle * aus test_db.test;
+------+
|Ich würde|
+------+
| 1 |
+------+
1 Zeile im Satz (0,00 Sek.)

4: MHA-Software installieren

1: Installieren Sie die MHA-abhängige Umgebung auf allen Servern. Installieren Sie zuerst die Epel-Quelle (3+1)

[root@master ~]# cd /etc/yum.repos.d/
[root@master yum.repos.d]# ll
Gesamtdosis 20
drwxr-xr-x. 2 root root 187 Oktober 10 18:08 Backup
-rw-r--r--. 1 root root 1458 28. Dezember 23:07 CentOS7-Base-163.repo
-rw-r--r--. 1 root root 951 Dez 29 14:52 epel.repo
-rw-r--r--. 1 root root 1050 1. Nov. 04:33 epel.repo.rpmnew
-rw-r--r--. 1 Wurzel Wurzel 1149 1. Nov. 04:33 epel-testing.repo
-rw-r--r--. 1 root root 228 27. Okt. 18:43 local.repo

Drei Datenbanken plus ein MHA-Manager

[root@mha-manager ~]# yum install epel-release --nogpgcheck
[root@mha-manager ~]# yum install -y perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-ParalExtUtils-CBuilder perl-ExtUtils-MakeMaker perl-CPAN

2: Die Node-Komponente (3+1) muss zuerst auf allen Servern installiert werden

[root@mha-manager ~]# tar zxvf mha4mysql-node-0.57.tar.gz
[root@mha-manager ~]# cd mha4mysql-node-0.57
[root@mha-manager mha4mysql-node-0.57]# perl Makefile.PL
[root@mha-manager mha4mysql-node-0.57]# make && make install

3: Installieren Sie die Manager-Komponente auf mha-manager

[root@mha-manager ~]# tar zxvf mha4mysql-manager-0.57.tar.gz 
[root@mha-manager ~]# cd mha4mysql-manager-0.57/
[root@mha-manager mha4mysql-manager-0.57]# perl Makefile.PL
[root@mha-manager mha4mysql-manager-0.57]# make && make install

Nach der Installation des Managers werden mehrere Tools unter /usr/local/bin generiert

Bildbeschreibung hier einfügen

masterha_check_ssh Überprüfen Sie die SSH-Konfiguration von MHA
masterha_check_repl MySQL-Replikationsstatus prüfen
masterha_manger startet das Manager-Skript
masterha_check_status prüft den aktuellen MHA-Laufstatus
masterha_master_monitor erkennt, ob der Master ausgefallen ist
masterha_master_switch steuert Failover (automatisch oder manuell)
masterha_conf_host fügt konfigurierte Serverinformationen hinzu oder löscht sie
masterha_stop fährt den Manager herunter

Nach der Installation des Knotens werden mehrere Skripte unter /usr/local/bin generiert

Bildbeschreibung hier einfügen

save_binary_logs speichert und kopiert die Binärlogs des Masters

apply_diff_relay_logs identifiziert differentielle Relay-Log-Ereignisse und wendet die differentiellen Ereignisse auf andere Slaves an

filter_mysqlbinlog entfernt unnötige ROLLBACK-Ereignisse (MHA verwendet dieses Tool nicht mehr)

purge_relay_logs Relay-Protokolle löschen (blockiert den SQL-Thread nicht)

Fünf: Konfigurieren Sie die kennwortlose Authentifizierung

1: Konfigurieren Sie die kennwortlose Authentifizierung für alle Knoten im Manager

(1) Schlüssel generieren

[root@mha-manager ~]# ssh-keygen -t rsa # Drücken Sie weiterhin die Eingabetaste

(2) Nachdem der Schlüssel generiert wurde, wird er an die anderen drei Datenbanken gesendet

[root@mha-manager ~]# ssh-copy-id 20.0.0.10 # Eingabe: ja Passwort: 123456
[root@mha-manager ~]# ssh-copy-id 20.0.0.11
[root@mha-manager ~]# ssh-copy-id 20.0.0.12

(3) Anmeldetest

[root@mha-manager ~]# ssh [email protected]
Letzte Anmeldung: Di 29. Dez 14:52:09 2020 von 20.0.0.1
[root@master ~]# beenden
AbmeldenVerbindung zu 20.0.0.10 geschlossen.
[root@mha-manager ~]# ssh [email protected]
Letzte Anmeldung: Di 29. Dez 13:20:07 2020 von 20.0.0.1
[root@slave1 ~]# beenden
AbmeldenVerbindung zu 20.0.0.11 geschlossen.
[root@mha-manager ~]# ssh [email protected]
Letzte Anmeldung: Di 27 Okt 19:45:24 2020 von 20.0.0.1
[root@slave2 ~]# beenden
AbmeldenVerbindung zu 20.0.0.12 geschlossen.

2: Konfigurieren Sie die kennwortfreie Authentifizierung für den Datenbankknoten auf dem Master

(1) Schlüssel generieren

[root@master ~]# ssh-keygen -t rsa

(2) Nachdem der Schlüssel generiert wurde, wird er an die beiden anderen Datenbanken gesendet

[root@master ~]# ssh-copy-id 20.0.0.11
[root@master ~]# ssh-Kopie-ID 20.0.0.12

(3) Anmeldetest

[root@master ~]# ssh [email protected]
Letzte Anmeldung: Di 29. Dez 16:40:06 2020 von 20.0.0.13
[root@slave1 ~]# beenden
AbmeldenVerbindung zu 20.0.0.11 geschlossen.
[root@master ~]# ssh [email protected]
Letzte Anmeldung: Di 27 Okt 23:05:20 2020 von 20.0.0.13
[root@slave2 ~]# beenden
AbmeldenVerbindung zu 20.0.0.12 geschlossen.

3: Konfigurieren Sie die kennwortfreie Authentifizierung für den Datenbankknoten auf Slave1

(1) Schlüssel generieren

[root@slave1 ~]# ssh-keygen -t rsa

(2) Nachdem der Schlüssel generiert wurde, wird er an die beiden anderen Datenbanken gesendet

[root@slave1 ~]# ssh-Kopie-ID 20.0.0.10
[root@slave1 ~]# ssh-Kopie-ID 20.0.0.12

(3) Anmeldetest

[root@slave1 ~]# ssh [email protected]
Letzte Anmeldung: Di 29. Dez 16:39:55 2020 von 20.0.0.13
[root@master ~]# beenden
AbmeldenVerbindung zu 20.0.0.10 geschlossen.
[root@slave1 ~]# ssh [email protected]
Letzte Anmeldung: Di 27 Okt 23:14:06 2020 von 20.0.0.10
[root@slave2 ~]# beenden
AbmeldenVerbindung zu 20.0.0.12 geschlossen.

4: Konfigurieren Sie die kennwortfreie Authentifizierung für den Datenbankknoten auf Slave2

(1) Schlüssel generieren

[root@slave2 ~]# ssh-keygen -t rsa

(2) Nachdem der Schlüssel generiert wurde, wird er an die beiden anderen Datenbanken gesendet

[root@slave2 ~]# ssh-Kopie-ID 20.0.0.10
[root@slave2 ~]# ssh-Kopie-ID 20.0.0.11

(3) Anmeldetest

[root@slave2 ~]# ssh [email protected]
Letzte Anmeldung: Di 29. Dez 16:59:43 2020 von 20.0.0.11
[root@master ~]# beenden
AbmeldenVerbindung zu 20.0.0.10 geschlossen.
[root@slave2 ~]# ssh [email protected]
Letzte Anmeldung: Di 29 Dez 16:48:51 2020 von 20.0.0.10
[root@slave1 ~]# beenden
AbmeldenVerbindung zu 20.0.0.11 geschlossen.

6. MHA konfigurieren

1: Kopieren Sie die relevanten Skripte in das Verzeichnis /usr/local/bin auf dem Manager-Knoten

(1) Kopieren

[root@mha-manager ~]# cp -ra /root/mha4mysql-manager-0.57/samples/scripts/ /usr/local/bin/

(2) Nach dem Kopieren gibt es vier ausführbare Dateien

Bildbeschreibung hier einfügen

master_ip_failover #Skript zur VIP-Verwaltung beim automatischen Umschalten

master_ip_online_change #VIP-Verwaltung beim Online-Umschalten

power_manager #Skript zum Herunterfahren des Hosts nach einem Fehler

send_report #Ein Skript, das nach einem Failover einen Alarm sendet

(3) Kopieren Sie das obige automatische VIP-Verwaltungsskript in das Verzeichnis /usr/local/bin. Hier wird das Skript zur Verwaltung von VIP verwendet

[root@mha-manager-Skripte]# cp master_ip_failover /usr/local/bin/
[root@mha-manager-Skripte]# cd ..
[root@mha-manager bin]# ll
Gesamtdosis 88

Bildbeschreibung hier einfügen

2: Ändern Sie das automatische Umschaltskript

[root@mha-manager ~]# vi /usr/local/bin/master_ip_failover # Gesamten Inhalt löschen #!/usr/bin/env perl
streng verwenden;
Warnungen verwenden FATAL => 'alle';

verwenden Sie Getopt::Long;

Mein
$Befehl, $ssh_user, $orig_master_host, $orig_master_ip,
$orig_master_port, $new_master_host, $new_master_ip, $new_master_port
);
#########################################Inhaltsabschnitt hinzufügen#######################################
mein $vip = '20.0.0.200';
mein $brdc = '20.0.0.255';
mein $ifdev = "ens33";
mein $key = "1";
mein $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
mein $ssh_stop_vip = "/sbin/ifconfig ens33:$key down";
mein $exit_code = 0;
#my $ssh_start_vip = "/usr/sbin/ip-Adresse hinzufügen $vip/24 brd $brdc dev $ifdev Label $ifdev:$key;/usr/sbin/arping -q -A -c 1 -I $ifdev $vip;iptables -F;";
#my $ssh_stop_vip = "/usr/sbin/ip-Adresse del $vip/24 dev $ifdev label $ifdev:$key";
##################################################################################
GetOptions(
'Befehl=s' => \$Befehl,
'ssh_user=s' => \$ssh_user,
'orig_master_host=s' => \$orig_master_host,
'orig_master_ip=s' => \$orig_master_ip,
'orig_master_port=i' => \$orig_master_port,
'neuer_master_host=s' => \$neuer_master_host,
'neue_Master-IP=s' => \$neue_Master-IP,
'neuer_Masterport=i' => \$neuer_Masterport,
);

beenden &main();

Unterhaupt {

drucken "\n\nIM SKRIPTTEST====$ssh_stop_vip==$ssh_start_vip===\n\n";

wenn ( $command eq "stop" || $command eq "stopssh" ) {

mein $exit_code = 1;
auswerten {
print "Deaktivieren des VIP auf dem alten Master: $orig_master_host \n";
&stop_vip();
$exit_code = 0;
};
wenn ($@) {
warnen "Fehler aufgetreten: $@\n";
beenden $exit_code;
}
beenden $exit_code;
}
elsif ( $Befehl gleich "start" ) {

mein $exit_code = 10;
auswerten {
print "Aktivieren des VIP - $vip auf dem neuen Master - $new_master_host \n";
&start_vip();
$exit_code = 0;
};
wenn ($@) {
warnen $@;
beenden $exit_code;
}
beenden $exit_code;
}
elsif ( $Befehl gleich "Status" ) {
print "Überprüfe den Status des Skripts.. OK \n";
Ausgang 0;
}
anders {
&Verwendung();
Ausgang 1;
}
}
unter start_vip() {
`ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
# Ein einfacher Systemaufruf, der das VIP auf dem old_master deaktiviert
unter stop_vip() {
`ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`;
}

Unterverwendung {
drucken
"Verwendung: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=Host --orig_master_ip=IP --orig_master_port=Port --new_master_host=Host --new_master_ip=IP --new_master_port=Port\n";
}

3: Erstellen Sie das MHA-Softwareverzeichnis und kopieren Sie die Konfigurationsdatei

[root@mha-manager ~]# mkdir /etc/mha
[root@mha-manager ~]# cp mha4mysql-manager-0.57/samples/conf/app1.cnf /etc/mha
[root@mha-manager ~]# vi /etc/mha/app1.cnf
[Serverstandard]
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/manager.log
master_binlog_dir=/usr/local/mysql/data
master_ip_failover_script=/usr/local/bin/master_ip_failover
master_ip_online_change_script=/usr/local/bin/master_ip_online_change
Passwort=Manager
Benutzer=mha
Ping-Intervall = 1
remote_workdir=/tmp
repl_password=123
repl_user=meinSlave
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 20.0.0.11 -s 20.0.0.12
shutdown_script=""
ssh_user=root

[Server1]
Hostname = 20.0.0.10
Port = 3306
[Server2]
Hostname = 20.0.0.11
Port = 3306
Kandidat_Master = 1
check_repl_delay=0
[server3]
Hostname = 20.0.0.12
Port = 3306

7. Gesundheitscheck

1: Testen Sie die passwortlose SSH-Authentifizierung. Wenn alles normal ist, wird die Ausgabe erfolgreich sein.

[root@mha-manager ~]# masterha_check_ssh
--conf=<server_config_file> muss festgelegt sein.
[root@mha-manager ~]# masterha_check_ssh --conf=/etc/mha/app1.cnf
Di., 29. Dez. 2020, 20:19:16 - [Warnung] Globale Konfigurationsdatei /etc/masterha_default.cnf nicht gefunden. Wird übersprungen.
Di., 29. Dez. 2020, 20:19:16 - [Info] Standardkonfiguration der Anwendung wird aus /etc/mha/app1.cnf gelesen.
Di., 29. Dez. 2020, 20:19:16 - [Info] Serverkonfiguration wird aus /etc/mha/app1.cnf gelesen.
Di., 29. Dez. 2020, 20:19:16 - [Info] SSH-Verbindungstests werden gestartet.
Di, 29. Dez. 2020, 20:19:17 - [debug] 
Di., 29. Dez. 2020, 20:19:16 - [debug] Verbindung per SSH von [email protected](20.0.0.10:22) zu [email protected](20.0.0.11:22)..
Di., 29. Dez. 2020, 20:19:16 - [debug] ok.
Di., 29. Dez. 2020, 20:19:16 - [debug] Verbindung per SSH von [email protected](20.0.0.10:22) zu [email protected](20.0.0.12:22)..
Di., 29. Dez. 2020, 20:19:17 - [debug] ok.
Di., 29. Dez. 2020, 20:19:18 - [debug] 
Di., 29. Dez. 2020, 20:19:17 - [debug] Verbindung per SSH von [email protected](20.0.0.12:22) zu [email protected](20.0.0.10:22)..
Di., 29. Dez. 2020, 20:19:17 - [debug] ok.
Di., 29. Dez. 2020, 20:19:17 - [debug] Verbindung per SSH von [email protected](20.0.0.12:22) zu [email protected](20.0.0.11:22)..
Di., 29. Dez. 2020, 20:19:18 - [debug] ok.
Di., 29. Dez. 2020, 20:19:18 - [debug] 
Di., 29. Dez. 2020, 20:19:16 - [debug] Verbindung per SSH von [email protected](20.0.0.11:22) zu [email protected](20.0.0.10:22)..
Di., 29. Dez. 2020, 20:19:17 - [debug] ok.
Di., 29. Dez. 2020, 20:19:17 - [debug] Verbindung per SSH von [email protected](20.0.0.11:22) zu [email protected](20.0.0.12:22)..
Di., 29. Dez. 2020, 20:19:17 - [debug] ok.
Di., 29. Dez. 2020, 20:19:18 - [Info] Alle SSH-Verbindungstests wurden erfolgreich bestanden.

2: Testen Sie die MySQL Master-Slave-Verbindung. Abschließend erscheint die Meldung „MySQL Replication Health is OK“.

[root@mha-manager ~]# masterha_check_repl --conf=/etc/mha/app1.cnf
Di., 29. Dez. 2020, 20:30:29 - [Warnung] Globale Konfigurationsdatei /etc/masterha_default.cnf nicht gefunden. Wird übersprungen.
Di., 29. Dez. 2020, 20:30:29 - [Info] Standardkonfiguration der Anwendung wird aus /etc/mha/app1.cnf gelesen.
Di., 29. Dez. 2020, 20:30:29 - [Info] Serverkonfiguration wird aus /etc/mha/app1.cnf gelesen.
Di., 29. Dez. 2020, 20:30:29 – [Info] MHA::MasterMonitor Version 0.57.
Di 29. Dez 2020 20:30:30 - [info] GTID Failover-Modus = 0
Di 29. Dez 2020 20:30:30 - [info] Tote Server:
Di 29. Dez 2020 20:30:30 - [info] Aktive Server:
Di 29. Dez 2020 20:30:30 - [info] 20.0.0.10 (20.0.0.10:3306)
Di 29. Dez 2020 20:30:30 - [info] 20.0.0.11(20.0.0.11:3306)
Di 29. Dez 2020 20:30:30 - [info] 20.0.0.12 (20.0.0.12:3306)
Di 29. Dez 2020 20:30:30 - [info] Lebende Sklaven:
Di 29. Dez 2020 20:30:30 - [info] 20.0.0.11(20.0.0.11:3306) Version=5.6.36-log (älteste Hauptversion zwischen Slaves) log-bin: aktiviert
.......AusgelassenÜberprüfen des Status des Skripts.. OK 
Di., 29. Dez. 2020, 20:30:55 - [Info] OK.
Di., 29. Dez. 2020, 20:30:55 – [Warnung] shutdown_script ist nicht definiert.
Di., 29. Dez. 2020, 20:30:55 - [Info] Habe Exitcode 0 erhalten (Master nicht tot).

Der Zustand der MySQL-Replikation ist in Ordnung.

8: Zeigen Sie die VIP-Adresse von Master1 an

Überprüfen Sie, ob 20.0.0.200 vorhanden ist

Diese VIP-Adresse verschwindet nicht, weil der Managerknoten den MHA-Dienst stoppt

Wenn Sie mha zum ersten Mal starten, generiert die Masterdatenbank nicht automatisch eine VIP-Adresse und muss manuell aktiviert werden.

[root@master ~]# ifconfig ens33:1 20.0.0.200/24 up
[root@master ~]# IP-Adresse
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast Status UP qlen 1000
 Link/Ether 00:0c:29:8d:e2:af brd ff:ff:ff:ff:ff:ff:ff
 inet 20.0.0.10/24 brd 20.0.0.255 Bereich global ens33
  valid_lft für immer preferred_lft für immer
 inet 20.0.0.200/24 brd 20.0.0.255 Bereich global sekundär ens33:1
  valid_lft für immer preferred_lft für immer
 inet6 fe80::a6c1:f3d4:160:102a/64 Bereichslink 
  valid_lft für immer preferred_lft für immer

9. Starten Sie MHA und überprüfen Sie den Status

[root@mha-manager ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &
[1] 57152
[root@mha-manager ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:57152) läuft (0:PING_OK), Master:20.0.0.10

Fehlersimulation und -behebung

1. Fehlersimulation

1: Den Master-Server herunterfahren

[root@master ~]# pkill mysqld

2: Protokollinformationen anzeigen

[root@mha-manager ~]# cat /var/log/masterha/app1/manager.log

Master 20.0.0.10 (20.0.0.10:3306) ist ausgefallen! # 20.0.0.10 ist ausgefallen. Weitere Einzelheiten finden Sie in den MHA-Manager-Protokollen unter mha-manager:/var/log/masterha/app1/manager.log.

Automatisches (nicht interaktives) Failover gestartet.
Ungültige Master-IP-Adresse auf 20.0.0.10 (20.0.0.10:3306)
Der neueste Slave 20.0.0.11 (20.0.0.11:3306) verfügt über alle Relay-Protokolle zur Wiederherstellung.
20.0.0.11(20.0.0.11:3306) als neuer Master ausgewählt. # 20.0.0.11 wird zum primären Server 20.0.0.11(20.0.0.11:3306): OK: Alle Protokolle wurden erfolgreich angewendet.
20.0.0.11(20.0.0.11:3306): OK: Master-IP-Adresse aktiviert.
20.0.0.12(20.0.0.12:3306): Dieser Host hat die neuesten Relay-Log-Ereignisse.
Das Generieren der Relay-Diff-Dateien vom letzten Slave war erfolgreich.

3: Virtuelle Adresse anzeigen

Die virtuelle Adresse hat 20.0.0.11 erreicht

[root@slave1 ~]# IP-Adresse
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast Status UP qlen 1000
 Link/Ether 00:0c:29:49:77:39 brd ff:ff:ff:ff:ff:ff:ff
 inet 20.0.0.11/24 brd 20.0.0.255 Bereich global ens33
  valid_lft für immer preferred_lft für immer
 inet 20.0.0.200/8 brd 20.255.255.255 Bereich global ens33:1
  valid_lft für immer preferred_lft für immer
 inet6 fe80::5cbb:1621:4281:3b24/64 Bereichslink 
  valid_lft für immer preferred_lft für immer

4: Überprüfen Sie den Master-Slave-Status

Zeigen Sie die Binärdateien des Masterservers an

[root@slave1 ~]# mysql

mysql> Masterstatus anzeigen;
+-------------------+----------+--------------+------------------+-------------------+
| Datei | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------+----------+--------------+------------------+-------------------+
| master-bin.000003 | 120 | | | |
+-------------------+----------+--------------+------------------+-------------------+
1 Zeile im Satz (0,00 Sek.)

Den Status von 2 anzeigen

[root@slave2 ~]# mysql

mysql> Slave-Status anzeigen\G;
*************************** 1. Reihe ***************************
    Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
     Master_Host: 20.0.0.11
     Master_User: meinSlave
     Master_Port: 3306
    Verbindungswiederholung: 60
    Master_Log_File: master-bin.000003
   Read_Master_Log_Pos: 120
    Relay-Log-Datei: relay-log-bin.000002
    Relay_Log_Pos: 284
  Relay_Master_Log_File: master-bin.000003
    Slave_IO_Running: Ja
   Slave_SQL_Running: Ja
    Replicate_Do_DB: 
   Replikat_Ignorieren_DB:

2. Fehlerbehebung

1: Öffnen Sie die Down-Datenbank

[root@master ~]# systemctl start mysqld
[root@master ~]# systemctl status mysqld
● mysqld.service - LSB: MySQL starten und stoppen
 Geladen: geladen (/etc/rc.d/init.d/mysqld; fehlerhaft; Vendor-Vorgabe: deaktiviert)
 Aktiv: aktiv (läuft) seit 29.12.2020 21:50:03 CST; vor 25 Sek.
  Dokumentation: man:systemd-sysv-generator(8)
 Prozess: 977 ExecStart=/etc/rc.d/init.d/mysqld start (Code=beendet, Status=0/ERFOLGREICH)
 CGroup: /system.slice/mysqld.service
   ├─1026 /bin/sh /usr/local/mysql/bin/mysqld_safe --datadir=/usr/local/mysql/data --pid-file…
   └─1358 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/m

2: Führen Sie eine Master-Slave-Replikation für die ausgefallene Datenbank durch

Master-Slave-Replikation

[root@master ~]#mysql

mysql> ändere Master in master_host='20.0.0.11',master_user='myslave',master_password='123',master_log_file='master-bin.000003',master_log_pos=120; 
Abfrage OK, 0 Zeilen betroffen, 2 Warnungen (0,01 Sek.)
# 20.0.0.11 ist der Masterserver, nachdem der Masterserver heruntergefahren wurdemysql> start slave;
Abfrage OK, 0 Zeilen betroffen (0,01 Sek.)

Status anzeigen

mysql> Slave-Status anzeigen\G;
*************************** 1. Reihe ***************************
    Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
     Master_Host: 20.0.0.11
     Master_User: meinSlave
     Master_Port: 3306
    Verbindungswiederholung: 60
    Master_Log_File: master-bin.000003
   Read_Master_Log_Pos: 120
    Relay-Log-Datei:mysqld-relay-bin.000002
    Relay_Log_Pos: 284
  Relay_Master_Log_File: master-bin.000003
    Slave_IO_Running: Ja
   Slave_SQL_Running: Ja
    Replicate_Do_DB: 
   Replikat_Ignorieren_DB:

3: Ändern Sie die mha-Konfigurationsdatei

[root@mha-manager ~]# vi /etc/mha/app1.cnf

secondary_check_script=/usr/local/bin/masterha_secondary_check -s 20.0.0.10 -s 20.0.0.12
# Da 20.0.0.11 der Masterserver ist, müssen 20.0.0.10 und 20.0.0.12 als Slave-Server hinzugefügt werden [server1]
Hostname = 20.0.0.10
Kandidat_Master = 1
check_repl_delay=0
Port = 3306
[Server2]
Hostname = 20.0.0.11
Port = 3306
# Da 20.0.0.10 ausgefallen ist, wird die Datei server1 automatisch gelöscht. Fügen Sie server1 erneut hinzu und legen Sie ihn als primären Backup-Server fest. Ändern Sie server2

4: Betreten Sie die Datenbank und autorisieren Sie erneut

[root@master ~]#mysql

mysql> gewähre 'mha'@'master', identifiziert durch 'manager', alle Privilegien für *.*;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

mysql> Berechtigungen leeren;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

5: Starten Sie mha erneut

[root@mha-manager ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &
[1] 58927
[root@mha-manager ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:58927) läuft (0:PING_OK), Master:20.0.0.11

6: Überprüfen Sie das Protokoll erneut

[root@mha-manager ~]# cat /var/log/masterha/app1/manager.log
......
Di., 29. Dez. 2020, 22:16:53 - [Info] Tote Server: # Gestoppte DiensteDi., 29. Dez. 2020, 22:16:53 - [Info] Lebende Server: # Überlebende DiensteDi., 29. Dez. 2020, 22:16:53 - [Info] 20.0.0.10(20.0.0.10:3306)
Di 29. Dez 2020 22:16:53 - [info] 20.0.0.11(20.0.0.11:3306)
Di 29. Dez 2020 22:16:53 - [info] 20.0.0.12 (20.0.0.12:3306)
.......

7: In die primäre Datenbank geschriebene Daten synchronisieren und anzeigen

Weitere Datenbanken finden Sie

mysql> Datenbank erstellen ooo;
Abfrage OK, 1 Zeile betroffen (0,00 Sek.)

mysql> Datenbanken anzeigen;
+--------------------+
| Datenbank |
+--------------------+
| Informationsschema |
|mysql |
|oooo|
| Leistungsschema |
| Prüfung |
| test_db |
+--------------------+
6 Zeilen im Satz (0,00 Sek.)

Dies ist das Ende dieses Artikels über die Schritte zum Erstellen einer MHA-Architekturbereitstellung in MySQL. Weitere relevante Inhalte zum Erstellen einer MHA-Architekturbereitstellung in MySQL finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!

Das könnte Sie auch interessieren:

So verwenden Sie Python zum Sammeln von Informationen zum Bereitstellungs- und Betriebsstatus von MySQL MHA
Eine vollständige Erklärung der MySQL-Hochverfügbarkeitsarchitektur: MHA-Architektur
Detaillierte Bereitstellungsschritte für MySQL MHA-Hochverfügbarkeitskonfiguration und Failover
Zusammenfassung mehrerer Fehlerprotokolle zum Einrichten und Wechseln von MySQL MHA
Mysql GTID Mha-Konfigurationsmethode
Super-Deployment-Tutorial zur MHA-Hochverfügbarkeits-Failover-Lösung unter MySQL
MHA implementiert manuelles Umschalten der MySQL Master-Slave-Datenbank
Einführung in die Überwachung des MySQL MHA-Betriebsstatus

<<: W3C Tutorial (8): W3C XML Schema Aktivitäten

>>: Detaillierte Erklärung des einfachen Stores von Vue