Die Mehrheit der DBAs führt von Zeit zu Zeit Zustandsprüfungen ihrer Datenbanken durch. Normalerweise würde es auf einer täglichen oder wöchentlichen Basis passieren. Wir haben bereits besprochen, warum solche Überprüfungen wichtig sind und was sie beinhalten sollten.
Um sicherzustellen, dass Ihre Systeme in einem guten Zustand sind, müssen Sie eine Menge Informationen durchgehen – Hoststatistiken, MySQL-Statistiken, Workload-Statistiken, Status von Sicherungen, Datenbankpakete, Protokolle und so weiter. Solche Daten sollten in jeder ordnungsgemäß überwachten Umgebung verfügbar sein, obwohl sie manchmal über mehrere Standorte verstreut sind - Sie haben möglicherweise ein Tool zum Überwachen des MySQL-Status, ein anderes Tool zum Sammeln von Systemstatistiken, vielleicht eine Reihe von Skripten, z. B. um den Status zu überprüfen von Ihre Sicherungen. Dies macht Zustandsprüfungen viel zeitaufwändiger, als sie sein sollten – der DBA muss die verschiedenen Teile zusammenfügen, um den Zustand des Systems zu verstehen.
Integrierte Tools wie ClusterControl haben den Vorteil, dass sich alle Bits an derselben Stelle (oder in derselben Anwendung) befinden. Dies bedeutet jedoch nicht, dass sie sich nebeneinander befinden – sie können sich in verschiedenen Abschnitten der Benutzeroberfläche befinden, und ein DBA muss möglicherweise einige Zeit damit verbringen, sich durch die Benutzeroberfläche zu klicken, um alle interessanten Daten zu erreichen.
Die Grundidee hinter der Erstellung von Betriebsberichten besteht darin, alle wichtigen Daten in einem einzigen Dokument zusammenzufassen, das schnell überprüft werden kann, um den Zustand der Datenbanken zu verstehen.
Betriebsberichte sind im Menü Seitenmenü -> Betriebsberichte verfügbar:
Sobald Sie dorthin gehen, wird Ihnen eine Liste mit Berichten angezeigt, die manuell oder automatisch basierend auf einem vordefinierten Zeitplan erstellt wurden:
Wenn Sie einen neuen Bericht manuell erstellen möchten, verwenden Sie die Option „Erstellen“. Wählen Sie den Typ des Berichts, den Clusternamen (für Berichte pro Cluster), die E-Mail-Empfänger (optional – wenn Sie möchten, dass Ihnen der Bericht zugestellt wird) und schon sind Sie ziemlich fertig:
Die Berichte können auch so geplant werden, dass sie regelmäßig erstellt werden:
Derzeit sind 5 Arten von Berichten verfügbar:
- Verfügbarkeitsbericht – Alle Cluster.
- Backup-Bericht – Alle Cluster.
- Schemaänderungsbericht – nur MySQL/MariaDB-basierter Cluster.
- Täglicher Systembericht – pro Cluster.
- Paket-Upgrade-Bericht – pro Cluster.
Verfügbarkeitsbericht
Verfügbarkeitsberichte konzentrieren sich auf die Verfügbarkeit. Es umfasst drei Abschnitte. Zuerst die Verfügbarkeitsübersicht:
Sie können Informationen über Verfügbarkeitsstatistiken Ihrer Datenbanken, den Clustertyp, die Gesamtbetriebszeit und -ausfallzeit, den aktuellen Status des Clusters und wann sich dieser Status zuletzt geändert hat, anzeigen.
Ein weiterer Abschnitt enthält weitere Details zur Verfügbarkeit für jeden Cluster. Der folgende Screenshot zeigt nur einen der Datenbank-Cluster:
Wir können sehen, wann ein Knoten den Zustand gewechselt hat und was der Übergang war. Es ist ein guter Ort, um zu überprüfen, ob es kürzlich Probleme mit dem Cluster gab. Ähnliche Daten werden im dritten Abschnitt dieses Berichts angezeigt, wo Sie den Verlauf der Änderungen des Clusterstatus einsehen können.
Backup-Bericht
Der zweite Berichtstyp umfasst Sicherungen aller Cluster. Es enthält zwei Abschnitte – Backup-Zusammenfassung und Backup-Details, wobei Ersteres Ihnen im Wesentlichen eine kurze Zusammenfassung darüber gibt, wann das letzte Backup erstellt wurde, ob es erfolgreich abgeschlossen wurde oder fehlgeschlagen ist, Backup-Verifizierungsstatus, Erfolgsrate und Aufbewahrungszeitraum:
ClusterControl bietet auch Beispiele für Backup-Richtlinien, wenn es einen der überwachten Datenbank-Cluster findet, der ohne geplantes Backup oder verzögerten Slave konfiguriert ist. Als nächstes folgen die Backup-Details:
Sie können auch die Liste der auf dem Cluster ausgeführten Sicherungen mit Status, Typ und Größe innerhalb des angegebenen Intervalls überprüfen. So nahe können Sie sicher sein, dass Backups korrekt funktionieren, ohne einen vollständigen Wiederherstellungstest durchzuführen. Wir empfehlen auf jeden Fall, solche Tests hin und wieder durchzuführen. Die gute Nachricht ist, dass ClusterControl die MySQL-basierte Wiederherstellung und Überprüfung auf einem eigenständigen Host unter Backup -> Backup wiederherstellen unterstützt.
Täglicher Systembericht
Dieser Berichtstyp enthält detaillierte Informationen zu einem bestimmten Cluster. Es beginnt mit einer Zusammenfassung verschiedener Warnungen, die sich auf den Cluster beziehen:
Im nächsten Abschnitt geht es um den Zustand der Knoten, die Teil des Clusters sind:
Sie haben eine Liste der Knoten im Cluster, ihren Typ, ihre Rolle (Master oder Slave), den Status des Knotens, die Betriebszeit und das Betriebssystem.
Ein weiterer Abschnitt des Berichts ist die Backup-Zusammenfassung, wie wir sie oben besprochen haben. Als Nächstes wird eine Zusammenfassung der wichtigsten Abfragen im Cluster angezeigt:
Schließlich sehen wir eine „Knotenstatus-Übersicht“, in der Ihnen Diagramme zu Betriebssystem- und MySQL-Metriken für jeden Knoten angezeigt werden.
Wie Sie sehen können, haben wir hier Diagramme, die alle Aspekte der Auslastung des Hosts abdecken – CPU, Arbeitsspeicher, Netzwerk, Festplatte, CPU-Auslastung und freie Festplatte. Dies reicht aus, um eine Vorstellung davon zu bekommen, ob in letzter Zeit etwas Seltsames passiert ist oder nicht. Sie können auch einige Details zur MySQL-Arbeitslast sehen – wie viele Abfragen wurden ausgeführt, welche Art von Abfrage, wie auf die Daten zugegriffen wurde (über welchen Handler)? Dies sollte andererseits ausreichen, um die meisten Probleme auf MySQL-Seite zu lösen. Was Sie sich ansehen möchten, sind alle Spitzen und Einbrüche, die Sie in der Vergangenheit nicht gesehen haben. Vielleicht wurde dem Mix eine neue Abfrage hinzugefügt und als Ergebnis handler_read_rnd_next in die Höhe geschossen? Möglicherweise gab es eine Erhöhung der CPU-Last und eine hohe Anzahl von Verbindungen könnte auf eine erhöhte Belastung von MySQL hindeuten, aber auch auf eine Art Konflikt. Ein unerwartetes Muster könnte gut untersucht werden, damit Sie wissen, was vor sich geht.
Paket-Upgrade-Bericht
Dieser Bericht enthält eine Zusammenfassung der Pakete, die für Upgrades durch den Repository-Manager auf den überwachten Hosts verfügbar sind. Stellen Sie für eine genaue Berichterstattung sicher, dass Sie auf jedem Host immer stabile und vertrauenswürdige Repositories verwenden. In einigen unerwünschten Fällen könnten die überwachten Hosts nach einem Upgrade mit einem veralteten Repository konfiguriert werden (z. B. verwendet jede MariaDB-Hauptversion ein anderes Repository), ein unvollständiges internes Repository (z. B. teilweise vom Upstream gespiegelt) oder ein hochmodernes Repository (üblicherweise für unstable Nightly-Build-Pakete).
Der erste Abschnitt ist die Upgrade-Zusammenfassung:
Es fasst die Gesamtzahl der Pakete zusammen, die für ein Upgrade verfügbar sind, sowie den zugehörigen Managed Service für den Cluster wie Load Balancer, virtuelle IP-Adresse und Arbitrator. Als nächstes bietet ClusterControl eine detaillierte Paketliste, gruppiert nach Pakettyp für jeden Host:
Dieser Bericht stellt die verfügbare Version bereit und kann uns sehr dabei helfen, unser Wartungsfenster effizient zu planen. Kritische Upgrades wie Sicherheits- und Datenbankpakete könnten wir gegenüber unkritischen Upgrades priorisieren, die mit anderen Wartungsfenstern mit geringerer Priorität konsolidiert werden könnten.
Schemaänderungsbericht
Dieser Bericht vergleicht die ausgewählten MySQL/MariaDB-Datenbankänderungen in der Tabellenstruktur, die zwischen zwei verschiedenen generierten Berichten aufgetreten sind. In den älteren Versionen von MySQL/MariaDB ist der DDL-Vorgang ein nicht-atomarer Vorgang (vor 8.0) und erfordert eine vollständige Tabellenkopie (vor 5.6 für die meisten Vorgänge) – wodurch andere Transaktionen blockiert werden, bis er abgeschlossen ist. Schemaänderungen können zu einem großen Problem werden, sobald Ihre Tabellen eine erhebliche Datenmenge erhalten, und müssen insbesondere in einem Cluster-Setup sorgfältig geplant werden. In einer mehrschichtigen Entwicklungsumgebung haben wir viele Fälle gesehen, in denen Entwickler die Tabellenstruktur unbemerkt geändert haben, was zu erheblichen Auswirkungen auf die Abfrageleistung geführt hat.
Damit ClusterControl einen genauen Bericht erstellen kann, müssen spezielle Optionen in der CMON-Konfigurationsdatei für den jeweiligen Cluster konfiguriert werden:
- schema_change_detection_address - Mit SHOW TABLES/SHOW CREATE TABLE wird geprüft, ob sich das Schema geändert hat. Die Prüfungen werden auf der angegebenen Adresse ausgeführt und haben das Format HOSTNAME:PORT. Die schema_change_detection_databases muss auch eingestellt werden. Ein Differential einer geänderten Tabelle wird erstellt (mit diff).
- schema_change_detection_databases - Durch Kommas getrennte Liste von Datenbanken, die auf Schemaänderungen überwacht werden sollen. Wenn leer, werden keine Prüfungen durchgeführt.
In diesem Beispiel möchten wir Schemaänderungen für die Datenbanken „myapp“ und „sbtest“ auf unserem MariaDB-Cluster mit der Cluster-ID 27 überwachen. Wählen Sie einen der Datenbankknoten als Wert für schema_change_detection_address aus . Für die MySQL-Replikation sollte dies der Master-Host oder ein beliebiger Slave-Host sein, der die Datenbanken enthält (falls die teilweise Replikation aktiv ist). Fügen Sie dann in /etc/cmon.d/cmon_27.cnf die beiden folgenden Zeilen hinzu:
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestStarten Sie den CMON-Dienst neu, um die Änderung zu laden:
$ systemctl restart cmonFür den ersten und wichtigsten Bericht gibt ClusterControl nur das Ergebnis der Metadatensammlung zurück, ähnlich wie unten:
Mit dem ersten Bericht als Grundlage geben die nachfolgenden Berichte die erwartete Ausgabe zurück:
Beachten Sie, dass nur neue Tabellen oder geänderte Tabellen im Bericht gedruckt werden. Der erste Bericht dient nur der Metadatenerfassung zum Vergleich in den nachfolgenden Runden, daher müssen wir ihn mindestens zweimal ausführen, um den Unterschied zu sehen.
Mit diesem Bericht können Sie jetzt die Spuren der Datenbankstruktur erfassen und nachvollziehen, wie sich Ihre Datenbank im Laufe der Zeit entwickelt hat.
Abschließende Gedanken
Der Betriebsbericht ist eine umfassende Möglichkeit, den Zustand Ihrer Datenbankinfrastruktur zu verstehen. Es wurde sowohl für Betriebs- als auch für Führungskräfte entwickelt und kann bei der Analyse Ihrer Datenbankoperationen sehr nützlich sein. Die Berichte können vor Ort erstellt oder per E-Mail an Sie geliefert werden, was die Dinge bequem vereinfacht, wenn Sie über ein Berichtssilo verfügen.
Wir würden gerne Ihr Feedback zu allem hören, was Sie gerne in den Bericht aufgenommen hätten, was fehlt und was nicht benötigt wird.
