Diese Seite beschreibt Calíope 1.5, die Version, die wir gerade bauen. Die 1.4 ist fertig und in der App-Review, und der Store liefert heute 1.3 auf dem Mac und 1.2 auf dem iPad. 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 › Replik
Der Replikations-Monitor fragt automatisch alle 5 Sekunden SHOW REPLICA STATUS (oder SHOW SLAVE STATUS in Versionen vor MySQL 8.0.22) ab.
Wie du den Monitor öffnest:
Klick in der Seitenleiste Werkzeuge auf Replik (Symbol mit kreisförmigen Pfeilen). Der Monitor öffnet sich in einem neuen Tab.
Wichtigste Indikatoren:
- I/O Thread: Status des Threads, der Events vom Quellserver liest (Running / Not Running).
- SQL Thread: Status des Threads, der die Events lokal anwendet (Running / Not Running).
- Lag: Sekunden Verzögerung gegenüber dem Quellserver.
- Grün — Lag < 5 s (synchronisiert)
- Orange — Lag zwischen 5 s und 30 s (moderate Verzögerung)
- Rot — Lag ≥ 30 s (kritische Verzögerung)
- Quellserver: Host des Master-/Datenquellenservers.
- Position im Binärlog: Datei und Position des Binärlogs, das der I/O-Thread gelesen hat, und die Position, die der SQL-Thread ausgeführt hat.
Fehler: Wenn der I/O- oder der SQL-Thread Fehler haben, erscheinen sie in Rot mit der vollständigen MySQL-Fehlermeldung.
Auto-Aktualisierung: Der Toggle Auto-aktualisieren (5 s) aktiviert die automatische Aktualisierung alle 5 Sekunden. Deaktiviere ihn, wenn du eine statische Anzeige möchtest, um Werte zu inspizieren, ohne dass sie sich ändern.
Lag-Warnungen: Wenn eine Replikationsverzögerung oberhalb der in Server-Warnungen konfigurierten Schwelle erkannt wird (siehe Thema Server-Warnungen), wird eine Systembenachrichtigung gesendet.
Dieses Panel zeigt nur nützliche Daten, wenn der verbundene MySQL-Server als Replik konfiguriert ist. Auf einem Master- oder Standalone-Server erscheinen die Werte als —.
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, und lässt sie starten, stoppen oder zurücksetzen; 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.
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.
Erkunde die Events des MySQL-Binary-Logs mit Filtern nach Typ (DDL, DML, System) und Textsuche.
Wo es zu finden ist: Workspace › Werkzeuge › Binlog
Das Binary Log von MySQL protokolliert alle Datenänderungen auf dem Server. Der Betrachter von Calíope erlaubt es, diese Events direkt aus der App zu erkunden, ohne das Dienstprogramm mysqlbinlog auf der Kommandozeile verwenden zu müssen.
Wie du den Betrachter öffnest:
Klick in der Seitenleiste Werkzeuge auf Binlog (Schriftrollen-Symbol). Der Betrachter öffnet sich in einem neuen Tab.
Verwendung:
1. Wähl die Log-Datei im Auswahlmenü der oberen Leiste. Die verfügbaren Dateien werden mit SHOW BINARY LOGS abgerufen.
2. Passe das Limit der zu ladenden Events an (nützlich bei sehr großen Logs).
3. Klick auf Laden, um die Events der ausgewählten Datei zu lesen.
4. Filtere nach Event-Typ mit den Buttons: Alle, DDL, DML oder System.
5. Nutze das Suchfeld, um Events nach dem Inhalt des Info-Felds zu filtern.
Event-Typen:
- DDL (orange): CREATE-, ALTER-, DROP-, RENAME-Anweisungen innerhalb von Query-Events.
- DML (blau): Zeilen-Events — Write_rows, Update_rows, Delete_rows.
- System (grau): Xid (Transaktions-Commit), Gtid, Rotate, Anonymous_Gtid und andere Steuer-Events.
Informationen pro Event:
Jede Zeile zeigt die Log-Datei, die Anfangsposition, den Event-Typ, die Endposition und das Feld Info mit dem Inhalt des Events (SQL bei DDL, Zeilenbeschreibung bei DML).
Anwendungsfälle:
- Audit von Änderungen in der Produktion: sehen, welche DDL-Anweisungen wann ausgeführt wurden.
- Replikationsanalyse: prüfen, ob die Events korrekt generiert werden.
- Point-in-Time Recovery: die exakte Position im Binlog identifizieren, bis zu der wiederhergestellt werden soll.
Berechtigungsanforderungen:
- BINLOG_MONITOR (MariaDB 10.5+ oder MySQL 8.0.22+)
- REPLICATION SLAVE in älteren MySQL-Versionen