Proaktive MySQL-Überwachung (Developer Studio/Advisors Angle)

Die proaktive Überwachung Ihrer MySQL-Datenbank ist heutzutage unerlässlich. Es spielt eine entscheidende und bedeutende Rolle bei der Verwaltung und Kontrolle Ihrer Datenbank, insbesondere für Ihre Produktionscluster. Das Fehlen spezifischer Informationen, die für die Verbesserung Ihrer Datenbank von Vorteil wären, oder das Versäumnis, die Grundursache für auftretende Probleme zu identifizieren, kann zu extremen Schwierigkeiten führen, sie zu beheben oder sich von ihren glorreichen Tagen zu erholen.

Die proaktive Überwachung Ihrer MySQL-Datenbank ermöglicht Ihrem Team, die Leistung Ihrer Datenbankdienste zu verstehen. Funktioniert und liefert es basierend auf der erwarteten Arbeitslast? Verfügen Sie über genügend Ressourcen, damit der Server basierend auf der Arbeitslast, die er derzeit verarbeitet, leistungsfähig ist? Die proaktive Überwachung wendet Dinge an, die Katastrophen verhindern oder Ihre Datenbank beschädigen sollen, die Sie im Voraus benachrichtigen. Auf diese Weise können DBAs oder Administratoren wichtige Aufgaben ausführen, um Fehlfunktionen, Datenbeschädigungen, Sicherheitslücken und -angriffe oder unerwartete Abpraller des Datenverkehrs in Ihrem Datenbankcluster zu vermeiden. Indem diese sofort beachtet werden, muss das proaktive Monitoring für MySQL automatisiert werden und 24/7 ohne Unterbrechung laufen und es liegt an den DBAs, Devops, Administratoren zu entscheiden, ob basierend auf der Priorität der Aufgaben und wie wichtig es ist, ob es gewartet werden muss oder nur eine typische tägliche Routinearbeit.

Proaktives Monitoring mit ClusterControl

ClusterControl bietet einen vielfältigen Stil zur Überwachung Ihrer MySQL-Datenbankserver. Sein Ansatz ist vergleichbar mit anderen Enterprise-Monitoring-Tools und Cloud-Lösungen der Enterprise-Klasse. ClusterControl neigt dazu, alle Best Practices für die Verwaltung und Überwachung der Datenbanken anzuwenden, jedoch mit der Flexibilität zur Konfiguration, um die gewünschte Einrichtung basierend auf Ihrer Umgebung zu erreichen.

Wenn es um Alarme und Benachrichtigungen geht, hat ClusterControl einen gemischten Ansatz, für den es integrierte Alarme gibt, und dann gibt es die Advisors, über die wir in diesem Blog mehr diskutieren werden.

ClusterControl-Alarme für MySQL

Alarme weisen auf Probleme hin, die den Cluster als Ganzes beeinträchtigen oder beeinträchtigen könnten. Diese Schnittstelle bietet eine detaillierte Erläuterung des Problems zusammen mit der empfohlenen Maßnahme (falls verfügbar) zur Lösung des Problems. Jeder Alarm ist kategorisiert als:

• Cluster

• Cluster-Wiederherstellung

• Datenbankzustand

• Datenbankleistung

• Host

• Knoten

• Netzwerk

Ein Alarm kann bestätigt werden, indem das Feld Ignorieren? Kontrollkästchen. Bei Ignorierung wird keine Benachrichtigung per E-Mail gesendet. Ein Alarm kann nicht gelöscht oder verworfen werden, Sie können ihn jedoch aus der Liste ausblenden, indem Sie auf die Schaltfläche Ignorierte Alarme ausblenden klicken.

Siehe Beispiel-Screenshot unten,

Proaktivität mit ClusterControl

ClusterControl unterstützt die automatische Wiederherstellung, die reagiert, wenn eine Fehlererkennung aufgetreten ist. Die automatische Wiederherstellung mit ClusterControl ist eine der proaktivsten Funktionen, die im Katastrophenfall eine entscheidende Rolle spielt.

Die Aktivierung der automatischen Wiederherstellung ist für diese proaktive Überwachung erforderlich, die in verschiedenen Situationen reagiert, beispielsweise wenn der primäre MySQL-Knoten ausfällt.

In ClusterControl wird dies sofort beim Abhören der Verbindung erkannt mit dem Datenbankserver oder in diesem Fall dem primären Server. ClusterControl wird so schnell wie möglich reagieren und ein Failover anwenden.

Das Failover ist Teil der aktivierten Clusterwiederherstellung. Da beide Schaltflächen Cluster und Knoten aktiviert sind, folgt die Knotenwiederherstellung, wie Sie unten sehen.

Abhängig von der Erreichbarkeit der Knoten wird ClusterControl versuchen, kontinuierlich vorbeizukommen Stellen Sie eine Verbindung über SSH her und versuchen Sie, den Knoten zu erreichen, und versuchen Sie, ihn wiederherzustellen, indem Sie mit sysvinit oder systemd beginnen. Offensichtlich könnten Sie denken, dass es ein Failover anwendet und ClusterControl versucht, die ausgefallene primäre zu starten. Das könnte bedeuten, dass zwei Datenbankknoten verfügbar sind, richtig? Obwohl wahr, versetzt ClusterControl den ausgefallenen Primärknoten während der Wiederherstellung in einen schreibgeschützten Zustand. Siehe unten,

Obwohl es bestimmte Optionen gibt, die Sie festlegen können, um den Failover-Mechanismus zu verwalten, müssen Sie sollten Sie sich dazu auf unsere Dokumentation beziehen, da dies nicht der Schwerpunkt dieses Blogs ist.

Berater für Proaktivität mit ClusterControl verwenden

In ClusterControl finden Sie Advisors, indem Sie zu → Performance → Advisors gehen. ClusterControl-Advisors werden je nach dem zu überwachenden Cluster angewendet. Beispielsweise können eine MySQL-Replikation und MySQL mit Galera-Cluster, die entweder auf Percona oder MariaDB ausgeführt werden, Unterschiede aufweisen. Die MySQL Replication Advisors haben zum Beispiel Folgendes:

Während es sich in einem Galera-Cluster befindet, fügt es die Galera-spezifischen Berater wie unten gezeigt hinzu ,

Anpassen Ihrer ClusterControl-MySQL-Berater

Berater sind anpassbar und können an Ihre Bedürfnisse angepasst werden. Klicken Sie im obigen Screenshot der Advisors einfach auf Bearbeiten und Sie werden zu der einfachen IDE weitergeleitet, die wir in ClusterControl integriert haben.

Sie können auch Ihre eigenen ClusterControl-Berater erstellen. Sie können selbst nachschlagen, um mehr über das Erstellen zu erfahren, indem Sie Write Your First Advisor lesen, oder die zweiteilige Serie lesen, um mithilfe des Meltdown/Spectre-Erkennungsskripts Ihr eigenes zu erstellen.

Wie sind ClusterControl-Berater proaktiv?

Technisch fungieren ClusterControl-Berater meistens als Melder und buchstäblich als Ihre Berater. ClusterControl Advisors benachrichtigt Sie, wenn es ungewöhnliches Verhalten feststellt, wenn es die von ClusterControl standardmäßig festgelegten Basisschwellenwerte überschreitet. Üblicherweise sind die angewandten Schwellenwerte generische Werte. Diese allgemeinen Werte basieren auf Best Practices und der gängigsten und akzeptabelsten Workload- oder Umgebungskonfiguration. Die meisten Advisor bieten standardmäßig keine Alarme oder Warnmechanismen in der ClusterControl-Benutzeroberfläche. Es benachrichtigt Sie über die Benutzeroberfläche (siehe Beispiel-Screenshot des Ratgebers für den Binlog-Speicherort unten).

Wie bereits erwähnt, können Berater geändert und über unseren einfachen Editor oder unsere IDE bearbeitet werden. Beispielsweise stellt ClusterControl in einem MySQL-Replikationscluster einen Advisor für den Binlog-Speicherort bereit. Es erkennt, dass Binlogs im Datenverzeichnis gespeichert sind, wo es darauf hinweist, dass es sich außerhalb des Datenverzeichnisses befinden muss.

Nehmen wir ein Beispiel aus der Advisor-Liste und wählen Sie Advisor Verbindungen aktuell verwendet aus . Lassen Sie uns dies wie unten gezeigt bearbeiten,

oder gehen Sie alternativ zu

→ Manage → Developer Studio und wählen Sie die connection_used_pct.js wie unten gezeigt aus.

Indem Sie es proaktiver gestalten, indem Sie Alarme senden, können Sie es ändern und hinzufügen die folgenden Funktionen genau wie unten,

function myAlarm(title, message, recommendation)
{
  return Alarm::alarmId(
        Node,
      true,
        title,
        message,
        recommendation
  );
}

Wenn Sie hingegen den Schwellenwert auf 20 setzen, fügen Sie diese Zeilen unten direkt innerhalb der if-Bedingungsanweisung hinzu, wenn der Schwellenwert über dem angegebenen Schwellenwert liegt.

                 myAlarmId = myAlarm(TITLE, msg, ADVICE_WARNING);
                // Let's raise an alarm.
                host.raiseAlarm(myAlarmId, Warning);
Here's the complete script with my modifications in bold,
#include "common/mysql_helper.js"
var DESCRIPTION="This advisor calculates the percentage of threads_connected over max_connections,"
                " if the percentage is higher than 20% you will be notified,"
                " preventing your database server from becoming unstable.";
var WARNING_THRESHOLD=20;
var TITLE="Connections currently used";
var ADVICE_WARNING="You are using more than " + WARNING_THRESHOLD +
    "% of the max_connections."
    " Consider regulating load, e.g by using HAProxy. Using up all connections"
    " may render the database server unusable.";
var ADVICE_OK="The percentage of currently used connections is satisfactory." ;

function myAlarm(title, message, recommendation)
{
  return Alarm::alarmId(
        Node,
      true,
        title,
        message,
        recommendation
  );
}


function main()
{
    var hosts     = cluster::mySqlNodes();
    var advisorMap = {};
    for (idx = 0; idx < hosts.size(); ++idx)
    {
        host        = hosts[idx];
        map         = host.toMap();
        connected     = map["connected"];
        var advice = new CmonAdvice();
        print("   ");
        print(host);
        print("==========================");
        if (!connected)
        {
            print("Not connected");
            continue;
        }
        var Threads_connected = host.sqlStatusVariable("Threads_connected");
        var Max_connections   = host.sqlSystemVariable("Max_connections");
        if (Threads_connected.isError() || Max_connections.isError())
        {
            justification = "";
            msg = "Not enough data to calculate";
        }
        else
        {
            var used = round(100 * Threads_connected / Max_connections,1);
            if (used > WARNING_THRESHOLD)
            {
                advice.setSeverity(1);
                msg = ADVICE_WARNING;
                justification = used + "% of the connections is currently used,"
                " which is > " + WARNING_THRESHOLD + "% of max_connections.";
                 myAlarmId = myAlarm(TITLE, msg, ADVICE_WARNING);
                // Let's raise an alarm.
                host.raiseAlarm(myAlarmId, Warning);
            }
            else
            {
                justification = used + "% of the connections is currently used,"
                " which is < 90% of max_connections.";
                advice.setSeverity(0);
                msg = ADVICE_OK;
            }
        }
        advice.setHost(host);
        advice.setTitle(TITLE);
        advice.setJustification(justification);
        advice.setAdvice(msg);
        advisorMap[idx]= advice;
        print(advice.toString("%E"));
    }
    return advisorMap;
}

Sie können sysbench verwenden, um es zu testen. In meinem Test werde ich proaktiv durch das Senden des Alarms benachrichtigt. Diese wird mir auch per E-Mail zugesendet oder kann benachrichtigt werden, wenn Sie Benachrichtigungen von Drittanbietern integriert haben. Siehe Screenshot unten,

Vorbehalte der Berater von ClusterControl

Ändern oder Bearbeiten eines bestehenden Advisors in ClusterControl wird auf alle Cluster angewendet. Das heißt, Sie müssen Ihr Skript einchecken, wenn es eine bestimmte Bedingung hat, die nur für Ihren vorhandenen Cluster gilt (entweder MySQL oder andere von ClusterControl unterstützte Datenbanken). Dies liegt daran, dass die ClusterControl Advisors nur über unsere cmon DB in einer einzigen Quelle gespeichert werden. Diese werden von allen Clustern gezogen oder abgerufen, die Sie in ClusterControl erstellt haben.

Zum Beispiel können Sie dies in einem Skript tun:

    var hosts     =cluster::mySqlNodes();

    var advisorMap ={};

    print(hosts[1].clusterId());

Dieses Skript gibt die Cluster-ID aus. Sobald Sie den Wert erhalten haben, weisen Sie ihn einer Variablen zu und verwenden Sie diese Variable, um zu bewerten, ob diese spezifische Cluster-ID akzeptabel ist oder nicht, basierend auf der von Ihrem Berater gewünschten Aufgabe. Sagen wir,

function main()
{
    var hosts     = cluster::mySqlNodes();
    var advisorMap = {};
    for (idx = 0; idx < hosts.size(); ++idx)
    {
        host        = hosts[idx];
        map         = host.toMap();
        connected     = map["connected"];
        var advice = new CmonAdvice();
        print("   ");
        print(host);
        print("==========================");
        if (host.clusterId() == 15)
        {
            print("Not applicable for cluster id == 15");
            continue;
        }
…
….
…..

was bedeutet, wenn es die cluster_id ==15 ist, dann einfach überspringen oder mit der nächsten Schleife fortfahren.

Fazit

Das Erstellen oder Ändern der ClusterControl Advisors ist eine gute Gelegenheit, die versteckten Funktionen zu nutzen, die ClusterControl Ihnen bieten kann. Es scheint versteckt zu sein, aber es ist da – es ist nur so, dass die Funktion weniger verwendet wird. Es bietet eine einfache, aber leistungsstarke Funktion namens ClusterControl Domain Specific Language (CDSL), die für extrem schwierige Aufgaben verwendet werden kann, die ClusterControl fehlen. Stellen Sie einfach sicher, dass Sie alle Einschränkungen kennen und testen Sie alles zuerst, bevor Sie es schließlich auf Ihre Produktionsumgebung anwenden.