This page describes Calíope 1.5, the version I am building right now. 1.4 is on the App Store for the Mac, iPad, iPhone, Apple Watch, Apple TV and Apple Vision Pro. 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 › Replication Monitor
The Replication Monitor shows SHOW REPLICA STATUS (SHOW SLAVE STATUS before MariaDB 10.5 and MySQL 8.0.22) of the server you are connected to, and reads it again every 5 seconds.
How to open the monitor:
In the Tools sidebar, click Replication Monitor (circular arrows icon). The monitor opens in a new tab.
Main indicators:
- IO thread: the thread that reads events from the source server. It shows what the server reports — Yes, No or Connecting — and it is green only with Yes.
- SQL thread: the thread that applies those events on this server, with the same values.
- Lag: seconds behind the source server.
- Green — under 5 s
- Orange — from 5 s to 30 s
- Red — 30 s or more
With a thread stopped the server has no figure, and the card says No reading: a zero would say “up to date” about a replica that isn’t applying anything.
- Source server: the host this replica reads from.
- Binary log position: the source’s binary log file, the position the IO thread has read up to and the position the SQL thread has executed. While the two differ, there are events received and not yet applied.
Errors: if a thread stops on an error, a Replication errors section appears with the server’s full message.
Full status: every column of SHOW REPLICA STATUS with its raw value, including the ones the cards don’t show — the GTID positions, Master_Server_Id (which machine this replica reads from) or the configured delay.
Auto-refresh: the Auto-refresh (5 s) switch reads the status every 5 seconds, and Updated says when it was last read. Turn it off to keep a static snapshot, and click Refresh to read it again when you want.
Lag alerts: if the lag reaches the threshold configured in Server Alerts (see topic Server Alerts), a system notification is sent.
The monitor only reads: it doesn’t start or stop replication. On a server that isn’t a replica — a primary or a standalone server — it says Server is not a replica instead of the cards.
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, seen from inside; 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.
Only connections to an engine whose replication the tool can probe are offered; the rest don't appear in the list. If a member you already saved can no longer be probed, the group still shows it, unreached and with the reason.
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.
Read the server's binary log event by event, filtered by class (DDL, DML, System) and by text.
Where it is: Workspace › Tools › Binary Log
The binary log is the server's record of every change: what replicas copy and what point-in-time recovery replays. The viewer reads it from the app, without the mysqlbinlog command-line utility.
How to open it:
In the Tools sidebar, click Binary Log (scroll icon). It opens in a new tab and reads the newest file straight away.
Usage:
1. File: lists the server's binary log files (SHOW BINARY LOGS) with their size. Choosing one reads its events.
2. Limit is how many events are read, from the start of the file (100 to 2000). Changing it reads the file again. When the file has more events than that, a line above the list says so: raise the limit to read further.
3. Type filters by class: All, DDL, DML or System.
4. The Search… field keeps the events whose type or content contains the text.
5. Reload logs reads the file list again, and the chosen file with it: that is how you see the changes made since the tab opened. If you were reading the newest file and the server has started another since, it moves to the new one.
Event classes:
- DDL (orange): statements that change the schema or the accounts — CREATE, ALTER, DROP, RENAME, TRUNCATE, GRANT, REVOKE.
- DML (blue): data changes. With row-based logging a change is a group: the statement that produced it (Annotate_rows in MariaDB, Rows_query in MySQL, when the server records it), the table it touches (Table_map) and the rows (Write_rows, Update_rows, Delete_rows). With statement-based logging, the INSERT, UPDATE, DELETE, REPLACE or LOAD DATA itself.
- System (gray): everything that is not a change — BEGIN, the commit (Xid), Gtid, Rotate, the file header (Format_desc), other control events, and statements that change neither data nor schema, such as FLUSH PRIVILEGES.
Each row shows:
the event type, its starting position (Pos) and, when the server records it, the position where it ends; its class; and the Info field: the SQL of a statement, the table of a Table_map, the transaction number of a commit.
Use cases:
- Change auditing: which DDL ran, and in which order.
- Replication analysis: what the replicas are copying.
- Point-in-time recovery: the exact position to restore up to.
The viewer only reads: it does not purge or change any binary log.
Required privileges:
- MariaDB 10.5 and later: BINLOG MONITOR.
- MySQL: REPLICATION CLIENT to list the files and REPLICATION SLAVE to read their events.
Without them, or with binary logging off, the viewer says it has no access.