Einführung in die Überwachung des MySQL MHA-Betriebsstatus

1. Projektbeschreibung

1.1 Hintergrund

MHA (Master HA) ist ein Open-Source-MySQL-Hochverfügbarkeitsprogramm, das eine automating master failover MySQL Master-Slave-Replikationsarchitektur bereitstellt. Wenn MHA master Masterknotenfehler erkennt, wird der slave mit den neuesten Daten zum neuen master befördert. Voraussetzung für automatisches FailOver ist, dass MHA gestartet und ausgeführt wird. In einer Produktionsumgebung kommt es vor, dass der MySQL Masterknoten nicht rechtzeitig gestartet wird oder unvorhergesehen angehalten wird, ohne dass dies bemerkt wird. Dies führt dazu, dass bei einer Anomalie kein automatisches FailOver erfolgt, die Produktion beeinträchtigt wird oder die Verarbeitungszeit verlängert wird, wodurch der Fehler eskaliert.

Darüber hinaus ändert sich nach MHA FailOver der Betriebsstatus von MHA von „ is running (0: PING_OK) auf „ stopped (2: „NICHT_LÄUFT“). Anhand der Änderung des Betriebsfeedbackergebnisses lässt sich feststellen, ob möglicherweise ein Master-Slave-Wechsel stattgefunden hat. Kann als Warning betrachtet werden.

Zusammenfassend ist es notwendig, den Betriebszustand von MHA zu überwachen.

1.2 Implementierungsdesign

MHA wird auf dem Manager Knoten ausgeführt und ein Manager Knoten kann Dutzende von Clustern verwalten. Derzeit besteht unser Überwachungssystem aus Telegraf + InfluxDB + Grafana , daher müssen wir Telegraf auf Manager -Knoten bereitstellen, um den Laufstatus von MHA zu erfassen und in InfluxDB zu speichern. Fügen Sie im vorhandenen Grafana MySQL Dashboard ein masterha_check_status 的panel hinzu.

1.2.1 Bisherige Methoden

Im siebten Teil des Artikels „Am Beispiel der Überwachung des Status des MongoDB-Replikatsatzes, um zu sehen, wie das Exec-Eingabe-Plugin im Telegraf System geschrieben und bereitgestellt wird“ haben wir eine Methode zum Implementieren MySQL MHA Überwachung vorgestellt. Diese Methode erfordert jedoch manuelle Wartung für jeden Cluster und die automatische Erkennungsfunktion ist nicht gut genug, was die Wartungskosten erhöht, insbesondere wenn die Gruppe viele MHA-Cluster hat.

1.2.2 Optimierte Methode

Manager -Knoten stellt für jeden überwachten MHA-Cluster eine dedizierte Konfigurationsdatei bereit. Die optimierte Überwachungsmethode erkennt und passt die Überwachung automatisch anhand der Konfigurationsdatei an, sodass keine individuelle Konfiguration und Wartung erforderlich ist.

Die Bereitstellungsschritte lauten wie folgt:

2. Einzelheiten zur Umsetzung

2.1 Bearbeiten der ausführbaren Python-Datei

Die ausführbare Datei ist telegraf_checkmhastatus.py

#!/usr/bin/python
# -*- Kodierung: UTF-8 -*-

 

Betriebssystem importieren
io importieren
erneut importieren
ConfigParser importieren

Pfad='/cnf/mhacnf'
#fout=open('Name der Ausgabedatei','w')
für Name in os.listdir(Pfad):
  Pfadname = os.path.join(Pfad,Name)
 ## print(Pfadname)
 ## drucken(Name)
  config = ConfigParser.ConfigParser()
  versuchen:
    config.read(Pfadname)
    server_item = konfiguration.abschnitte()
    server1_host = '' ##Knoten 1 in der MHA-cnf-Konfigurationsdatei
    server2_host = '' ##Knoten 2 in der MHA-cnf-Konfigurationsdatei
    server3_host = '' ##Knoten 3 in der MHA-cnf-Konfigurationsdatei
    mha_cnf_remark = ''
    wenn „server1“ im Server-Element:
      server1_host = config.get('server1','Hostname')
    anders:
       server1_host = ''
       mha_cnf_remark = mha_cnf_remark + 'Server1 ist nicht konfiguriert;'
    wenn „server2“ im Serveritem:
      server2_host = config.get('server2','Hostname')
    anders:
      server2_host = ''
      mha_cnf_remark = mha_cnf_remark + 'Server2 ist nicht konfiguriert;'
    wenn „server3“ im Server-Element:
      server3_host = config.get('server3','Hostname')

      ##drucken(mha_cnf_remark)
  außer Ausnahme als e:
    drucken(e)

  mha_status_result = ''
  wenn server1_host <> '' und server2_host <> '':
    cmd_mha_status ='/usr/local/bin/masterha_check_status --conf='+Pfadname
    mit os.popen(cmd_mha_status) als mha_status:
      mha_status_result = mha_status.read()
      wenn „running(0:PING_OK)“ in mha_status_result:
        drucken('masterha_check_status,server='+server1_host+' Status=1i')
        drucken('masterha_check_status,server='+server2_host+' Status=1i')
      wenn „gestoppt(2:NICHT_LÄUFT)“ in mha_status_result:
      ##anders:
        drucken('masterha_check_status,server='+server1_host+' Status=0i')
        drucken('masterha_check_status,server='+server2_host+' Status=0i')

veranschaulichen:

• (1) Durchsuchen Sie die Dateien im Verzeichnis /cnf/mhacnf (vorausgesetzt, dass sich die Konfigurationsdateien der MHA-Konfigurationsdateien in diesem Verzeichnis befinden).
• (2) Führen Sie masterha_check_status --cong = XXXX，XXXX die spezifische Konfigurationsdatei ist. Bestimmen Sie die Laufergebnisse.
• (3) Besorgen Sie sich MHA-Clusterknoten.
• (4) Da unsere MHA-Cluster alle aus einem Master und einem Slave bestehen, gibt es nur eine Situation: if server1_host <> '' and server2_host <> '':. Sie können dies entsprechend Ihren Anforderungen und spezifischen Szenarien ändern.
• (5) Die Daten werden in measurement namens masterha_check_status mit Tag Key host und server gespeichert. Wenn der Vorgang erfolgreich war, Status=1 , andernfalls ist Status=0 .
• (6) Die Server entsprechenden Daten sind Server IP (beachten Sie, dass diese bei der Konfiguration grafana zugeordnet wird).

2.2 Telegraf-Datei ändern

Das Standardverzeichnis der Datei ist /etc/telegraf/ und die Standarddatei ist telegraf.conf .

Betten Sie die ausführbare Datei in telegraf.conf ein, gesteuert durch python .

Der Code lautet wie folgt:

[[Eingaben.exec]]
  ##Befehls-Array
  Befehle = ["python /data/check_mha_status/check_mha_status.py",]
  Zeitüberschreitung = "60 s"
  Datenformat = "Zustrom"

2.3 Ändern Sie das laufende Konto des Telegraf-Dienstes

Das Standard-Startkonto telegraf Dienstes ist telegraf . Es werden jedoch Python und ausführbare python Dateien aufgerufen, daher müssen die Berechtigungen geändert werden. Aktualisieren Sie der Einfachheit halber das laufende Konto des telegraf service und ändern Sie es in root . 🙂

Ändern Sie telegraf.service , der Standardpfad ist /usr/lib/systemd/system/telegraf.service .

Der geänderte Code lautet wie folgt:

[Einheit]
Beschreibung=Der Plugin-gesteuerte Server-Agent zum Melden von Metriken in InfluxDB
Dokumentation=https://github.com/influxdata/telegraf
Nach=Netzwerk.Ziel

[Service]
Umgebungsdatei=-/etc/default/telegraf
##Benutzer=telegraf
Benutzer=root
ExecStart=/usr/bin/telegraf -config /etc/telegraf/telegraf.conf -config-directory /etc/telegraf/telegraf.d $TELEGRAF_OPTS
ExecReload=/bin/kill -HUP $MAINPID
Neustart=bei Fehler
RestartForceExitStatus=SIGPIPE
KillMode=Kontrollgruppe

[Installieren]
WantedBy=Mehrbenutzer.Ziel

2.4 Telegraf-Dienst starten

service telegraf start ####Starten Sie den Dienstservice telegraf status ####Überprüfen Sie den Dienststatusservice telegraf stop ####Beenden Sie den Dienst

2.5 Grafana konfigurieren und Panel hinzufügen

Da telegraf MySQL Instanzknotens auch seine eigenen Daten meldet, wie beispielsweise die Anzahl der MySQL -Verbindungen, TPS , QPS , Master-Slave-Status, Latenz, Ressourcen (CPU, Speicher, Festplatte, IOWait) usw., befinden sich diese Indikatoren auf einem Dashboard , und der neu erfasste MHA-Laufstatus ist ein neu hinzugefügter MySQL-Indikator, sodass der MHA-Laufstatus als Panel des vorhandenen MySQL Dashboard verwendet werden sollte.

Die auf dem MySQL-Instanzknoten gemeldeten Daten sind host und instance (Server-IP: Port) jedes Knotens; während die vom MHA-Laufstatus gemeldeten Daten host manager und die Server-IP jeder Instanz sind. Daher ist eine Integration in ein Dashboard basierend auf einer Host-Zuordnung nicht möglich (da keine Zuordnung besteht). Die Zuordnung ist nur über instance (Server-IP: Port) und Server -IP möglich.

Regulieren Sie zunächst die Instanz (Server-IP:Port) und entfernen Sie die Portdaten. Fügen Sie dazu eine Grafana-Variable --server_ip wie folgt hinzu :

Beachten Sie, dass die oben genannte Datenquelle aus measurement mysql stammt.

Fügen Sie dann eine weitere grafana Variable hinzu --mha_server . Beachten Sie, dass diese von der oben angegebenen Variable server_ip abhängt.

Auf diese Weise werden die beiden measurement mysql und masterha_check_status miteinander verknüpft und können verknüpft werden.

Fügen Sie abschließend die panel wie folgt hinzu.

Die SQL-Anweisung lautet wie folgt:

Wählen Sie Mittelwert ("Status") aus "masterha_check_status", wobei ("Server" =~ /^$mha_server$/) und $timeFilter GROUP BY Zeit (1m) Füllung (null)

3. Umsetzung

Der Laufstatus ist 1 und der abnormale oder geschlossene Status ist 0.

Sie können auch Alarm hinzufügen, z. B. per E-Mail, WeChat, DingTalk usw., auf die ich hier jedoch nicht näher eingehen werde.

Und noch etwas:

Aufgrund der optimierten Überwachungsmethode wird die Überwachung automatisch erkannt und entsprechend der Konfigurationsdatei angepasst. Wenn daher ein neues MHA hinzugefügt wird und der Vorgang lange dauert, beispielsweise 10 Minuten, meldet die vorhandene MHA Überwachung möglicherweise einen Fehler oder Alarm.

Um diese Situation zu vermeiden, wird empfohlen, eine neue MHA Konfigurationsdatei hinzuzufügen und sie dann im MHA-Konfigurationsdateiverzeichnis abzulegen. Alternativ können Sie die Konfigurationsdatei zunächst in einem anderen Verzeichnis platzieren und sie dann als letzten Schritt nach Abschluss MHA -Konfiguration in das Verzeichnis /cnf/mhacnf verschieben.

Dies ist das Ende dieses Artikels über die Überwachung des Betriebsstatus von MySQL MHA. Weitere relevante Inhalte zur Überwachung des Betriebsstatus von MySQL MHA finden Sie in den vorherigen Artikeln von 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!