Esta página describe Calíope 1.5, la versión que estamos construyendo ahora mismo. La 1.4 está terminada y en revisión de App Store, y la tienda sirve hoy la 1.3 en el Mac y la 1.2 en iPad. El changelog dice en qué versión llegó cada función.
Añade un botón «Abrir en Calíope» a cada tema. Sólo funciona con la app instalada.
Muestra el estado en tiempo real de SHOW REPLICA STATUS: lag, threads I/O y SQL, errores y posición del log binario.
Dónde está: Espacio de Trabajo › Herramientas › Réplica
El Monitor de replicación consulta automáticamente SHOW REPLICA STATUS (o SHOW SLAVE STATUS en versiones anteriores a MySQL 8.0.22) cada 5 segundos.
Cómo abrir el monitor:
En la barra lateral Herramientas pulsa Réplica (ícono de flechas circulares). El monitor se abre en una nueva pestaña.
Indicadores principales:
- I/O Thread: estado del hilo que lee eventos del servidor origen (Running / Not Running).
- SQL Thread: estado del hilo que aplica los eventos localmente (Running / Not Running).
- Lag: segundos de retraso respecto al servidor origen.
- Verde — lag < 5 s (sincronizado)
- Naranja — lag entre 5 s y 30 s (retraso moderado)
- Rojo — lag ≥ 30 s (retraso crítico)
- Servidor origen: host del servidor maestro/fuente de datos.
- Posición en log binario: archivo y posición del log binario que ha leído el hilo I/O y la posición que ha ejecutado el hilo SQL.
Errores: si el hilo I/O o el SQL tienen errores, aparecen en rojo con el mensaje completo del error de MySQL.
Auto-actualización: el toggle Auto-actualizar (5 s) activa la actualización automática cada 5 segundos. Desactívalo si quieres una lectura estática para inspeccionar valores sin que cambien.
Alertas de lag: si se detecta lag de replicación superior al umbral configurado en Alertas del servidor (ver tema Alertas del servidor), se envía una notificación del sistema.
Este panel solo muestra datos útiles si el servidor MySQL conectado está configurado como réplica. En un servidor maestro o standalone, los valores aparecerán como —.
Palabras clave: replicación, réplica, slave, master, lag, io thread, sql thread, show replica status, auto-actualizar, error replicación, binlog position
El grupo entero de un vistazo, no una máquina desde dentro.
Dónde está: Espacio de Trabajo › Herramientas › Topología
Convive con el Monitor de replicación y no lo sustituye: aquél enseña el estado de la máquina a la que estás conectado y permite arrancarla, detenerla o reiniciarla; ésta habla con todas las máquinas del grupo, incluidas las que no tienes abiertas, y sólo lee.
Quién es primario y quiénes réplicas lo declaras tú. No se detecta: la detección sólo vería lo que está conectado en este instante, así que produciría grupos que cambian solos y no podrías distinguir «esta réplica ya no está en el grupo» de «esta réplica está caída».
Lo que sí hace es contradecirte: si el primario no ve una réplica que declaraste, o si una réplica apunta a otro servidor, se te dice.
Que un miembro no responda es un estado normal del grupo, no un error: verás «7 de 9 alcanzados» con los dos que faltan nombrados y su motivo.
«Segundos de retraso» miente en dos casos, y por eso al lado va la deriva de GTID.
Dónde está: Topología › Retraso
Seconds_Behind_Source mide el evento que se está aplicando, no lo que falta por aplicar. Eso lo hace engañoso de dos maneras:
- Con el hilo IO parado el servidor no tiene con qué calcularlo y devuelve nulo. Aquí verás «Sin dato», no un cero: un cero diría «al día» de una réplica desconectada.
- Una réplica que acaba de reconectar tras un corte largo puede decir 0 mientras le faltan horas de binlog por traer, simplemente porque el evento que aplica en este momento es reciente.
Por eso al lado va la deriva de GTID: cuántas transacciones tiene el primario que la réplica no ha ejecutado. Esa cifra sí dice lo que falta. Cuando la replicación va por posición de binlog y no por GTID no hay nada que comparar, y también se dice.
Eliges de tus conexiones guardadas cuál es el primario y cuáles las réplicas.
Dónde está: Topología › Declarar grupos
Un grupo se declara desde la propia herramienta: el botón Declarar grupos de su barra. No está en la configuración del monitor de servidores, que es otra herramienta y otro interruptor.
Los miembros salen de tus conexiones guardadas: eliges una como primario y añades las demás como réplicas, en el orden en que quieras verlas. Hacen falta al menos dos conexiones guardadas — una para el primario y otra para su réplica—; si no las tienes, guárdalas antes en el gestor de conexiones.
Calíope no adivina la topología: la detección sólo vería lo conectado en este instante, así que los grupos cambiarían solos y no podrías distinguir «esta réplica ya no está en el grupo» de «esta réplica está caída». Lo que sí hace es contradecirte cuando el primario no ve una réplica que declaraste.
El grupo lleva su propio intervalo de sondeo y su interruptor: apagarlo detiene el sondeo sin borrar la topología. Y si borras una conexión que era miembro, el grupo no desaparece — se marca, y se te dice qué miembros se retiraron.
Explora los eventos del binary log de MySQL con filtros por tipo (DDL, DML, Sistema) y búsqueda por texto.
Dónde está: Espacio de Trabajo › Herramientas › Binlog
El Binary Log de MySQL registra todos los cambios de datos en el servidor. El visor de Calíope permite explorar estos eventos directamente desde la app, sin necesidad de usar la utilidad mysqlbinlog en la línea de comandos.
Cómo abrir el visor:
En la barra lateral Herramientas pulsa Binlog (ícono de pergamino). El visor se abre en una nueva pestaña.
Uso:
1. Selecciona el archivo de log en el selector de la barra superior. Los archivos disponibles se obtienen con SHOW BINARY LOGS.
2. Ajusta el Límite de eventos a cargar (útil en logs muy grandes).
3. Pulsa Cargar para leer los eventos del archivo seleccionado.
4. Filtra por tipo de evento usando los botones: Todos, DDL, DML o Sistema.
5. Usa el campo de búsqueda para filtrar eventos por contenido del campo Info.
Tipos de eventos:
- DDL (naranja): sentencias CREATE, ALTER, DROP, RENAME dentro de eventos Query.
- DML (azul): eventos de filas — Write_rows, Update_rows, Delete_rows.
- Sistema (gris): Xid (commit de transacción), Gtid, Rotate, Anonymous_Gtid y otros eventos de control.
Información por evento:
Cada fila muestra el archivo de log, la posición inicial, el tipo de evento, la posición final y el campo Info con el contenido del evento (SQL para DDL, descripción de filas para DML).
Casos de uso:
- Auditoría de cambios en producción: ver qué sentencias DDL se ejecutaron y cuándo.
- Análisis de replicación: verificar que los eventos se están generando correctamente.
- Point-in-time recovery: identificar la posición exacta en el binlog hasta la que restaurar.
Requisitos de privilegios:
- BINLOG_MONITOR (MariaDB 10.5+ o MySQL 8.0.22+)
- REPLICATION SLAVE en versiones anteriores de MySQL