Diese Seite beschreibt Calíope 1.7, die Version, die ich gerade baue. Die 1.6 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.
ClickHouse
Mit ClickHouse gibt es weder Quellserver noch Threads: Die Replikation läuft pro Tabelle. Der Monitor zeigt vier Karten —replizierte Tabellen, Keeper, der schlimmste Rückstand in Sekunden und die Warteschlange in Einträgen— und eine Zeile pro Replicated*-Tabelle mit diesem Replikat, wie viele Replikate von wie vielen aktiv sind, die fehlenden mit Namen, den Status in Worten —aktuell, im Rückstand, ein Replikat antwortet nicht, schreibgeschützt, Sitzung mit Keeper verloren— und Rückstand und Warteschlange getrennt. Ein Replikat, das seine Sitzung mit Keeper verliert (is_session_expired), bleibt schreibgeschützt, bis es sie zurückbekommt. Ohne replizierte Tabellen sagt der Monitor das.
Oracle
Mit Oracle wird dieses Werkzeug nicht angeboten: Die Replikation von Oracle (Data Guard) gibt es in der Free-Edition nicht, gegen die Calíope gemessen wird, und es gibt nichts, womit man sie prüfen könnte.
TiDB
Mit TiDB wird dieses Werkzeug nicht angeboten: TiDB repliziert innerhalb des eigenen Speichers (TiKV, mit Raft), ohne MySQL-Replikate, die zu überwachen wären, und SHOW REPLICA STATUS gibt es nicht. Den Zustand des Clusters zeigt TiDB Dashboard.
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 du verbunden bist, von innen betrachtet; diese spricht mit allen Maschinen der Gruppe, auch mit denen, die du nicht geöffnet hast, und liest nur.
Welche Maschine der Primary ist und welche die Replikate sind, deklarierst du. Es wird nicht erkannt: eine Erkennung sähe nur, was gerade verbunden ist, erzeugte Gruppen, die sich von selbst ändern, und du könntest „dieses Replikat gehört nicht mehr zur Gruppe“ nicht von „dieses Replikat ist ausgefallen“ unterscheiden.
Was sie tut, ist dir zu widersprechen: sieht der Primary ein deklariertes Replikat nicht, oder zeigt ein Replikat auf einen anderen Server, wird es gesagt.
Ein Replikat, das von einem anderen Replikat der Gruppe liest — eine Kaskade —, ist kein Widerspruch: Das Diagramm zeichnet seinen Pfeil von diesem Replikat aus, und der Primary zählt nur die Replikate, die von ihm lesen.
Dass ein Mitglied nicht antwortet, ist ein normaler Zustand der Gruppe und kein Fehler: Du siehst „7 von 9 erreicht“, mit den beiden fehlenden namentlich und mit ihrem Grund.
ClickHouse
Aus einer ClickHouse-Sitzung geöffnet, deklarierst nicht du die Topologie: Der Server deklariert sie in system.clusters. Seine Cluster werden gezeigt —auch default, mit einem einzigen Knoten— mit einem Diagramm pro Shard, einem Kasten pro Replikat und der Tabelle daneben; oben, wie viele Replikate von wie vielen antworten, die fehlenden mit Namen, und unter einer, die nicht antwortet, was Keeper über sie sagt. Es wird nur gelesen. Ein ClickHouse-Profil wird im Gruppeneditor nicht angeboten.
Oracle
Mit Oracle wird die Topologie nicht angeboten, aus demselben Grund wie der Replikations-Monitor: Data Guard gibt es in der Free-Edition nicht, und es gibt nichts, womit man es messen könnte. Ein Oracle-Profil wird auch im Gruppeneditor nicht angeboten.
TiDB
Mit TiDB wird die Topologie nicht angeboten, aus demselben Grund wie der Replikationsmonitor: TiDB repliziert innerhalb des eigenen Speichers, ohne MySQL-Replikate. Ein Mitglied, das sich als TiDB herausstellt — auch eines, das als MySQL gespeichert ist —, erscheint als nicht erreicht, mit diesem Grund, und ein TiDB-Profil wird im Gruppeneditor nicht angeboten.
„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 siehst du „Kein Messwert“, keine Null: eine Null würde von einem getrennten Replikat „aktuell“ behaupten.
- Ein Replikat, das sich nach einem langen Ausfall gerade wieder verbunden hat, kann 0 anzeigen, während ihm noch Stunden an Binlog fehlen — schlicht weil das Ereignis, das es in diesem Moment anwendet, neu ist.
Deshalb steht die GTID-Abweichung daneben: wie viele Transaktionen der Primary hat, die das Replikat 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.
Du wählst aus deinen 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 deinen gespeicherten Verbindungen: Du wählst eine als Primärserver und fügst die übrigen als Replikate hinzu, in der Reihenfolge, in der du sie sehen möchtest. Es braucht mindestens zwei gespeicherte Verbindungen — eine für den Primärserver und eine für sein Replikat; falls du sie nicht hast, speichere sie zuerst im Verbindungsmanager.
Angeboten werden nur Verbindungen zu einer Engine, deren Replikation das Werkzeug abfragen kann; die übrigen erscheinen nicht in der Liste, und ihre Engines werden unter den Replikaten genannt, damit du weißt, warum sie fehlen. 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 du könntest „dieses Replikat gehört nicht mehr zur Gruppe“ nicht von „dieses Replikat ist ausgefallen“ unterscheiden. Was Calíope sehr wohl tut: dir 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 du eine Verbindung löschst, die Mitglied war, verschwindet die Gruppe nicht — sie wird markiert, und dir wird gesagt, welche Mitglieder entfernt wurden.
TiDB
Eine TiDB-Verbindung wird nicht als Mitglied angeboten: TiDB repliziert in seinem eigenen Speicher, ohne MySQL-Replikate, und der Editor sagt das unter den Replikaten.
Eine Zeile der Replikatabelle öffnet alles zu diesem Mitglied: Rollen, Kanäle, GTID-Abweichung und letzte Fehler.
Wo es zu finden ist: Workspace › Werkzeuge › Topologie
Klicke oder tippe auf eine Zeile der Replikatabelle —oder aktiviere sie mit VoiceOver oder der Tastatur—, um alles zu diesem Mitglied zu öffnen: die deklarierte und die beobachtete Rolle, die Adresse, die Version und den Zeitpunkt der Messung. Für jeden Kanal zeigt es die Quelle, die Verzögerung, die IO- und SQL-Threads, die Binlog-Datei und -Position, die GTID-Abweichung und die letzten IO- und SQL-Fehler mit ihrem Code. Beim Primärserver kommen der Binlog-Status und die Zahl der verbundenen Replikas hinzu, die er sieht.
Die GTID-Abweichung lautet auf eine von vier Arten: aktuell; zurück, bernsteinfarben, wenn der Abstand erheblich ist; innerhalb dessen, was der Primärserver während der Abfrage vorangekommen ist; oder nicht vergleichbar, ohne GTID.
Unten gehen Zurück und Weiter durch die Mitglieder, Kopieren kopiert eine technische Zusammenfassung und Fertig schließt. Ein Mitglied, das die Gruppe verlassen hat, sagt das.
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. Antwortet der Server nicht, sagt er das, und Logs neu laden versucht es erneut.
Verfügbar auf macOS, iPad, iPhone und Apple Vision Pro.
Oracle
Mit Oracle wird dieses Werkzeug nicht angeboten: Was Oracle von jeder Änderung aufbewahrt, sind die Redo-Logs, und die sind kein Protokoll von Anweisungen, das sich der Reihe nach lesen ließe.
TiDB
Mit TiDB wird dieses Werkzeug nicht angeboten: TiDB führt kein Binary Log — SHOW BINARY LOGS bleibt leer —, und seine Änderungen gehen über TiCDC hinaus, außerhalb des SQL-Servers.