Detaillierte Bereitstellungsschritte für MySQL MHA-Hochverfügbarkeitskonfiguration und Failover

Detaillierte Bereitstellungsschritte für MySQL MHA-Hochverfügbarkeitskonfiguration und Failover

1. Einführung in MHA

1. Was ist MHA?

MHA (Master High Availability) ist eine hervorragende Software für Failover und Master-Slave-Replikation in einer MySQL-Hochverfügbarkeitsumgebung.
Der Grund für die Einführung von MHA ist die Lösung des MySQL-Single-Point-Problems.
Während des MySQL-Failover-Prozesses kann MHA den Failover-Vorgang innerhalb von 0–30 Sekunden automatisch abschließen.
MHA kann während des Failover-Prozesses ein Höchstmaß an Datenkonsistenz gewährleisten, um eine wirklich hohe Verfügbarkeit zu erreichen.

2. Zusammensetzung von MHA

MHA-Knoten (Datenknoten)
MHA Node läuft auf jedem MySQL-Server.

MHA-Manager (Verwaltungsknoten)
MHA Manager kann auf einer separaten Maschine eingesetzt werden, um mehrere Master-Slave-Cluster zu verwalten. Er kann auch auf einem Slave-Knoten eingesetzt werden.
MHA Manager erkennt regelmäßig die Masterknoten im Cluster. 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.

3. Eigenschaften von MHA

  • 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. Wenn nur ein Slave das neueste Binärprotokoll erhalten hat, kann MHA das neueste Binärprotokoll auf alle anderen Slave-Server anwenden und so die Datenkonsistenz auf allen Knoten sicherstellen.
  • Derzeit unterstützt MHA eine Ein-Master-Mehrere-Slave-Architektur mit mindestens drei Servern, d. h. einem Master und zwei Slaves.

Bildbeschreibung hier einfügen

2. MySQL MHA erstellen

1. Experimentelle Ideen:

1. MHA-Architektur

1) Datenbankinstallation
2) Ein Master und zwei Slaves
3) MHA-Konstruktion

2. Fehlersimulation

1) Die Hauptdatenbank fällt aus
2) Die alternative Masterdatenbank wird zur Masterdatenbank
3) Die ursprünglich ausgefallene Master-Datenbank wird wiederhergestellt und tritt wieder MHA bei, um eine Slave-Datenbank zu werden

(II) Experimentelle Schritte

MHA-Manager-Knotenserver: CentOS7.4 (64 Bit) manager/192.168.126.10, MHA-Knoten und Manager-Komponenten installieren Master-Knotenserver: CentOS7.4 (64 Bit) mysql1/192.168.126.20, mysql5.7 installieren, MHA-Knotenkomponenten Slave1-Knotenserver: CentOS7.4 (64 Bit) mysql2/192.168.126.30, mysql5.7 installieren, MHA-Knotenkomponenten Slave2-Knotenserver: CentOS7.4 (64 Bit) mysql3/192.168.126.40, mysql5.7 installieren, MHA-Knotenkomponenten

Deaktivieren Sie die Firewall auf jedem Computer

systemctl stoppe Firewall
systemctl deaktiviert Firewall
0

1. Installieren Sie mysql15.7

Installieren Sie mysql5.7 auf den Knoten Master, Slave1 und Slave2 (Einzelheiten zur MySQL-Installation finden Sie im vorherigen Blogbeitrag).

2. Ändern Sie die Hostnamen der Knoten Master, Slave1 und Slave2

hostnamectl set-hostname Mysql1
hostnamectl set-hostname Mysql2
hostnamectl set-hostname Mysql3

Bildbeschreibung hier einfügen

3. Ändern Sie die MySQL-Hauptkonfigurationsdatei /etc/my.cnf der Knoten Master, Slave1 und Slave2
##Masterknoten##

vim /etc/meine.cnf
[mysqld]
Server-ID = 1
log_bin = Master-Bin
log-slave-updates = wahr

systemctl startet mysqld neu

Bildbeschreibung hier einfügen

##Slave1-, Slave2-Knoten##

vim /etc/meine.cnf
server-id = 2 #Die Server-IDs der drei Server können nicht gleich sein log_bin = master-bin
Relais-Protokoll = Relais-Protokoll-Bin
Relais-Log-Index = Slave-Relay-Bin.Index

systemctl startet mysqld neu

Bildbeschreibung hier einfügen

4. Erstellen Sie zwei Softlinks auf den Knoten Master, Slave1 und Slave2

ln -s /usr/local/mysql/bin/mysql /usr/sbin/
ln -s /usr/local/mysql/bin/mysqlbinlog /usr/sbin/

5. MySQL mit einem Master und zwei Slaves konfigurieren (1) Alle Datenbankknoten sind von MySQL autorisiert

mysql -uroot -p
gewähre Replikations-Slave auf *.* an 'myslave'@'192.168.126.%', identifiziert durch '123'; #Slave-Datenbanksynchronisierung verwendet alle Berechtigungen auf *.* an 'mha'@'192.168.126.%', identifiziert durch 'manager'; #Manager verwendet alle Berechtigungen auf *.* an 'mha'@'Mysql1', identifiziert durch 'manager'; #Verhindert, dass die Slave-Bibliothek über den Hostnamen eine Verbindung zur Master-Bibliothek herstellt, gewähre alle Berechtigungen auf *.* an 'mha'@'Mysql2', identifiziert durch 'manager';
Gewähren Sie 'mha'@'Mysql3', identifiziert durch 'manager', alle Berechtigungen für *.*.
Berechtigungen leeren;

Bildbeschreibung hier einfügen

(2) Zeigen Sie Binärdateien und Synchronisierungspunkte auf dem Masterknoten an
Masterstatus anzeigen;

Bildbeschreibung hier einfügen

(3) Führen Sie Synchronisierungsvorgänge an den Knoten Slave1 und Slave2 durch

Ändere den Master in master_host='192.168.126.20',master_user='myslave',master_password='123',master_log_file='master-bin.000001',master_log_pos=1747; 

Slave starten;

(4) Überprüfen Sie die Ergebnisse der Datensynchronisierung auf den Knoten Slave1 und Slave2

Slave-Status anzeigen\G		
// Stellen Sie sicher, dass sowohl der IO- als auch der SQL-Thread „Ja“ sind. Dies zeigt an, dass die Synchronisierung normal ist.
Slave_IO_Running: Ja
Slave_SQL_Running: Ja

Bildbeschreibung hier einfügen

(5) Beide Slave-Bibliotheken müssen auf Read-Only-Modus eingestellt sein:

setze global schreibgeschützt=1; 

Bildbeschreibung hier einfügen

6. MHA-Software installieren (1) MHA-abhängige Umgebung auf allen Servern installieren. Zuerst Epel-Quelle installieren

yum installiere epel-release --nogpgcheck -y
yum install -y perl-DBD-MySQL \
perl-Konfiguration-Tiny \
perl-Log-Versand \
perl-Parallel-ForkManager \
perl-ExtUtils-CBuilder \
perl-ExtUtils-MakeMaker \
perl - CPAN

(2) Installieren Sie das MHA-Softwarepaket. Auf allen Servern muss zunächst die Node-Komponente installiert werden. Das ist bei jeder Betriebssystemversion unterschiedlich. Hier muss bei CentOS7.4 die Version 0.57 gewählt werden.
Die Knotenkomponente muss zuerst auf allen Servern installiert werden und die Managerkomponente muss zuletzt auf dem MHA-Managerknoten installiert werden, da der Manager von der Knotenkomponente abhängt.

Installationspakete:

Die Node-Komponente muss auf allen Servern installiert sein

cd /opt
tar zxvf mha4mysql-node-0.57.tar.gz
cd mha4mysql-node-0.57
perl Makefile.PL
machen && machen installieren

(3) Installieren Sie die Managerkomponente auf dem MHA-Managerknoten

cd /opt
tar zxvf mha4mysql-manager-0.57.tar.gz
cd mha4mysql-manager-0.57
perl Makefile.PL
machen && machen installieren

Nach der Installation der Managerkomponente werden unter /usr/local/bin mehrere Tools generiert, darunter hauptsächlich die folgenden:

  • 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

Bildbeschreibung hier einfügen

#Nachdem die Knotenkomponente installiert wurde, werden unter /usr/local/bin mehrere Skripte generiert (diese Tools werden normalerweise durch das MHAManager-Skript ausgelöst und erfordern keine manuelle Bedienung). Die wichtigsten sind wie folgt:
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)

Bildbeschreibung hier einfügen

7. Konfigurieren der kennwortlosen Authentifizierung auf allen Servern

(1) Konfigurieren Sie die kennwortfreie Authentifizierung für alle Datenbankknoten auf dem Managerknoten

ssh-keygen -t rsa #Drücken Sie die Eingabetaste vollständig ssh-copy-id 192.168.126.20
SSH-Kopie-ID 192.168.126.30
SSH-Kopie-ID 192.168.126.40 

Bildbeschreibung hier einfügen

Bildbeschreibung hier einfügen

(2) Konfigurieren Sie die kennwortfreie Authentifizierung auf mysql1 für die Datenbankknoten mysql2 und mysql3

ssh-keygen -t rsa
SSH-Kopie-ID 192.168.126.30
SSH-Kopie-ID 192.168.126.40

(3) Konfigurieren Sie die kennwortfreie Authentifizierung auf mysql2 für die Datenbankknoten mysql1 und mysql3

ssh-keygen -t rsa
SSH-Kopie-ID 192.168.126.20
SSH-Kopie-ID 192.168.126.40

(4) Konfigurieren Sie die kennwortfreie Authentifizierung auf mysql3 für die Datenbankknoten mysql1 und mysql2

ssh-keygen -t rsa
SSH-Kopie-ID 192.168.126.20
SSH-Kopie-ID 192.168.126.30

8. Konfigurieren von MHA auf dem Managerknoten

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

cp -rp /opt/mha4mysql-manager-0.57/samples/scripts /usr/local/bin
//Nach dem Kopieren gibt es vier ausführbare Dateien ll /usr/local/bin/scripts/

master_ip_failover #Skript zur VIP-Verwaltung bei automatischer Umschaltung master_ip_online_change #VIP-Verwaltung bei Online-Umschaltung power_manager #Skript zum Herunterfahren des Hosts nach einem Fehler send_report #Skript zum Senden eines Alarms nach einem Fehler switch 

Bildbeschreibung hier einfügen

(2) Kopieren Sie das obige VIP-Verwaltungsskript für die automatische Umschaltung in das Verzeichnis /usr/local/bin. Hier wird das Skript master_ip_failover zur Verwaltung von VIP und Failover verwendet.

cp /usr/local/bin/scripts/master_ip_failover /usr/local/bin

(3) Die geänderten Inhalte sind wie folgt: (Löschen Sie die ursprünglichen Inhalte, kopieren Sie die VIP-bezogenen Parameter direkt und ändern Sie sie)

vim /usr/local/bin/master_ip_failover

#!/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#######################################
my $vip = '192.168.126.200'; #Geben Sie die Adresse von vipmy an $brdc = '192.168.126.255'; #Geben Sie die Broadcast-Adresse von vipmy an $ifdev = 'ens33'; #Geben Sie die an vipmy gebundene Netzwerkkarte an $key = '1'; #Geben Sie die Seriennummer der an vipmy gebundenen virtuellen Netzwerkkarte an $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip"; #Stellt dar, dass der Wert dieser Variable ifconfig ens33:1 192.168.126.200 ist
my $ssh_stop_vip = "/sbin/ifconfig ens33:$key down"; #Dieser Variablenwert repräsentiert ifconfig ens33:1 192.168.126.200 down
my $exit_code = 0; #Geben Sie den Exit-Statuscode als 0 an
#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 den 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";
}

Bildbeschreibung hier einfügen

(4) Erstellen Sie das MHA-Softwareverzeichnis und kopieren Sie die Konfigurationsdatei. Hier wird die Konfigurationsdatei app1.cnf zum Verwalten des MySQL-Knotenservers verwendet.

mkdir /etc/masterha
cp /opt/mha4mysql-manager-0.57/samples/conf/app1.cnf /etc/masterha
vim /etc/masterha/app1.cnf #Löschen Sie den ursprünglichen Inhalt, kopieren Sie direkt die IP-Adresse des Knotenservers und ändern Sie sie [Serverstandard]
manager_log=/var/log/masterha/app1/manager.log
manager_workdir=/var/log/masterha/app1
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
Ping-Intervall = 1
remote_workdir=/tmp
repl_password=123
repl_user=meinSlave
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.126.30 -s 192.168.126.40
shutdown_script=""
ssh_user=root
Benutzer=mha

[Server1]
Hostname = 192.168.126.20
Port = 3306

[Server2]
Kandidat_Master = 1
check_repl_delay=0
Hostname = 192.168.126.30
Port = 3306

[server3]
Hostname = 192.168.126.40
Port = 3306
[Serverstandard]
manager_log=/var/log/masterha/app1/manager.log #Manager-Protokoll manager_workdir=/var/log/masterha/app1.log #Manager-Arbeitsverzeichnis master_binlog_dir=/usr/local/mysql/data/ #Der Speicherort, an dem der Master das Binlog speichert. Der Pfad hier muss mit dem im Master konfigurierten Binlog-Pfad übereinstimmen, damit MHA es finden kann master_ip_failover_script=/usr/local/bin/master_ip_failover #Legen Sie das Umschaltskript für das automatische Failover fest, das ist das obige Skript master_ip_online_change_script=/usr/local/bin/master_ip_online_change #Legen Sie das Umschaltskript für das manuelle Umschalten fest password=manager #Legen Sie das Passwort des Root-Benutzers in MySQL fest. Dieses Passwort ist das Passwort zum Erstellen des Überwachungsbenutzers im vorherigen Artikel ping_interval=1 #Legen Sie das Zeitintervall für die Überwachung der Hauptdatenbank und das Senden von Ping-Paketen fest. Der Standardwert beträgt 3 Sekunden. Automatisches Failover nach drei Versuchen ohne Antwort
remote_workdir=/tmp #Legen Sie den Speicherort fest, an dem das Remote-MySQL-Binlog beim Umschalten gespeichert wird repl_password=123 #Legen Sie das Kennwort des Replikationsbenutzers fest repl_user=myslave #Legen Sie den Benutzer des Replikationsbenutzers fest report_script=/usr/local/send_report #Legen Sie das Skript zum Senden von Alarmen nach dem Umschalten fest secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.126.30 -s 192.168.126.40 #Geben Sie die IP-Adresse des zu überprüfenden Slave-Servers an shutdown_script="" #Legen Sie das Skript zum Herunterfahren des fehlerhaften Hosts nach einem Fehler fest (die Hauptfunktion dieses Skripts besteht darin, den Host herunterzufahren, um einen Brain Split zu verhindern, der hier nicht verwendet wird)
ssh_user=root #Legen Sie den SSH-Anmeldebenutzernamen fest user=mha #Legen Sie den Überwachungsbenutzer root fest

[Server1]
Hostname = 192.168.126.20
Port = 3306

[Server2]
Hostname = 192.168.126.30
Port = 3306
Kandidat_Master = 1
#Auf Kandidatenmaster setzen. Nach dem Setzen dieses Parameters wird die Slave-Datenbank nach dem Master-Slave-Wechsel zur Master-Datenbank befördert, auch wenn die Master-Datenbank nicht der neueste Slave im Cluster ist

check_repl_delay=0
#Wenn ein Slave mehr als 100 Millionen Relay-Logs hinter dem Master zurückliegt, wählt MHA den Slave standardmäßig nicht als neuen Master aus, da die Wiederherstellung des Slaves sehr lange dauert. Durch Festlegen von check_repl_delay=0 veranlasst MHA den Switch, die Replikationsverzögerung bei der Auswahl eines neuen Masters zu ignorieren. Dieser Parameter ist für Hosts mit candidates_master=1 sehr nützlich, da der Masterkandidat während des Switches der neue Master sein muss.

[server3]
Hostname = 192.168.126.40
Port = 3306

9. Die erste Konfiguration erfordert die manuelle Aktivierung der virtuellen IP auf dem Masterknoten

/sbin/ifconfig ens33:1 192.168.126.200/24 

Bildbeschreibung hier einfügen

10. Testen Sie die passwortlose SSH-Authentifizierung auf dem Manager-Knoten. Wenn sie normal ist, wird die Ausgabe erfolgreich sein, wie unten gezeigt.

masterha_check_ssh -conf=/etc/masterha/app1.cnf 

Bildbeschreibung hier einfügen

11. Testen Sie die MySQL-Master-Slave-Verbindung auf dem Manager-Knoten. Wenn „MySQL Replication Health is OK“ angezeigt wird, ist alles normal. Wie unten gezeigt.

masterha_check_repl -conf=/etc/masterha/app1.cnf 

Bildbeschreibung hier einfügen

12. Starten Sie MHA auf dem Managerknoten

nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &

–remove_dead_master_conf: Dieser Parameter bedeutet, dass bei einem Master-Slave-Wechsel die IP-Adresse der alten Master-Datenbank aus der Konfigurationsdatei entfernt wird.
–manger_log: Speicherort des Protokolls.

–ignore_last_failover: Standardmäßig wird kein Failover durchgeführt, wenn MHA aufeinanderfolgende Ausfallzeiten erkennt und das Intervall zwischen zwei Ausfallzeiten weniger als 8 Stunden beträgt. Diese Einschränkung dient dazu, den Ping-Pong-Effekt zu vermeiden. Dieser Parameter bedeutet, dass die Dateien ignoriert werden, die durch den letzten durch MHA ausgelösten Wechsel generiert wurden. Standardmäßig wird das Verzeichnis nach dem Auftreten des MHA-Wechsels im Protokoll aufgezeichnet, d. h. in der oben festgelegten Protokolldatei app1.failover.complete. Wenn die Datei beim nächsten Wechsel im Verzeichnis vorhanden ist, darf der Wechsel nicht ausgelöst werden, es sei denn, die Datei wird nach dem ersten Wechsel gelöscht. Der Einfachheit halber wird es hier auf –ignore_last_failover eingestellt.

13. Überprüfen Sie den MHA-Status und Sie können sehen, dass der aktuelle Master der Mysql1-Knoten ist.

masterha_check_status --conf=/etc/masterha/app1.cnf 

Bildbeschreibung hier einfügen

14. Überprüfen Sie das MHA-Protokoll und Sie können sehen, dass der aktuelle Master 192.168.126.20 ist, wie unten gezeigt.

cat /var/log/masterha/app1/manager.log | grep "aktueller Master" 

Bildbeschreibung hier einfügen

Überprüfen Sie, ob die VIP-Adresse 192.168.126.200 von Mysql1 existiert. Diese VIP-Adresse wird nicht verschwinden, weil der Managerknoten den MHA-Dienst stoppt.

ifconfig

//Um den Manager-Dienst herunterzufahren, können Sie den folgenden Befehl verwenden.
masterha_stop --conf=/etc/masterha/app1.cnf
Oder Sie können die Prozess-ID direkt beenden, um sie zu löschen.

Bildbeschreibung hier einfügen

(III) Fehlersimulation

#Überwachen und beobachten Sie Protokolldatensätze auf dem Managerknoten

tail -f /var/log/masterha/app1/manager.log 

Bildbeschreibung hier einfügen

#Stoppen Sie den MySQL-Dienst auf dem Masterknoten Mysql1

systemctl stoppt mysqld
oder pkill -9 mysql 

Bildbeschreibung hier einfügen

#Nach einem normalen automatischen Wechsel wird der MHA-Prozess beendet. HMA ändert automatisch den Inhalt der Datei app1.cnf und löscht den ausgefallenen MySQL1-Knoten. Prüfen Sie, ob mysql2 VIP übernimmt
ifconfig

Bildbeschreibung hier einfügen

Bildbeschreibung hier einfügen

Algorithmus für das Failover der Kandidaten-Masterdatenbank:
1. Im Allgemeinen wird die Qualität von Slave-Datenbanken anhand von (Position/GTID) beurteilt. Wenn es einen Unterschied in den Daten gibt, wird der Slave, der dem Master am nächsten ist, zum Master-Kandidaten.
2. Wenn die Daten konsistent sind, wählen Sie die alternative Masterdatenbank entsprechend der Reihenfolge der Konfigurationsdateien aus.
3. Legen Sie ein Gewicht fest (candidate_master=1), um den Kandidatenmaster zwangsweise entsprechend dem Gewicht anzugeben.
(1) Wenn ein Slave standardmäßig 100 MB an Relay-Logs hinter dem Master zurückliegt, schlägt er fehl, selbst wenn er über Gewichte verfügt.
(2) Wenn check_repl_delay=0 ist, wird es zwangsweise als Backup-Master ausgewählt, auch wenn es um eine große Anzahl von Protokollen zurückliegt.

Schritte zur Fehlerbehebung:

1. MySQL reparieren

systemctl startet mysqld neu

2. Master und Slave reparieren

#Zeigen Sie die Binärdateien und Synchronisierungspunkte auf dem aktuellen Masterserver an. Mysql2 zeigt den Masterstatus an.
#Führen Sie den Synchronisierungsvorgang auf dem ursprünglichen Masterserver mysql1 aus. Ändern Sie den Master in master_host='192.168.126.30',master_user='myslave',master_password='123',master_log_file='master-bin.000001',master_log_pos=1747;

Slave starten;

Slave-Status anzeigen\G

Bildbeschreibung hier einfügen

3. Ändern Sie die Konfigurationsdatei app1.cnf auf dem Managerknoten (und fügen Sie diesen Datensatz hinzu, da er automatisch verschwindet, wenn ein Fehler erkannt wird).

vim /etc/masterha/app1.cnf
......
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.126.20 -s 192.168.126.40
......
[Server1]
Hostname = 192.168.126.30
Port = 3306

[Server2]
Kandidat_Master = 1
check_repl_delay=0
Hostname = 192.168.126.20
Port = 3306

[server3]
Hostname = 192.168.126.40
Port = 3306

Bildbeschreibung hier einfügen

4. Starten Sie MHA auf dem Managerknoten

nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &

Bildbeschreibung hier einfügen

Bildbeschreibung hier einfügen

#Lösen Sie das Problem der Inkompatibilität chinesischer und englischer Zeichen und der Meldung von Fehlern dos2unix /usr/local/bin/master_ip_failover

Damit ist dieser Artikel über die MySQL MHA-Hochverfügbarkeitskonfiguration und detaillierte Bereitstellungsschritte für Failover abgeschlossen. Weitere Informationen zur MySQL MHA-Hochverfügbarkeitskonfiguration 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!

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
  • Schritte zum Erstellen der MHA-Architekturbereitstellung in MySQL
  • 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

<<:  So unterstützen Sie Webdings-Schriftarten in Firefox

>>:  Detaillierte Erklärung gängiger Docker-Befehle

Artikel empfehlen

So lösen Sie das Problem, das Root-Passwort von Mysql auf dem Mac zu vergessen

Ich habe MySQL auf meinem Computer längere Zeit n...

So verwenden Sie den Nginx-Proxy zum Surfen im Internet

Normalerweise verwende ich nginx als Reverse-Prox...

Vue+Vant implementiert die obere Suchleiste

In diesem Artikelbeispiel wird der spezifische Co...

JavaScript-Implementierung eines Karussellbeispiels

In diesem Artikel wird der spezifische Code für J...

VPS erstellt Offline-Download-Server (nach der Ära der Netzwerkfestplatten)

Motivation Aus Lerngründen habe ich einen VPS-Die...

Eine Zeile CSS-Code zur Integration von Avatar und Nationalflagge

Es ist Nationalfeiertag und jeder kann es kaum er...

JavaScript implementiert den detaillierten Prozess der Stapelstruktur

Inhaltsverzeichnis 1. Die Stapelstruktur verstehe...

Detaillierte Analyse des HTTP-Statuscodes 502 des Dienstes nginx+php-fpm

Bei einem unserer Webprojekte ist aufgrund der Zu...

Parsen des Linux-Quellcodes epoll

Inhaltsverzeichnis 1. Einleitung 2. Einfaches Epo...

Detaillierte Anweisungen zum Download und Installationsprozess von MySQL 5.7.18

MySql herunterladen 1. Öffnen Sie die offizielle ...