This page describes Calíope 1.5, the version we are building right now. 1.4 is finished and in App Review, and the store serves 1.3 on the Mac and 1.2 on iPad. The changelog says which version each feature landed in.
Adds an “Open in Calíope” button to every topic. It only works with the app installed.
Displays the real-time status of SHOW REPLICA STATUS: lag, I/O and SQL threads, errors, and binary log position.
Where it is: Workspace › Tools › Replica
The Replication Monitor automatically queries SHOW REPLICA STATUS (or SHOW SLAVE STATUS for MySQL versions prior to 8.0.22) every 5 seconds.
How to open the monitor:
In the Tools sidebar, click Replica (circular arrows icon). The monitor opens in a new tab.
Main indicators:
- I/O Thread: status of the thread that reads events from the source server (Running / Not Running).
- SQL Thread: status of the thread that applies events locally (Running / Not Running).
- Lag: seconds of delay behind the source server.
- Green — lag < 5 s (in sync)
- Orange — lag between 5 s and 30 s (moderate delay)
- Red — lag ≥ 30 s (critical delay)
- Source server: host of the master/source server.
- Binary log position: file and position in the binary log that the I/O thread has read, and the position that the SQL thread has executed.
Errors: if the I/O or SQL thread has errors, they appear in red with the full MySQL error message.
Auto-refresh: the Auto-refresh (5 s) toggle enables automatic updates every 5 seconds. Disable it if you want a static snapshot to inspect values without them changing.
Lag alerts: if replication lag exceeds the threshold configured in Server Alerts (see topic Server Alerts), a system notification is sent.
This panel only shows useful data if the connected MySQL server is configured as a replica. On a master or standalone server, values will appear as —.
Keywords: replication, replica, slave, master, lag, io thread, sql thread, show replica status, auto-refresh, replication error, binlog position
The whole group at a glance, not one machine from the inside.
Where it is: Workspace › Tools › Topology
It lives alongside the Replication monitor and doesn’t replace it: that one shows the state of the machine you’re connected to and lets you start, stop or reset it; this one talks to every machine in the group, including the ones you don’t have open, and only reads.
Which machine is the primary and which are the replicas is something you declare. It isn’t detected: detection would only see what’s connected right now, so it would produce groups that change on their own and you couldn’t tell “this replica is no longer in the group” from “this replica is down”.
What it does do is contradict you: if the primary can’t see a replica you declared, or a replica points at another server, you’re told.
A member not answering is a normal state of the group, not an error: you’ll see “7 of 9 reached”, with the two missing ones named and their reason.
“Seconds behind” lies in two cases, which is why GTID drift sits next to it.
Where it is: Topology › Lag
Seconds_Behind_Source measures the event being applied, not what’s left to apply. That makes it misleading in two ways:
- With the IO thread stopped the server has nothing to compute it from and returns null. Here you’ll see “No reading”, not a zero: a zero would say “up to date” of a disconnected replica.
- A replica that just reconnected after a long outage can say 0 while it still has hours of binlog to fetch, simply because the event it is applying right now is recent.
That’s why the GTID drift sits next to it: how many transactions the primary has that the replica hasn’t executed. That figure does say what’s missing. When replication goes by binlog position rather than GTID there is nothing to compare, and that is said too.
You pick which of your saved connections is the primary and which are the replicas.
Where it is: Topology › Declare groups
A group is declared from the tool itself: the Declare groups button in its toolbar. It is not in the server monitor's setup, which is a different tool with a different switch.
Members come from your saved connections: pick one as the primary and add the others as replicas, in the order you want to see them. You need at least two saved connections — one for the primary and one for its replica; if you don't have them, save them first in the connection manager.
Calíope does not guess the topology: detection would only see what is connected right now, so groups would change on their own and you could not tell «this replica is no longer in the group» from «this replica is down». What it does do is contradict you when the primary can't see a replica you declared.
Each group carries its own poll interval and its own switch: turning it off stops the polling without deleting the topology. And if you delete a connection that was a member, the group does not disappear — it is flagged, and you are told which members were removed.
Browse MySQL binary log events with filters by type (DDL, DML, System) and text search.
Where it is: Workspace › Tools › Binlog
The MySQL Binary Log records all data changes on the server. Calíope's viewer lets you explore these events directly from the app, without needing to use the mysqlbinlog command-line utility.
How to open the viewer:
In the Tools sidebar, click Binlog (scroll icon). The viewer opens in a new tab.
Usage:
1. Select the log file from the selector in the top bar. Available files are retrieved with SHOW BINARY LOGS.
2. Adjust the Limit of events to load (useful for very large logs).
3. Tap Load to read the events from the selected file.
4. Filter by event type using the buttons: All, DDL, DML, or System.
5. Use the search field to filter events by content in the Info field.
Event types:
- DDL (orange): CREATE, ALTER, DROP, RENAME statements within Query events.
- DML (blue): row events — Write_rows, Update_rows, Delete_rows.
- System (gray): Xid (transaction commit), Gtid, Rotate, Anonymous_Gtid, and other control events.
Per-event information:
Each row shows the log file, starting position, event type, ending position, and the Info field with the event content (SQL for DDL, row description for DML).
Use cases:
- Production change auditing: see which DDL statements were executed and when.
- Replication analysis: verify that events are being generated correctly.
- Point-in-time recovery: identify the exact binlog position to restore up to.
Privilege requirements:
- BINLOG_MONITOR (MariaDB 10.5+ or MySQL 8.0.22+)
- REPLICATION SLAVE on older MySQL versions