Eine vollständige Erklärung der MySQL-Hochverfügbarkeitsarchitektur: MHA-Architektur

masterha_check_ssh Überprüfen Sie den SSH-Konfigurationsstatus von MHA masterha_check_repl Überprüfen Sie den MySQL-Replikationsstatus masterha_manger Starten Sie MHA
masterha_check_status prüft den aktuellen MHA-Laufstatus masterha_master_monitor prüft, ob der Master ausgefallen ist masterha_master_switch steuert das Failover (automatisch oder manuell)
masterha_conf_host fügt konfigurierte Serverinformationen hinzu oder löscht sie

save_binary_logs speichert und kopiert die Binärprotokolle 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 Relay-Protokolle löschen (blockiert den SQL-Thread nicht)

Rolle IP-Adresse Hostname Server-ID Typ Monitor-Host 192.168.0.20 Server01 - Monitor Replikationsgruppe Master 192.168.0.50 Server02 1 schreiben Kandidat Master 192.168.0.60 Server03 2 lesen Slave 192.168.0.70 Server04 3 lesen

## 1. Schalten Sie die Firewall aus systemctl stop firewalld
systemctl deaktiviert Firewall
0

## 2. Legen Sie den Hostnamen hostnamectl set-hostname Mysql1 fest
hostnamectl set-hostname Mysql2
hostnamectl set-hostname Mysql3

## 3. Knoteneinstellungen: Master-, Slave1-, Slave2-Konfigurationsdateien /etc/my.cnf

## a. Master-Knoten##
vim /etc/meine.cnf
[mysqld]
Server-ID = 1
log_bin = Master-Bin
log-slave-updates = wahr
systemctl startet mysqld neu

##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

## 4. Erstellen Sie einen Softlink ln -s /usr/local/mysql/bin/mysql /usr/sbin/
ln -s /usr/local/mysql/bin/mysqlbinlog /usr/sbin/

## 5. Ein Master und zwei Slaves: Alle Knoten werden mit mysql -uroot -p autorisiert
gewähre Replikations-Slave auf *.* an 'myslave'@'192.168.80.%', identifiziert durch '123'; #Slave-Datenbanksynchronisierung verwendet alle Berechtigungen auf *.* an 'mha'@'192.168.80.%', 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 *.*.

## Die Binärdatei kann auf dem Master angezeigt werden, der Synchronisierungspunkt zeigt den Masterstatus an;
+-------------------+----------+--------------+------------------+-------------------+
| Datei | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------+----------+--------------+------------------+-------------------+
| master-bin.000002 | 1745 | | | |
+-------------------+----------+--------------+------------------+-------------------+

## Slave1, Slave2 Knoten Datensynchronisationsergebnisse zeigen Slave-Status\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

# Slave1 und Slave2 in den Nur-Lese-Modus setzen. set global read_only=1;

# Erstellen Sie einen Datenbanktest##Fügen Sie ein Datenelement in die Master-Datenbank ein, um zu testen, ob es synchronisiert ist##
Datenbank test_db erstellen;
verwenden Sie test_db;
Tabellentest erstellen (ID int);
in test(id)-Werte einfügen (1);

# Ansicht aus der Datenbank select * from test_db.test;
+------+
|Ich würde|
+------+
| 1 |
+------+

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

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

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

-----------------------------------------------------------------------------------------------------
#Nachdem die Managerkomponente installiert wurde, werden unter /usr/local/bin mehrere Tools generiert, hauptsächlich die folgenden:
masterha_check_ssh prüft die SSH-Konfiguration von MHAmasterha_check_repl prüft den MySQL-Replikationsstatusmasterha_manger startet das Manager-Skriptmasterha_check_status prüft den aktuellen MHA-Laufstatusmasterha_master_monitor prüft, ob der Master down istmasterha_master_switch steuert das Failover (automatisch oder manuell)
masterha_conf_host Konfigurierte Serverinformationen hinzufügen oder löschen masterha_stop Manager herunterfahren

#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ärprotokolle 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 Relay-Protokolle löschen (blockiert den SQL-Thread nicht)

ssh-keygen -t rsa #Drücken Sie die Eingabetaste vollständig ssh-copy-id 192.168.80.10
SSH-Kopie-ID 192.168.80.20
SSH-Kopie-ID 192.168.80.30

ssh-keygen -t rsa
SSH-Kopie-ID 192.168.80.20
SSH-Kopie-ID 192.168.80.30

ssh-keygen -t rsa
SSH-Kopie-ID 192.168.80.10
SSH-Kopie-ID 192.168.80.30

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

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

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.80.200'; #Geben Sie die Adresse von vipmy an $brdc = '192.168.80.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.80.200 ist
my $ssh_stop_vip = "/sbin/ifconfig ens33:$key down"; #Dieser Variablenwert repräsentiert ifconfig ens33:1 192.168.80.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 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";
}

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.80.20 -s 192.168.80.30
shutdown_script=""
ssh_user=root
Benutzer=mha

[Server1]
Hostname = 192.168.80.10
Port = 3306

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

[server3]
Hostname = 192.168.80.30
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.80.20 -s 192.168.80.30 #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.80.10
Port = 3306

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

check_repl_delay=0
#Wenn ein Slave standardmäßig mehr als 100 M Relay-Protokolle hinter dem Master zurückliegt, wählt MHA den Slave nicht als neuen Master aus. 
Da die Wiederherstellung dieses Slaves sehr lange dauert, löst MHA durch Festlegen von check_repl_delay=0 den Wechsel aus und ignoriert die Replikationsverzögerung bei der Auswahl eines neuen Masters. Dieser Parameter ist sehr nützlich für Hosts mit dem Wert candidates_master=1, da der Masterkandidat während des Wechsels der neue Master sein muss.

[server3]
Hostname = 192.168.80.30
Port = 3306

/sbin/ifconfig ens33:1 192.168.80.200/24

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

Di., 26. Nov. 2020, 23:09:45 - [Warnung] Globale Konfigurationsdatei /etc/masterha_default.cnf nicht gefunden. Wird übersprungen.
Di, 26. Nov 2020, 23:09:45 - [Info] Standardkonfiguration der Anwendung wird aus /etc/masterha/app1.cnf gelesen.
Di., 26. Nov. 2020, 23:09:45 Uhr – [Info] Serverkonfiguration wird aus /etc/masterha/app1.cnf gelesen.
Di, 26. Nov 2020, 23:09:45 - [Info] SSH-Verbindungstests werden gestartet.
Di, 26. Nov 2020, 23:09:46 - [debug] 
Di., 26. Nov. 2020, 23:09:45 - [debug] Verbindung per SSH von [email protected](192.168.80.20:22) zu [email protected](192.168.80.30:22)..
Di., 26. Nov. 2020, 23:09:46 - [debug] ok.
Di, 26. Nov 2020, 23:09:47 - [debug] 
Di., 26. Nov. 2020, 23:09:46 - [debug] Verbindung per SSH von [email protected](192.168.80.30:22) zu [email protected](192.168.80.20:22)..
Di., 26. Nov. 2020, 23:09:47 - [debug] ok.
Di., 26. Nov. 2020, 23:09:47 Uhr – [Info] Alle SSH-Verbindungstests wurden erfolgreich bestanden.
# Passwortlose Authentifizierung erfolgreich

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

Di., 26. Nov. 2020, 23:10:29 - [Info] Überprüfung der Slave-Einstellungen abgeschlossen.
Di 26. Nov 2020 23:10:29 - [info] 
192.168.80.20(192.168.80.20:3306) (aktueller Master)
 +--192.168.80.30(192.168.80.30:3306)

Di., 26. Nov. 2020, 23:10:29 - [Info] Überprüfen der Replikationsintegrität auf 192.168.80.30.
Di, 26. Nov. 2020, 23:10:29 - [Info] ok.
Di., 26. Nov. 2020, 23:10:29 - [Info] Überprüfen des master_ip_failover_script-Status:
Di., 26. Nov. 2020, 23:10:29 Uhr - [info] /usr/local/bin/master_ip_failover --command=status --ssh_user=root --orig_master_host=192.168.80.20 --orig_master_ip=192.168.80.20 --orig_master_port=3306 


IM SKRIPTTEST====/sbin/ifconfig ens33:1 down==/sbin/ifconfig ens33:1 192.168.80.200===

Den Status des Skripts wird geprüft.. OK 
Di., 26. Nov. 2020, 23:10:29 - [Info] OK.
Di., 26. Nov. 2020, 23:10:29 – [Warnung] shutdown_script ist nicht definiert.
Di., 26. Nov. 2020, 23:10:29 - [Info] Habe Exitcode 0 erhalten (Master nicht tot).

Der Zustand der MySQL-Replikation ist in Ordnung.
# Master-Slave-Verbindung erfolgreich

# 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 gilt: Wenn MHA aufeinanderfolgende Ausfallzeiten erkennt und der Abstand zwischen zwei Ausfallzeiten weniger als 8 Stunden beträgt,
  Es wird kein Failover durchgeführt. Diese Einschränkung dient der Vermeidung des Ping-Pong-Effekts. Dieser Parameter bedeutet, dass die vom letzten MHA-ausgelösten Switch generierten Dateien ignoriert werden.
  Standardmäßig wird nach dem MHA-Wechsel das Protokollverzeichnis aufgezeichnet, d. h. die oben festgelegte Protokolldatei app1.failover.complete.
  Wenn Sie das nächste Mal umschalten und die Datei im Verzeichnis gefunden wird, darf der Wechsel nicht ausgelöst werden, es sei denn, die Datei wird nach dem ersten Wechsel gelöscht.
  Der Einfachheit halber ist dies auf --ignore_last_failover eingestellt.

# b Ü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

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

# c Überprüfen Sie, ob die VIP-Adresse 192.168.80.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.

# aÜberwachen und beobachten Sie Protokolldatensätze auf dem Managerknoten tail -f /var/log/masterha/app1/manager.log

# bStoppen Sie den MySQL-Dienst auf dem Masterknoten Mysql1 systemctl stop mysqld
oder pkill -9 mysql

# cNach 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
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.

1. Starten Sie den MySQL-Dienst neu systemctl restart mysqld
2. Reparieren Sie den Master-Slave: Überprüfen Sie zunächst, ob die Binärdateien und Synchronisierungspunkte den Master-Status anzeigen.
3. Der ursprüngliche Masterserver mysql1 führt Synchronisierungsvorgänge aus: Ändern Sie Master in master_host='192.168.80.20',master_user='myslave',master_password='123',master_log_file='master-bin.000001',master_log_pos=1745;
Slave starten;

4. Ändern Sie die Konfigurationsdatei app1.cnf auf dem Managerknoten
vi /etc/masterha/app1.cnf
......
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.80.10 -s 192.168.80.30
......
[Server1]
Hostname = 192.168.80.20
Port = 3306

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

[server3]
Hostname = 192.168.80.30
Port = 3306

5. Die Slave-Bibliothek muss auf schreibgeschützten Modus eingestellt sein: Die aktuelle Slave-Bibliothek ist mysql
setze global schreibgeschützt=1;

6. Starten Sie MHA auf dem Managerknoten und prüfen Sie, ob VIP zu mysql2 driftet
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 &

##Überprüfen Sie den MHA-Status und Sie können sehen, dass der aktuelle Master der Mysql2-Knoten ist masterha_check_status --conf=/etc/masterha/app1.cnf