Diese Seite beschreibt Calíope 1.5, die Version, die ich gerade baue. Die 1.4 ist im App Store für Mac, iPad, iPhone, Apple Watch, Apple TV und Apple Vision Pro. Das Changelog sagt, in welcher Version jede Funktion kam.
Fügt jedem Thema einen Button „In Calíope öffnen“ hinzu. Funktioniert nur mit installierter App.
Zeigt den Echtzeit-Status von SHOW REPLICA STATUS: Lag, I/O- und SQL-Threads, Fehler und Position des Binärlogs.
Wo es zu finden ist: Workspace › Werkzeuge › Replikations-Monitor
Der Replikations-Monitor zeigt SHOW REPLICA STATUS (SHOW SLAVE STATUS vor MariaDB 10.5 und MySQL 8.0.22) des Servers, mit dem du verbunden bist, und liest es alle 5 Sekunden neu.
Wie du den Monitor öffnest:
Klick in der Seitenleiste Werkzeuge auf Replikations-Monitor (Symbol mit kreisförmigen Pfeilen). Der Monitor öffnet sich in einem neuen Tab.
Wichtigste Indikatoren:
- IO-Thread: der Thread, der die Events vom Quellserver liest. Er zeigt, was der Server meldet — Yes, No oder Connecting — und ist nur bei Yes grün.
- SQL-Thread: der Thread, der diese Events auf diesem Server anwendet, mit denselben Werten.
- Rückstand: Sekunden Verzögerung gegenüber dem Quellserver.
- Grün — unter 5 s
- Orange — von 5 s bis 30 s
- Rot — 30 s oder mehr
Mit einem angehaltenen Thread hat der Server keinen Wert, und die Karte zeigt Kein Messwert: Eine Null würde „aktuell“ über ein Replikat sagen, das nichts anwendet.
- Quell-Server: der Host, von dem dieses Replikat liest.
- Position des Binary Log: die Binärlog-Datei der Quelle, die Position, bis zu der der IO-Thread gelesen hat, und die, die der SQL-Thread ausgeführt hat. Solange sich beide unterscheiden, gibt es empfangene, noch nicht angewendete Events.
Fehler: Hält ein Thread wegen eines Fehlers an, erscheint der Abschnitt Replikationsfehler mit der vollständigen Meldung des Servers.
Vollständiger Status: alle Spalten von SHOW REPLICA STATUS mit ihrem Rohwert, auch die, die die Karten nicht zeigen — die GTID-Positionen, Master_Server_Id (von welcher Maschine dieses Replikat liest) oder die eingestellte Verzögerung.
Auto-Aktualisierung: Der Schalter Auto-Aktualisierung (5 s) liest den Status alle 5 Sekunden, und Aktualisiert sagt, wann er zuletzt gelesen wurde. Schalte ihn aus, um eine feste Momentaufnahme zu behalten, und klick auf Aktualisieren, um ihn neu zu lesen, wann du willst.
Lag-Warnungen: Erreicht der Rückstand die in Server-Warnungen konfigurierte Schwelle (siehe Thema Server-Warnungen), wird eine Systembenachrichtigung gesendet.
Der Monitor liest nur: Er startet und stoppt die Replikation nicht. Auf einem Server, der kein Replikat ist — einem Primärserver oder einem Standalone-Server — zeigt er statt der Karten Server ist kein Replikat.
Die ganze Gruppe auf einen Blick, nicht eine Maschine von innen.
Wo es zu finden ist: Workspace › Werkzeuge › Topologie
Sie existiert neben dem Replikations-Monitor und ersetzt ihn nicht: jener zeigt den Zustand der Maschine, mit der Sie verbunden sind,, von innen betrachtet; diese spricht mit allen Maschinen der Gruppe, auch mit denen, die Sie nicht geöffnet haben, und liest nur.
Welche Maschine der Primary ist und welche die Repliken sind, deklarieren Sie. Es wird nicht erkannt: eine Erkennung sähe nur, was gerade verbunden ist, erzeugte Gruppen, die sich von selbst ändern, und Sie könnten „diese Replik gehört nicht mehr zur Gruppe“ nicht von „diese Replik ist ausgefallen“ unterscheiden.
Was sie tut, ist Ihnen zu widersprechen: sieht der Primary eine deklarierte Replik nicht, oder zeigt eine Replik auf einen anderen Server, wird es gesagt.
Dass ein Mitglied nicht antwortet, ist ein normaler Zustand der Gruppe und kein Fehler: Sie sehen „7 von 9 erreicht“, mit den beiden fehlenden namentlich und mit ihrem Grund.
„Sekunden Rückstand“ lügt in zwei Fällen — deshalb steht die GTID-Abweichung daneben.
Wo es zu finden ist: Topologie › Rückstand
Seconds_Behind_Source misst das gerade angewandte Ereignis, nicht das, was noch aussteht. Das täuscht auf zwei Arten:
- Bei gestopptem IO-Thread hat der Server nichts, woraus er es berechnen könnte, und liefert null. Hier sehen Sie „Kein Messwert“, keine Null: eine Null würde von einer getrennten Replik „aktuell“ behaupten.
- Eine Replik, die sich nach einem langen Ausfall gerade wieder verbunden hat, kann 0 anzeigen, während ihr noch Stunden an Binlog fehlen — schlicht weil das Ereignis, das sie in diesem Moment anwendet, neu ist.
Deshalb steht die GTID-Abweichung daneben: wie viele Transaktionen der Primary hat, die die Replik nicht ausgeführt hat. Diese Zahl sagt, was fehlt. Läuft die Replikation über die Binlog-Position statt über GTID, gibt es nichts zu vergleichen, und auch das wird gesagt.
Sie wählen aus Ihren gespeicherten Verbindungen, welche der Primärserver ist und welche die Replikate sind.
Wo es zu finden ist: Topologie › Gruppen deklarieren
Eine Gruppe wird im Werkzeug selbst deklariert: über die Schaltfläche Gruppen deklarieren in seiner Leiste. Nicht in der Konfiguration des Server-Monitors — das ist ein anderes Werkzeug mit einem anderen Schalter.
Die Mitglieder stammen aus Ihren gespeicherten Verbindungen: Sie wählen eine als Primärserver und fügen die übrigen als Replikate hinzu, in der Reihenfolge, in der Sie sie sehen möchten. Es braucht mindestens zwei gespeicherte Verbindungen — eine für den Primärserver und eine für sein Replikat; falls Sie sie nicht haben, speichern Sie sie zuerst im Verbindungsmanager.
Angeboten werden nur Verbindungen zu einer Engine, deren Replikation das Werkzeug abfragen kann; die übrigen erscheinen nicht in der Liste. Kann ein bereits gespeichertes Mitglied nicht mehr abgefragt werden, zeigt die Gruppe es weiter an, als nicht erreicht und mit dem Grund.
Calíope errät die Topologie nicht: Eine Erkennung würde nur sehen, was gerade verbunden ist, Gruppen würden sich also von selbst ändern und Sie könnten «dieses Replikat gehört nicht mehr zur Gruppe» nicht von «dieses Replikat ist ausgefallen» unterscheiden. Was Calíope sehr wohl tut: Ihnen widersprechen, wenn der Primärserver ein deklariertes Replikat nicht sieht.
Jede Gruppe hat ihr eigenes Abfrageintervall und ihren eigenen Schalter: Ausschalten stoppt die Abfrage, ohne die Topologie zu löschen. Und wenn Sie eine Verbindung löschen, die Mitglied war, verschwindet die Gruppe nicht — sie wird markiert, und Ihnen wird gesagt, welche Mitglieder entfernt wurden.
Lies das Binary Log des Servers Event für Event, gefiltert nach Klasse (DDL, DML, System) und nach Text.
Wo es zu finden ist: Workspace › Werkzeuge › Binary Log
Das Binary Log ist das Protokoll, das der Server über jede Änderung führt: das, was Replikate kopieren, und das, was eine Wiederherstellung auf einen Zeitpunkt nachspielt. Der Betrachter liest es direkt in der App, ohne das Kommandozeilen-Werkzeug mysqlbinlog.
So öffnest du ihn:
Klick in der Seitenleiste Werkzeuge auf Binary Log (Schriftrollen-Symbol). Er öffnet sich in einem neuen Tab und liest sofort die neueste Datei.
Verwendung:
1. Datei: listet die Binary-Log-Dateien des Servers (SHOW BINARY LOGS) mit ihrer Größe. Wählst du eine, werden ihre Events gelesen.
2. Limit ist die Zahl der gelesenen Events, vom Anfang der Datei an (100 bis 2000). Ändern liest die Datei neu. Hat die Datei mehr Events, sagt es eine Zeile über der Liste: erhöhe das Limit, um weiterzulesen.
3. Typ filtert nach Klasse: Alle, DDL, DML oder System.
4. Das Feld Suchen… behält die Events, deren Typ oder Inhalt den Text enthält.
5. Logs neu laden liest die Dateiliste neu und mit ihr die gewählte Datei: So siehst du die Änderungen seit dem Öffnen des Tabs. Hast du die neueste Datei gelesen und der Server hat inzwischen eine neue begonnen, wechselt der Betrachter zu ihr.
Event-Klassen:
- DDL (orange): Anweisungen, die das Schema oder die Konten ändern — CREATE, ALTER, DROP, RENAME, TRUNCATE, GRANT, REVOKE.
- DML (blau): Datenänderungen. Bei zeilenbasiertem Logging ist eine Änderung eine Gruppe: die Anweisung, die sie erzeugt hat (Annotate_rows in MariaDB, Rows_query in MySQL, wenn der Server sie mitschreibt), die betroffene Tabelle (Table_map) und die Zeilen (Write_rows, Update_rows, Delete_rows). Bei anweisungsbasiertem Logging das INSERT, UPDATE, DELETE, REPLACE oder LOAD DATA selbst.
- System (grau): alles, was keine Änderung ist — BEGIN, der Commit (Xid), Gtid, Rotate, der Dateikopf (Format_desc), andere Steuer-Events und Anweisungen, die weder Daten noch Schema ändern, etwa FLUSH PRIVILEGES.
Jede Zeile zeigt:
den Event-Typ, seine Startposition (Pos) und, wenn der Server sie mitschreibt, die Endposition; seine Klasse; und das Feld Info: das SQL einer Anweisung, die Tabelle einer Table_map, die Transaktionsnummer eines Commits.
Anwendungsfälle:
- Änderungsaudit: welche DDL ausgeführt wurde, und in welcher Reihenfolge.
- Replikationsanalyse: was die Replikate kopieren.
- Wiederherstellung auf einen Zeitpunkt: die genaue Position, bis zu der wiederhergestellt wird.
Der Betrachter liest nur: Er löscht und ändert kein Binary Log.
Benötigte Rechte:
- MariaDB 10.5 und neuer: BINLOG MONITOR.
- MySQL: REPLICATION CLIENT, um die Dateien aufzulisten, und REPLICATION SLAVE, um ihre Events zu lesen.
Ohne sie, oder bei ausgeschaltetem Binary Log, meldet der Betrachter, dass er keinen Zugriff hat.