MySQL-Hochverfügbarkeitslösung MMM (MySQL Multi-Master-Replikationsmanager)

1. Einführung in MMM:

MMM steht für Multi-Master Replication Manager für MySQL: Der auf Perl basierende MySQL Multi-Master Replication Manager ist eine skalierbare Suite von Skripten zur Überwachung, Ausfallsicherung und Verwaltung der MySQL Master-Master-Replikationskonfiguration (es kann immer nur ein Knoten beschrieben werden). MMM kann auch Leselastausgleich auf Slave-Servern durchführen, sodass virtuelle IPs auf einer Gruppe von Servern gestartet werden können, die für die Replikation verwendet werden. Darüber hinaus verfügt es auch über Skripte zur Implementierung von Datensicherung und Neusynchronisierung zwischen Knoten. MySQL selbst bietet keine Replikations-Failover-Lösung. Die MMM-Lösung kann ein Server-Failover erreichen und dadurch eine hohe Verfügbarkeit von MySQL erreichen. MMM bietet nicht nur die Funktion der Floating-IP, sondern schaltet bei einem Ausfall des aktuellen Masterservers Ihre Backend-Slave-Server zur synchronen Replikation automatisch auf den neuen Masterserver um, ohne dass Sie die Synchronisierungskonfiguration manuell ändern müssen. Diese Lösung ist derzeit eine relativ ausgereifte Lösung. Weitere Informationen finden Sie auf der offiziellen Website: http://mysql-mmm.org

Vorteile : Hohe Verfügbarkeit, gute Skalierbarkeit, automatische Umschaltung im Fehlerfall und bei der Master-Master-Synchronisation steht für Schreibvorgänge gleichzeitig nur eine Datenbank zur Verfügung, um die Datenkonsistenz zu gewährleisten. Wenn der Masterserver ausfällt, übernimmt sofort ein anderer Masterserver und andere Slaveserver können ohne manuelles Eingreifen automatisch wechseln.

Nachteile : Der Monitorknoten ist ein einzelner Punkt, aber Sie können auch Keepalived oder Heertbeat kombinieren, um ihn hochverfügbar zu machen; mindestens drei Knoten, es gibt Anforderungen an die Anzahl der Hosts, eine Lese-/Schreibtrennung muss implementiert werden und auf dem Front-End muss ein Lese-/Schreibtrennungsprogramm geschrieben werden. In einem Geschäftssystem mit sehr starkem Lese- und Schreibverkehr ist die Leistung nicht sehr stabil und es können Probleme wie Replikationsverzögerungen und Umschaltfehler auftreten. Für Umgebungen mit hohen Anforderungen an die Datensicherheit und hohem Lese- und Schreibaufwand ist die MMM-Lösung wenig geeignet.

Anwendbare Szenarien:

MMM ist auf Szenarien anwendbar, in denen die Datenbank über eine große Anzahl von Zugriffen verfügt und eine Lese-/Schreibtrennung erreicht werden kann.
Die Hauptfunktionen von Mmm werden durch die folgenden drei Skripte bereitgestellt:
mmm_mond ist der Überwachungs-Daemon, der für alle Überwachungsaufgaben zuständig ist und über die Entfernung von Knoten entscheidet (der mmm_mond-Prozess führt eine regelmäßige Heartbeat-Erkennung durch, und wenn diese fehlschlägt, wird die Schreib-IP zu einem anderen Master verschoben) usw.
mmm_agentd ist ein Agent-Daemon, der auf dem MySQL-Server ausgeführt wird und dem Überwachungsknoten über einen einfachen Remote-Service-Satz bereitgestellt wird.
mmm_control verwaltet den mmm_mond-Prozess über die Befehlszeile. Während des gesamten Überwachungsprozesses müssen Sie in MySQL relevante autorisierte Benutzer hinzufügen. Zu den autorisierten Benutzern gehören ein mmm_monitor-Benutzer und ein mmm_agent-Benutzer. Wenn Sie das Backup-Tool von mm verwenden möchten, müssen Sie auch einen mmm_tools-Benutzer hinzufügen.

2. Einsatz und Implementierung

1. Umgebung Einführung

Betriebssystem: centos7.2 (64-bit) Datenbanksystem: mysql5.7.13

Selinux ausschalten

Konfigurieren Sie NTP zur Zeitsynchronisierung

2. Konfigurieren Sie die Datei /etc/hosts auf allen Hosts und fügen Sie den folgenden Inhalt hinzu:

192.168.31.83 Master1
192.168.31.141 Master2
192.168.31.250 Sklave1
192.168.31.225 Sklave2
192.168.31.106 Monitor1

Installieren Sie die Pakete perl, perl-devel, perl-CPAN, libart_lgpl.x86_64, rrdtool.x86_64, rrdtool-perl.x86_64 auf allen Hosts
#yum -y installiere perl-* libart_lgpl.x86_64 rrdtool.x86_64 rrdtool-perl.x86_64

Hinweis: Verwenden Sie die Online-Yum-Quellcodeinstallation von CentOS7

Installieren Sie Perl-bezogene Bibliotheken

#cpan -i Algorithmus::Diff Klasse::Singleton DBI DBD::mysql Log::Dispatch Log::Log4perl Mail::Senden Net::Ping Proc::Daemon Zeit::HiRes Params::Validieren Net::ARP

3. Installieren Sie mysql5.7 und konfigurieren Sie die Replikation auf den Hosts master1, master2, slave1 und slave2

Master1 und Master2 sind Master-Slave zueinander, und Slave1 und Slave2 sind Slaves von Master1. Fügen Sie den folgenden Inhalt zu jeder MySQL-Konfigurationsdatei /etc/my.cnf hinzu. Beachten Sie, dass die Server-ID nicht wiederholt werden kann.

Master1-Host:

log-bin = mysql-bin
binlog_format = gemischt
Server-ID = 1
Relay-Log = Relay-Bin
Relais-Log-Index = Slave-Relay-Bin.Index
log-slave-updates = 1
automatische Inkrementierung = 2
Auto-Inkrement-Offset = 1
Master2-Host:
log-bin = mysql-bin
binlog_format = gemischt
Server-ID = 2
Relay-Log = Relay-Bin
Relais-Log-Index = Slave-Relay-Bin.Index
log-slave-updates = 1
automatische Inkrementierung = 2
automatischer Inkrement-Offset = 2
Slave1-Host:
Server-ID = 3
Relay-Log = Relay-Bin
Relais-Log-Index = Slave-Relay-Bin.Index
schreibgeschützt = 1
Slave2-Host:
Server-ID = 4
Relay-Log = Relay-Bin
Relais-Log-Index = Slave-Relay-Bin.Index
schreibgeschützt = 1

Starten Sie den MySQL-Dienst nach Abschluss der Änderung von my.cnf über systemctl restart mysqld neu

Um die Firewall auf den 4 Datenbankhosts zu aktivieren, deaktivieren Sie entweder die Firewall oder erstellen Sie Zugriffsregeln:

Firewall-Befehl --permanent --add-port=3306/tcp
Firewall-Befehl --reload
Master-Slave-Konfiguration (Master1 und Master2 sind als Master konfiguriert, Slave1 und Slave2 sind als Slaves von Master1 konfiguriert):
Auf Master1 autorisieren:
mysql> gewähre Replikations-Slave auf *.* an rep@'192.168.31.%', identifiziert durch '123456';
Auf Master2 autorisieren:
mysql> gewähre Replikations-Slave auf *.* an rep@'192.168.31.%', identifiziert durch '123456';
Konfigurieren Sie Master2, Slave1 und Slave2 als Slaves von Master1:
Führen Sie Show Master Status auf Master1 aus; erhalten Sie Binlog-Dateien und Positionspunkte
mysql> Masterstatus anzeigen;
+------------------+----------+--------------+------------------+--------------------------------------------------+
| Datei | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+---------------------------------------------------+
| mysql-bin.000001 | 452 | | | |
+------------------+----------+--------------+------------------+-----------------------------------------------------+
Ausführen auf Master2, Slave1 und Slave2

mysql> ändere Master in master_host='192.168.31.83',master_port=3306,master_user='rep',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=452;
mysql>Slave-Start;
Überprüfen Sie die Master-Slave-Replikation:
Master2-Host:
mysql> Slave-Status anzeigen\G;
*************************** 1. Reihe ***************************
Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
Master_Host: 192.168.31.83
Master_User: rep
Master_Port: 3306
Verbindungswiederholung: 60
Master_Log_File:mysql-bin.000001
Read_Master_Log_Pos: 452
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Ja
Slave_SQL_Running: Ja
Slave1-Host:
mysql> Slave-Status anzeigen\G;
*************************** 1. Reihe ***************************
Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
Master_Host: 192.168.31.83
Master_User: rep
Master_Port: 3306
Verbindungswiederholung: 60
Master_Log_File:mysql-bin.000001
Read_Master_Log_Pos: 452
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Ja
Slave_SQL_Running: Ja
Slave2-Host:
mysql> Slave-Status anzeigen\G;
*************************** 1. Reihe ***************************
Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
Master_Host: 192.168.31.83
Master_User: rep
Master_Port: 3306
Verbindungswiederholung: 60
Master_Log_File:mysql-bin.000001
Read_Master_Log_Pos: 452
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Ja
Slave_SQL_Running: Ja
Wenn Slave_IO_Running und Slave_SQL_Running beide ja lauten, ist die Master-Slave-Konfiguration in Ordnung. Konfigurieren Sie Master1 als Slave von Master2:
Führen Sie „show master status“ auf Master2 aus, um Binlog-Dateien und Positionspunkte abzurufen.
mysql> Masterstatus anzeigen;
+------------------+----------+--------------+------------------+--------------------------------------------------+
| Datei | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+---------------------------------------------------+
| mysql-bin.000001 | 452 | | | |
+------------------+----------+--------------+------------------+----------------------------------------------------+
Auf Master1 ausführen:
mysql> ändere Master in master_host='192.168.31.141',master_port=3306,master_user='rep',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=452;
mysql> Slave starten;
Überprüfen Sie die Master-Slave-Replikation:
Master1-Host:
mysql> Slave-Status anzeigen\G;
*************************** 1. Reihe ***************************
Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
Master_Host: 192.168.31.141
Master_User: rep
Master_Port: 3306
Verbindungswiederholung: 60
Master_Log_File:mysql-bin.000001
Read_Master_Log_Pos: 452
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Ja
Slave_SQL_Running: Ja
Wenn Slave_IO_Running und Slave_SQL_Running beide „Ja“ lauten, ist die Master-Slave-Konfiguration in Ordnung.
4.mysql-mmm-Konfiguration:
Erstellen Sie auf den vier MySQL-Knoten ein Benutzer- und ein Proxy-Konto:
mysql> gewähre 'mmm_agent'@'192.168.31.%', identifiziert durch '123456', super, replicationclient, process auf *.*;
Erstellen Sie ein Überwachungskonto:
mysql> gewähre Replikationsclient auf *.* an 'mmm_monitor'@'192.168.31.%', identifiziert durch '123456';
Hinweis 1: Da die vorherige Master-Slave-Replikation und Master-Slave bereits in Ordnung waren, habe ich sie auf dem Master1-Server ausgeführt und es war in Ordnung.
Überprüfen Sie, ob auf den drei Datenbanken Master2, Slave1 und Slave2 Monitoring- und Proxy-Konten vorhanden sind
mysql> wähle Benutzer, Host aus mysql.user, wobei Benutzer in ('mmm_monitor', 'mmm_agent');
+-------------+----------------------------+
| Benutzer | Gastgeber |
+-------------+----------------------------+
| mmm_agent | 192.168.31.% |
| mmm_monitor | 192.168.31.% |
+-------------+------------------+
oder
mysql> Berechtigungen für 'mmm_agent'@'192.168.31.%' anzeigen;
+-----------------------------------------------------------------------------------------------------------------------------+
| Zuweisungen für [email protected].% |
+-----------------------------------------------------------------------------------------------------------------------------+
| GRANT-PROZESS, SUPER, REPLICATION-CLIENT AUF *.* AN 'mmm_agent'@'192.168.31.%' |
+-----------------------------------------------------------------------------------------------------------------------------+
mysql> Berechtigungen für 'mmm_monitor'@'192.168.31.%' anzeigen;
+-----------------------------------------------------------------------------------------------------------------------------+
| Zuschüsse für [email protected].% |
+-----------------------------------------------------------------------------------------------------------------------------+
| GRANT REPLICATION CLIENT ON *.* TO 'mmm_monitor'@'192.168.31.%' |
Anmerkung 2:
mmm_monitor-Benutzer: Die mmm-Überwachung wird verwendet, um den Zustand des MySQL-Serverprozesses zu überprüfen.
mmm_agent-Benutzer: Der mmm-Agent wird verwendet, um den schreibgeschützten Modus, den Replikationsmasterserver usw. zu ändern.
5. Installieren Sie mysql-mmm auf dem Monitor-Host (192.168.31.106), um das Überwachungsprogramm zu installieren
cd /tmp
wget http://pkgs.fedoraproject.org/repo/pkgs/mysql-mmm/mysql-mmm-2.2.1.tar.gz/f5f8b48bdf89251d3183328f0249461e/mysql-mmm-2.2.1.tar.gz
tar -zxf mysql-mmm-2.2.1.tar.gz
cd mysql-mmm-2.2.1
installieren
Installieren Sie den Agenten auf den Datenbankservern (Master1, Master2, Slave1, Slave2).
cd /tmp
wget http://pkgs.fedoraproject.org/repo/pkgs/mysql-mmm/mysql-mmm-2.2.1.tar.gz/f5f8b48bdf89251d3183328f0249461e/mysql-mmm-2.2.1.tar.gz
tar -zxf mysql-mmm-2.2.1.tar.gz
cd mysql-mmm-2.2.1
installieren

6. Konfigurieren Sie mmm

Schreiben Sie die Konfigurationsdatei. Die fünf Hosts müssen konsistent sein:
Nachdem die Installation abgeschlossen ist, werden alle Konfigurationsdateien unter /etc/mysql-mmm/ abgelegt. Sowohl der Management-Server als auch der Datenbankserver müssen eine gemeinsame Datei mmm_common.conf enthalten, deren Inhalt wie folgt ist:
active_master_rolewriter#Zeigt die aktive Masterrolle an. Alle DB-Server müssen den Parameter read_only aktivieren. Der Überwachungsagent für den Writer-Server schaltet das Attribut read_only automatisch aus.
<Host-Standard>
cluster_interfaceeno16777736#Cluster-Netzwerkschnittstelle
pid_path /var/run/mmm_agentd.pid#pid-Pfad
bin_path /usr/lib/mysql-mmm/#Pfad der ausführbaren Datei
replication_user rep#Replikationsbenutzer
replication_password 123456#Replikationsbenutzerkennwort
agent_usermmm_agent#Agent-Benutzer
agent_password 123456#Agent-Benutzerpasswort
</host>
<host master1>#Hostname von Master1
ip 192.168.31.83#IP von Master1
Modus Master # Rollenattribut, Master repräsentiert den Master
Peer Master2 # Der Hostname des Servers, der Master1 entspricht, d. h. der Server-Hostname von Master2
</host>
<host master2>#Gleiches Konzept wie Master
IP-Adresse 192.168.31.141
Modus Master
Peer-Master1
</host>
<host slave1>#Hostname der Slave-Bibliothek. Wenn mehrere Slave-Bibliotheken vorhanden sind, kann die gleiche Konfiguration wiederholt werden.
IP 192.168.31.250#Slave-IP
Modus Slave#Slave Rollenattribut stellt den aktuellen Host dar
</host>
<host slave2>#Gleiches Konzept wie Slave
IP-Adresse 192.168.31.225
Modus Slave
</host>
<Rolle Autor>#Autor-Rollenkonfiguration
Hosts Master1, Master2#Hostname des Servers, der Schreibvorgänge ausführen kann. Wenn Sie keine Schreibvorgänge umschalten möchten, können Sie hier nur den Master konfigurieren. Dadurch können Sie auch das Umschalten von Schreibvorgängen aufgrund von Netzwerkverzögerungen vermeiden. Wenn der Master jedoch ausfällt, verfügt der aktuelle MMM über keinen Schreiber und nur über externe Lesevorgänge.
ips 192.168.31.2#Virtuelle IP für externe Schreibvorgänge
Modus exklusiv#exklusiv bedeutet, dass nur ein Master existieren darf, d.h. es kann nur eine Schreib-IP bereitgestellt werden
</Rolle>
<Rollenleser>#Rollenkonfiguration lesen
Hosts Master2, Slave1, Slave2 # Der Hostname des Servers, der Lesevorgänge für die Außenwelt bereitstellt. Natürlich kann hier auch Master hinzugefügt werden
ips 192.168.31.3, 192.168.31.4, 192.168.31.5#Virtuelle IPs für externe Lesevorgänge. Diese drei IPs und Hosts entsprechen sich nicht eins zu eins, und die Anzahl der IPs und Hosts kann auch unterschiedlich sein. Bei dieser Konfiguration werden einem der Hosts zwei IPs zugewiesen
Modus ausgewogen#ausgewogen steht für Lastenausgleich
</Rolle>
Kopieren Sie diese Datei gleichzeitig auf andere Server, ohne die Konfiguration zu ändern
#für Host in Master1 Master2 Slave1 Slave2; führen Sie scp /etc/mysql-mmm/mmm_common.conf $host:/etc/mysql-mmm/ aus; fertig
Agentendateikonfiguration Bearbeiten Sie /etc/mysql-mmm/mmm_agent.conf auf 4 MySQL-Knotenmaschinen
Auf dem Datenbankserver gibt es außerdem eine mmm_agent.conf, die geändert werden muss. Ihr Inhalt lautet:
includemmm_common.conf
dieser Meister1
Hinweis: Diese Konfiguration konfiguriert nur den DB-Server. Der Überwachungsserver muss nicht konfiguriert werden. Der Hostname danach wird in den Hostnamen des aktuellen Servers geändert.
Starten Sie den Agentenprozess. Fügen Sie den folgenden Inhalt unter #!/bin/sh in die Skriptdatei /etc/init.d/mysql-mmm-agent ein
Quelle /root/.bash_profile
Fügen Sie es als Systemdienst hinzu und richten Sie es so ein, dass es automatisch gestartet wird
#chkconfig --add mysql-mmm-agent
#chkconfigmysql-mmm-agent ein
#/etc/init.d/mysql-mmm-agent start
Hinweis: Der Zweck des Hinzufügens der Quelle /root/.bash_profile besteht darin, den automatischen Start des mysql-mmm-agent-Dienstes beim Start zu ermöglichen.
Der einzige Unterschied zwischen dem automatischen und dem manuellen Start besteht darin, eine Konsole zu aktivieren. Dies bedeutet, dass der Dienst beim Starten möglicherweise aufgrund fehlender Umgebungsvariablen nicht gestartet werden kann und die Fehlermeldung wie folgt lautet:
Daemon-Bin: „/usr/sbin/mmm_agentd“
Daemon-PID: „/var/run/mmm_agentd.pid“
MMM-Agent-Daemon wird gestartet … Proc/Daemon.pm kann in @INC (@INC enthält: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) bei /usr/sbin/mmm_agentd Zeile 7 nicht gefunden werden.
BEGIN fehlgeschlagen – Kompilierung bei /usr/sbin/mmm_agentd Zeile 7 abgebrochen.
fehlgeschlagen

Lösung:

# cpanProc::Daemon
# cpan Log::Log4perl
# /etc/init.d/mysql-mmm-agent start
Daemon-Bin: „/usr/sbin/mmm_agentd“
Daemon-PID: „/var/run/mmm_agentd.pid“
MMM-Agent-Daemon wird gestartet ... Ok
# netstat -antp | grep mmm_agentd
tcp 0 0 192.168.31.83:9989 0.0.0.0:* LISTEN 9693/mmm_agentd
Konfigurieren der Firewall
Firewall-Befehl --permanent --add-port=9989/tcp
Firewall-Befehl --reload
Bearbeiten Sie /etc/mysql-mmm/mmm_mon.conf auf dem Monitor-Host
includemmm_common.conf

<Monitor>
ip 127.0.0.1##Aus Sicherheitsgründen sollten Sie es so einrichten, dass es nur auf dem lokalen Rechner lauscht. mmm_mond lauscht standardmäßig auf 9988
pid_pfad /var/run/mmm_mond.pid
bin_pfad /usr/lib/mysql-mmm/
status_pfad/var/lib/misc/mmm_mond.status
ping_ips192.168.31.83,192.168.31.141,192.168.31.250,192.168.31.225#IP-Adressliste zum Testen der Netzwerkverfügbarkeit. Solange eine der Adressen angepingt werden kann, bedeutet dies, dass das Netzwerk normal ist. Geben Sie hier nicht die lokale Adresse ein.
auto_set_online 0#Stellen Sie die Zeit für den automatischen Online-Zugriff ein. Standardmäßig wird der Zugriff nach 60 Sekunden aktiviert. Der Standardwert ist 60 Sekunden. Wenn Sie den Wert hier auf 0 setzen, wird der Zugriff sofort aktiviert.
</monitor>

<Standard prüfen>
Prüfperiode 5
trap_perioden 10
Zeitüberschreitung 2
#restart_after 10000
max_backlog 86400
</prüfen>
Prüfperiode
Beschreibung: Der Standardprüfzeitraum beträgt 5 Sekunden.
Standardwert: 5 s
trap_period
Beschreibung: Wenn ein Knoten trap_perioden lang nicht erkannt wird, gilt er als ausgefallen.
Standardwert: 10 s
Time-out
Beschreibung: Timeout-Zeit prüfen Standardwert: 2s
Neustart nach
Beschreibung: Starten Sie den Prüfvorgang neu, nachdem die restart_after-Prüfungen abgeschlossen sind. Standardwert: 10000
max_backlog
Beschreibung: Zeichnet die maximale Anzahl der Überprüfungen des rep_backlog-Protokolls auf. Standardwert: 60

<Host-Standard>
monitor_usermmm_monitor#Überwacht den Benutzer des DB-Servers
monitor_password 123456#Überwachen Sie das Passwort des DB-Servers
</host>
debug 0#debug 0 ist der Normalmodus, 1 ist der Debugmodus, um den Überwachungsprozess zu starten:
Fügen Sie den folgenden Inhalt unter #!/bin/sh in die Skriptdatei /etc/init.d/mysql-mmm-agent ein
Quelle /root/.bash_profile
Fügen Sie es als Systemdienst hinzu und richten Sie es so ein, dass es automatisch gestartet wird
#chkconfig --add mysql-mmm-monitor
#chkconfigmysql-mmm-monitor ein
#/etc/init.d/mysql-mmm-monitor starten

Startfehler:

MMM Monitor-Daemon wird gestartet: Proc/Daemon.pm kann in @INC (@INC enthält: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) bei /usr/sbin/mmm_mond, Zeile 11, nicht gefunden werden.
BEGIN fehlgeschlagen – Kompilierung bei /usr/sbin/mmm_mond Zeile 11 abgebrochen.
fehlgeschlagen
Lösung: Installieren Sie die folgenden Perl-Bibliotheken
#cpanProc::Daemon
#cpan Log::Log4perl
[root@monitor1 ~]# /etc/init.d/mysql-mmm-monitor start
Daemon-Bin: „/usr/sbin/mmm_mond“
Daemon-PID: „/var/run/mmm_mond.pid“
MMM Monitor-Daemon wird gestartet: Ok
[root@monitor1 ~]# netstat -anpt | grep 9988
tcp 0 0 127.0.0.1:9988 0.0.0.0:* LISTEN 8546/mmm_mond
Hinweis 1: Wenn die Konfigurationsdatei auf der Datenbankseite oder der Überwachungsseite geändert wird, müssen der Agentenprozess und der Überwachungsprozess neu gestartet werden.
Hinweis 2: MMM-Startreihenfolge: Zuerst den Monitor starten, dann den Agenten starten

Überprüfen Sie den Clusterstatus:

[root@monitor1 ~]# mmm_control anzeigen
master1(192.168.31.83) master/ONLINE. Rollen: writer(192.168.31.2)
master2(192.168.31.141) master/ONLINE. Rollen: Leser(192.168.31.5)
Slave1(192.168.31.250) Slave/ONLINE. Rollen: Leser(192.168.31.4)
Slave2(192.168.31.225) Slave/ONLINE. Rollen: Leser(192.168.31.3)

Wenn der Serverstatus nicht ONLINE ist, können Sie beispielsweise den folgenden Befehl verwenden, um den Server online zu bringen:

#mmm_controlset_online Hostname

Beispiel: [root@monitor1 ~]#mmm_controlset_onlinemaster1
Aus der obigen Anzeige können wir ersehen, dass sich der VIP der Schreibanforderung auf Master1 befindet und alle Slave-Knoten Master1 auch als Master-Knoten betrachten.
Überprüfen Sie, ob VIP aktiviert ist
[root@master1 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscpfifo_fast Status UP qlen 1000
Link/Ether 00:0c:29:6d:2f:82 brdff:ff:ff:ff:ff:ff:ff
inet 192.168.31.83/24 brd 192.168.31.255 Bereich global eno16777736
valid_lft für immer preferred_lft für immer
inet 192.168.31.2/32 Bereich global eno16777736
valid_lft für immer preferred_lft für immer
inet6 fe80::20c:29ff:fe6d:2f82/64 Bereichslink
valid_lft für immer preferred_lft für immer
[root@master2 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscpfifo_fast Status UP qlen 1000
Link/Ether 00:0c:29:75:1a:9c brdff:ff:ff:ff:ff:ff
inet 192.168.31.141/24 brd 192.168.31.255 Bereich global dynamisch eno16777736
valid_lft 35850 Sek. bevorzugt_lft 35850 Sek.
inet 192.168.31.5/32 Bereich global eno16777736
valid_lft für immer preferred_lft für immer
inet6 fe80::20c:29ff:fe75:1a9c/64 Bereichslink
valid_lft für immer preferred_lft für immer
[root@slave1 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscpfifo_fast Status UP qlen 1000
Link/Ether 00:0c:29:02:21:19 brdff:ff:ff:ff:ff:ff:ff
inet 192.168.31.250/24 brd 192.168.31.255 Bereich global dynamisch eno16777736
valid_lft 35719 Sek. bevorzugt_lft 35719 Sek.
inet 192.168.31.4/32 Bereich global eno16777736
valid_lft für immer preferred_lft für immer
inet6 fe80::20c:29ff:fe02:2119/64 Bereichslink
valid_lft für immer preferred_lft für immer
[root@slave2 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscpfifo_fast Status UP qlen 1000
Link/Ether 00:0c:29:e2:c7:fa brdff:ff:ff:ff:ff:ff
inet 192.168.31.225/24 brd 192.168.31.255 Bereich global dynamisch eno16777736
valid_lft 35930 Sek. bevorzugt_lft 35930 Sek.
inet 192.168.31.3/32 Bereich global eno16777736
valid_lft für immer preferred_lft für immer
inet6 fe80::20c:29ff:fee2:c7fa/64 Bereichslink
valid_lft für immer preferred_lft für immer
Überprüfen Sie die Richtung des Haupt-MySQL auf den Hosts Master2, Slave1 und Slave2
mysql> Slave-Status anzeigen\G;
*************************** 1. Reihe ***************************
Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
Master_Host: 192.168.31.83
Master_User: rep
Master_Port: 3306
Verbindungswiederholung: 60

MMM-Hochverfügbarkeitstests:

Der Server verwendet die VIP-Adresse zum Lesen und Schreiben. Wenn ein Fehler auftritt, wandert die VIP zu anderen Knoten und stellt Dienste von anderen Knoten bereit.
Überprüfen Sie zunächst den Status des gesamten Clusters. Sie können sehen, dass der gesamte Cluster normal ist
[root@monitor1 ~]# mmm_control anzeigen
master1(192.168.31.83) master/ONLINE. Rollen: writer(192.168.31.2)
master2(192.168.31.141) master/ONLINE. Rollen: Leser(192.168.31.5)
Slave1(192.168.31.250) Slave/ONLINE. Rollen: Leser(192.168.31.4)
Slave2(192.168.31.225) Slave/ONLINE. Rollen: Leser(192.168.31.3)
Simulieren Sie die Ausfallzeit von Master1, stoppen Sie den MySQL-Dienst manuell und beobachten Sie das Monitorprotokoll. Das Protokoll von Master1 lautet wie folgt:
[root@monitor1 ~]# tail -f /var/log/mysql-mmm/mmm_mond.log
2017/01/09 22:02:55 WARNUNG Überprüfen Sie, ob „rep_threads“ auf „master1“ in unbekanntem Status ist! Meldung: UNBEKANNT: Verbindungsfehler (Host = 192.168.31.83:3306, Benutzer = mmm_monitor)! Verbindung zum MySQL-Server auf „192.168.31.83“ nicht möglich (111)
2017/01/09 22:02:55 WARNUNG Überprüfen Sie, ob „rep_backlog“ auf „master1“ in unbekanntem Status ist! Meldung: UNBEKANNT: Verbindungsfehler (Host = 192.168.31.83:3306, Benutzer = mmm_monitor)! Keine Verbindung zum MySQL-Server auf „192.168.31.83“ möglich (111)
2017/01/09 22:03:05 FEHLER Die Prüfung von „mysql“ auf „master1“ ist seit 10 Sekunden fehlgeschlagen! Meldung: FEHLER: Verbindungsfehler (Host = 192.168.31.83:3306, Benutzer = mmm_monitor)! Verbindung zum MySQL-Server auf „192.168.31.83“ kann nicht hergestellt werden (111)
09.01.2017 22:03:07 FATAL Status des Hosts „Master1“ von ONLINE auf HARD_OFFLINE geändert (Ping: OK, MySQL: nicht OK)
09.01.2017 22:03:07 INFO Alle Rollen vom Host „master1“ entfernen:
09.01.2017 22:03:07 INFO Rolle „Writer(192.168.31.2)“ vom Host „Master1“ entfernt
09.01.2017 22:03:07 INFO Die verwaiste Rolle „writer(192.168.31.2)“ wurde „master2“ zugewiesen.
Den neuesten Status des Clusters anzeigen
[root@monitor1 ~]# mmm_control anzeigen
master1(192.168.31.83) master/HARD_OFFLINE. Rollen:
master2(192.168.31.141) master/ONLINE. Rollen: Leser(192.168.31.5), Schreiber(192.168.31.2)
Slave1(192.168.31.250) Slave/ONLINE. Rollen: Leser(192.168.31.4)
Slave2(192.168.31.225) Slave/ONLINE. Rollen: Leser(192.168.31.3)
Aus den angezeigten Ergebnissen können wir ersehen, dass sich der Status von Master1 von ONLINE zu HARD_OFFLINE geändert hat und der Schreib-VIP auf den Master2-Host übertragen wurde.
Überprüfen Sie den Status aller DB-Server-Cluster
[root@monitor1 ~]# mmm_control prüft alle
master1 ping [letzte Änderung: 2017/01/09 21:31:47] OK
master1 mysql [letzte Änderung: 2017/01/09 22:03:07] FEHLER: Verbindungsfehler (Host = 192.168.31.83:3306, Benutzer = mmm_monitor)! Verbindung zum MySQL-Server auf '192.168.31.83' kann nicht hergestellt werden (111)
master1 rep_threads [letzte Änderung: 2017/01/09 21:31:47] OK
master1 rep_backlog [letzte Änderung: 2017/01/09 21:31:47] OK: Backlog ist null
slave1 ping [letzte Änderung: 2017/01/09 21:31:47] OK
slave1mysql [letzte Änderung: 2017/01/09 21:31:47] OK
slave1 rep_threads [letzte Änderung: 2017/01/09 21:31:47] OK
slave1 rep_backlog [letzte Änderung: 2017/01/09 21:31:47] OK: Backlog ist null
master2 ping [letzte Änderung: 09.01.2017 21:31:47] OK
master2 mysql [letzte Änderung: 2017/01/09 21:57:32] OK
master2 rep_threads [letzte Änderung: 2017/01/09 21:31:47] OK
master2 rep_backlog [letzte Änderung: 2017/01/09 21:31:47] OK: Backlog ist null
slave2 ping [letzte Änderung: 2017/01/09 21:31:47] OK
slave2mysql [letzte Änderung: 2017/01/09 21:31:47] OK
slave2 rep_threads [letzte Änderung: 2017/01/09 21:31:47] OK
slave2 rep_backlog [letzte Änderung: 2017/01/09 21:31:47] OK: Backlog ist null
Aus dem Obigen können wir ersehen, dass Master1 angepingt werden kann, was bedeutet, dass nur der Dienst ausgefallen ist.

Zeigen Sie die IP-Adresse des Master2-Hosts an:

[root@master2 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscpfifo_fast Status UP qlen 1000
Link/Ether 00:0c:29:75:1a:9c brdff:ff:ff:ff:ff:ff
inet 192.168.31.141/24 brd 192.168.31.255 Bereich global dynamisch eno16777736
valid_lft 35519 Sek. bevorzugt_lft 35519 Sek.
inet 192.168.31.5/32 Bereich global eno16777736
valid_lft für immer preferred_lft für immer
inet 192.168.31.2/32 Bereich global eno16777736
valid_lft für immer preferred_lft für immer
inet6 fe80::20c:29ff:fe75:1a9c/64 Bereichslink
valid_lft für immer preferred_lft für immer
Slave1-Host:
mysql> Slave-Status anzeigen\G;
*************************** 1. Reihe ***************************
Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
Master_Host: 192.168.31.141
Master_User: rep
Master_Port: 3306
Slave2-Host:
mysql> Slave-Status anzeigen\G;
*************************** 1. Reihe ***************************
Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
Master_Host: 192.168.31.141
Master_User: rep
Master_Port: 3306
Starten Sie den MySQL-Dienst des Master1-Hosts und beobachten Sie das Monitorprotokoll. Das Protokoll von Master1 lautet wie folgt:
[root@monitor1 ~]# tail -f /var/log/mysql-mmm/mmm_mond.log
09.01.2017 22:16:56 INFO Überprüfen Sie, ob „mysql“ auf „Master1“ in Ordnung ist!
09.01.2017 22:16:56 INFO Überprüfen Sie, ob „rep_backlog“ auf „master1“ in Ordnung ist!
09.01.2017 22:16:56 INFO Überprüfen Sie, ob „rep_threads“ auf „master1“ in Ordnung ist!
09.01.2017 22:16:59 FATAL Der Status des Hosts „master1“ wurde von HARD_OFFLINE in AWAITING_RECOVERY geändert.
Oben sehen Sie, dass sich der Status von Master1 von „hard_offline“ zu „awaiting_recovery“ ändert. Verwenden Sie den folgenden Befehl, um den Server online zu bringen:
[root@monitor1 ~]#mmm_controlset_onlinemaster1
Den neuesten Status des Clusters anzeigen
[root@monitor1 ~]# mmm_control anzeigen
master1(192.168.31.83) master/ONLINE. Rollen:
master2(192.168.31.141) master/ONLINE. Rollen: Leser(192.168.31.5), Schreiber(192.168.31.2)
Slave1(192.168.31.250) Slave/ONLINE. Rollen: Leser(192.168.31.4)
Slave2(192.168.31.225) Slave/ONLINE. Rollen: Leser(192.168.31.3)
Sie können sehen, dass die Masterdatenbank den Master beim Start nicht übernimmt, bis der vorhandene Master wieder ausfällt.
Zusammenfassen
(1) Der Ausfall des Masterknotens des Master2-Kandidaten hat keine Auswirkungen auf den Status des Clusters, sondern entfernt lediglich den Lesestatus des Master2-Kandidatenknotens.
(2) Wenn der Masterknoten Master1 ausfällt, übernimmt der Masterknotenkandidat Master2 die Schreibrolle. Slave1 und Slave2 verweisen zur Replikation auf die neue Masterbibliothek Master2. Slave1 und Slave2 ändern Master automatisch in Master2.
(3) Wenn die Masterdatenbank von Master1 abstürzt und die Replikationsanwendung von Master2 hinter Master1 zurückbleibt, werden die Daten vom Master beschreibbar, und der Datenmaster kann zu diesem Zeitpunkt keine Konsistenz garantieren.
Wenn Master2, Slave1 und Slave2 hinter Master1 zurückbleiben und Master1 abstürzt, warten Slave1 und Slave2, bis die Daten mit db1 gleichziehen, bevor sie zur Replikation erneut auf den neuen Masterknoten2 verweisen. Zu diesem Zeitpunkt kann die Konsistenz der Datensynchronisierung nicht garantiert werden.
(4) Wenn die MMM-Hochverfügbarkeitsarchitektur verwendet wird, ist die Konfiguration der Master- und Master-Slave-Knoten identisch und die Halbsynchronisierung wird aktiviert, um die Sicherheit weiter zu verbessern, oder MariaDB/MySQL5.7 wird für die Multithread-Slave-Replikation verwendet, um die Replikationsleistung zu verbessern.

Anhang:

1. Logdateien:
Protokolldateien sind häufig der Schlüssel zur Fehleranalyse. Sie müssen daher gut mit der Verwendung von Protokolldateien zur Problemanalyse vertraut sein.
DB-Seite: /var/log/mysql-mmm/mmm_agentd.log
Überwachungsende: /var/log/mysql-mmm/mmm_mond.log
2. Befehlsdatei:
mmm_agentd: Startdatei des DB-Agent-Prozesses
mmm_mond: Startdatei für den Überwachungsprozess
mmm_backup: Sicherungsdateien
mmm_restore: Dateien wiederherstellen
mmm_control: Befehlsdatei für Überwachungsvorgänge
Es gibt nur das Programm mmm_agentd auf der DB-Serverseite und die anderen befinden sich auf der Monitorserverseite.
3. Verwendung von mmm_control
Mit dem Programm mmm_control können Sie den Clusterstatus überwachen, Schreiber wechseln, Online-/Offline-Vorgänge festlegen usw.
Gültige Befehle sind:
Hilfe - diese Nachricht anzeigen #Hilfeinformationen
Ping - Ping-Monitor #pingen Sie den aktuellen Cluster, um zu sehen, ob er normal ist
anzeigen - Status anzeigen #Cluster-Online-Statusprüfung
checks [<host>|all [<check>|all]] – Check-Status anzeigen#Überwachungs- und Prüfvorgänge ausführen
set_online<host> - setze Host <host> online #Setze den Host auf online
set_offline<host> - setze Host <host> offline #Setze den Host auf offline
Modus - aktuellen Modus drucken. #Den aktuellen Modus ausdrucken
set_active – in den aktiven Modus wechseln.

set_manual – in den manuellen Modus wechseln.
set_passive – in den passiven Modus wechseln.
move_role [--force] <role><host> – verschiebt die exklusive Rolle <role> zum Host <host>. #Entfernt den Writer-Server zum angegebenen Host-Server (Verwenden Sie --force nur, wenn Sie wissen, was Sie tun!)
set_ip<ip><host> – Rolle mit IP<ip> auf Host <host> setzen
Überprüfen Sie den Status aller DB-Server-Cluster:
[root@monitor1 ~]# mmm_control prüft alle
Zu den zu prüfenden Elementen gehören: Ping, ob MySQL normal ausgeführt wird, ob der Replikationsthread normal ist usw. Überprüfen Sie den Onlinestatus der Clusterumgebung:
[root@monitor1 ~]# mmm_control anzeigen
Führen Sie den Offlinevorgang auf dem angegebenen Host aus:
[root@monitor1 ~]# mmm_controlset_offline slave2
Führen Sie den Onlinevorgang auf dem angegebenen Host aus:
[root@monitor1 ~]# mmm_controlset_online slave2
Schreibschalter ausführen (manueller Schalter):
Den Master anzeigen, der dem aktuellen Slave entspricht
[root@slave2 ~]# mysql -uroot -p123456 -e 'Slave-Status anzeigen\G;'
mysql: [Warnung] Die Verwendung eines Passworts in der Befehlszeilenschnittstelle kann unsicher sein.
*************************** 1. Reihe ***************************
Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
Master_Host: 192.168.31.141
Um den Writer zu wechseln, stellen Sie sicher, dass für das Writer-Attribut in der Datei mmm_common.conf der entsprechende Host konfiguriert ist. Andernfalls ist der Wechsel nicht möglich.
[root@monitor1 ~]# mmm_controlmove_role Schriftsteller master1
OK: Die Rolle „Writer“ wurde von „Master2“ nach „Master1“ verschoben. Jetzt können Sie etwas warten und die Informationen zu den neuen Rollen prüfen!
[root@monitor1 ~]# mmm_control anzeigen
master1(192.168.31.83) master/ONLINE. Rollen: writer(192.168.31.2)
master2(192.168.31.141) master/ONLINE. Rollen: Leser(192.168.31.5)
Slave1(192.168.31.250) Slave/ONLINE. Rollen: Leser(192.168.31.4)
Slave2(192.168.31.225) Slave/ONLINE. Rollen: Leser(192.168.31.3)
Der gesicherte Slave wechselte automatisch zum neuen Master
[root@slave2 ~]# mysql -uroot -p123456 -e 'Slave-Status anzeigen\G;'
mysql: [Warnung] Die Verwendung eines Passworts in der Befehlszeilenschnittstelle kann unsicher sein.
*************************** 1. Reihe ***************************
Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
Master_Host: 192.168.31.83

4. Andere Verarbeitungsprobleme

Wenn Sie nicht möchten, dass der Writer von Master auf Backup umschaltet (einschließlich der Master-Slave-Verzögerung, die auch den Writer-VIP zum Umschalten veranlasst), können Sie Backup in <role write> entfernen, wenn Sie /etc/mysql-mmm/mmm_common.conf konfigurieren.
<Rolle Autor>#Autor-Rollenkonfiguration
hosts master1 #Hier ist nur ein Host konfiguriert
ips 192.168.31.2#Virtuelle IP für externe Schreibvorgänge
Modus exklusiv #exklusiv bedeutet, dass nur ein Master existieren darf, d. h. es kann nur eine Schreib-IP bereitgestellt werden
</Rolle>
Auf diese Weise wird bei einem Ausfall von Master1 der Schreibvorgang des Writers nicht auf den Master2-Server umgeschaltet und der Slave zeigt nicht auf den neuen Master. Zu diesem Zeitpunkt stellt der aktuelle MMM Schreibdienste für die Außenwelt bereit.

5. Zusammenfassung

1. Die virtuelle IP, die externes Lesen und Schreiben ermöglicht, wird vom Monitorprogramm gesteuert. Wenn der Monitor nicht gestartet wird, wird dem DB-Server keine virtuelle IP zugewiesen. Wenn jedoch eine virtuelle IP zugewiesen wurde, wird diese nicht sofort geschlossen, wenn das Monitorprogramm die zuvor zugewiesene virtuelle IP schließt, und externe Programme können weiterhin eine Verbindung herstellen und darauf zugreifen (solange das Netzwerk nicht neu gestartet wird). Dies hat den Vorteil, dass die Zuverlässigkeitsanforderungen an den Monitor geringer sind. Wenn jedoch zu diesem Zeitpunkt einer der DB-Server ausfällt, kann der Wechsel nicht verarbeitet werden, d. h. die ursprüngliche virtuelle IP bleibt unverändert und die virtuelle IP der ausgefallenen DB wird unzugänglich.

2. Das Agentenprogramm wird vom Monitorprogramm gesteuert, um Schreibumschaltung, Slave-Umschaltung und andere Vorgänge abzuwickeln. Wenn der Monitorprozess heruntergefahren wird, kann der Agentenprozess Fehler nicht selbst behandeln.

3. Das Überwachungsprogramm ist für die Überwachung des Status des Datenbankservers verantwortlich, einschließlich der MySQL-Datenbank, ob der Server ausgeführt wird, ob der Replikationsthread normal ist, die Master-Slave-Verzögerung usw.; es wird auch zur Steuerung des Agentenprogramms zur Fehlerbehandlung verwendet.

4. Der Monitor überwacht alle paar Sekunden den Status des DB-Servers. Wenn der DB-Server von einem Fehler- in einen Normalzustand gewechselt ist, versetzt ihn der Monitor nach 60 Sekunden automatisch in den Online-Zustand (der Standardwert beträgt 60 Sekunden und kann auf andere Werte eingestellt werden). Dies wird durch den Konfigurationsdateiparameter „auto_set_online“ des Überwachungsendes bestimmt. Es gibt drei Zustände des Cluster-Servers: HARD_OFFLINE→AWAITING_RECOVERY→online
5. Standardmäßig steuert der Monitor mmm_agent, um den Nur-Lese-Zugriff des Writer-DB-Servers auf OFF und den Nur-Lese-Zugriff anderer DB-Server auf ON zu setzen. Aus Gründen der Genauigkeit können Sie daher read_only=1 zu den my.cnf-Dateien aller Server hinzufügen, um den Writer und den Lesezugriff durch den Monitor zu steuern. Der Root-Benutzer und der Replikationsbenutzer sind vom Parameter read_only nicht betroffen.