Esta página describe Calíope 1.5, la versión que estoy construyendo ahora mismo. La 1.4 ya está en la App Store para Mac, iPad, iPhone, Apple Watch, Apple TV y Apple Vision Pro. 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 › Monitor de réplica
El Monitor de réplica enseña SHOW REPLICA STATUS (SHOW SLAVE STATUS antes de MariaDB 10.5 y de MySQL 8.0.22) del servidor al que estás conectado, y lo vuelve a leer cada 5 segundos.
Cómo abrir el monitor:
En la barra lateral Herramientas pulsa Monitor de réplica (ícono de flechas circulares). El monitor se abre en una nueva pestaña.
Indicadores principales:
- Hilo IO: el hilo que lee los eventos del servidor origen. Enseña lo que dice el servidor —Yes, No o Connecting— y sólo está en verde con Yes.
- Hilo SQL: el hilo que aplica esos eventos en este servidor, con los mismos valores.
- Retraso: segundos de retraso respecto al servidor origen.
- Verde — menos de 5 s
- Naranja — de 5 s a 30 s
- Rojo — 30 s o más
Con un hilo parado el servidor no tiene cifra, y la tarjeta dice Sin dato: un cero diría «al día» de una réplica que no está aplicando nada.
- Servidor origen: el host del que lee esta réplica.
- Posición del log binario: el archivo del log binario del origen, la posición hasta la que ha leído el hilo IO y la que ha ejecutado el hilo SQL. Mientras las dos difieren, hay eventos recibidos y todavía sin aplicar.
Errores: si un hilo se para por un error, aparece la sección Errores de replicación con el mensaje completo del servidor.
Estado completo: todas las columnas de SHOW REPLICA STATUS con su valor en bruto, también las que las tarjetas no enseñan: las posiciones GTID, Master_Server_Id (de qué máquina lee esta réplica) o el retraso configurado.
Auto-actualización: el interruptor Auto-actualizar (5 s) lee el estado cada 5 segundos, y Actualizado dice cuándo se leyó por última vez. Apágalo para quedarte con una lectura estática, y pulsa Actualizar para volver a leerlo cuando quieras.
Alertas de retraso: si el retraso llega al umbral configurado en Alertas del servidor (ver tema Alertas del servidor), se envía una notificación del sistema.
El monitor sólo lee: no arranca ni para la replicación. En un servidor que no es réplica —un primario o un servidor independiente— dice Servidor no es una réplica en lugar de las tarjetas.
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, mirada desde dentro; é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.
Sólo se ofrecen las conexiones de un motor cuya replicación la herramienta sabe sondear; las demás no salen en la lista. Si un miembro ya guardado deja de poder sondearse, el grupo lo sigue enseñando, sin alcanzar y con el motivo.
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.
Lee el binary log del servidor evento a evento, con filtro por clase (DDL, DML, Sistema) y por texto.
Dónde está: Espacio de Trabajo › Herramientas › Binary Log
El binary log es el registro que lleva el servidor de cada cambio: lo que copian las réplicas y lo que reproduce una recuperación a un instante dado. El visor lo lee desde la app, sin la utilidad mysqlbinlog de la línea de comandos.
Cómo abrirlo:
En la barra lateral Herramientas pulsa Binary Log (ícono de pergamino). Se abre en una pestaña nueva y lee enseguida el archivo más reciente.
Uso:
1. Archivo: lista los archivos del binary log del servidor (SHOW BINARY LOGS) con su tamaño. Elegir uno lee sus eventos.
2. Límite es cuántos eventos se leen, desde el principio del archivo (de 100 a 2000). Cambiarlo vuelve a leer el archivo. Si el archivo tiene más eventos, una línea encima de la lista lo dice: sube el límite para leer más allá.
3. Tipo filtra por clase: Todos, DDL, DML o Sistema.
4. El campo Buscar… deja los eventos cuyo tipo o contenido contienen el texto.
5. Recargar logs vuelve a leer la lista de archivos y, con ella, el archivo elegido: así se ven los cambios hechos después de abrir la pestaña. Si leías el archivo más reciente y el servidor ha empezado otro, pasa al nuevo.
Clases de evento:
- DDL (naranja): sentencias que cambian el esquema o las cuentas — CREATE, ALTER, DROP, RENAME, TRUNCATE, GRANT, REVOKE.
- DML (azul): cambios de datos. Con el registro por filas, un cambio es un grupo: la sentencia que lo produjo (Annotate_rows en MariaDB, Rows_query en MySQL, si el servidor la anota), la tabla que toca (Table_map) y las filas (Write_rows, Update_rows, Delete_rows). Con el registro por sentencias, el propio INSERT, UPDATE, DELETE, REPLACE o LOAD DATA.
- Sistema (gris): todo lo que no es un cambio — BEGIN, la confirmación (Xid), Gtid, Rotate, la cabecera del archivo (Format_desc), otros eventos de control, y las sentencias que no cambian ni datos ni esquema, como FLUSH PRIVILEGES.
Cada fila muestra:
el tipo de evento, su posición de inicio (Pos) y, si el servidor la anota, la de fin; su clase; y el campo Info: el SQL de una sentencia, la tabla de un Table_map, el número de transacción de una confirmación.
Casos de uso:
- Auditoría de cambios: qué DDL se ejecutó, y en qué orden.
- Análisis de replicación: qué están copiando las réplicas.
- Recuperación a un instante dado: la posición exacta hasta la que restaurar.
El visor sólo lee: no purga ni modifica ningún binary log.
Privilegios necesarios:
- MariaDB 10.5 y posteriores: BINLOG MONITOR.
- MySQL: REPLICATION CLIENT para listar los archivos y REPLICATION SLAVE para leer sus eventos.
Sin ellos, o con el binary log apagado, el visor dice que no tiene acceso.