Replica

Mostra lo stato in tempo reale di SHOW REPLICA STATUS: lag, thread I/O e SQL, errori e posizione del log binario.

Dove si trova: Workspace › Strumenti › Replica

Il Monitor della replica interroga automaticamente SHOW REPLICA STATUS (o SHOW SLAVE STATUS nelle versioni precedenti a MySQL 8.0.22) ogni 5 secondi.

Come aprire il monitor:
Nella barra laterale Strumenti premi Replica (icona di frecce circolari). Il monitor si apre in una nuova tab.

Indicatori principali:
- I/O Thread: stato del thread che legge gli eventi dal server di origine (Running / Not Running).
- SQL Thread: stato del thread che applica gli eventi localmente (Running / Not Running).
- Lag: secondi di ritardo rispetto al server di origine.
- Verde — lag < 5 s (sincronizzato)
- Arancione — lag tra 5 s e 30 s (ritardo moderato)
- Rosso — lag ≥ 30 s (ritardo critico)
- Server di origine: host del server master/fonte dei dati.
- Posizione nel log binario: file e posizione del log binario letti dal thread I/O e la posizione eseguita dal thread SQL.

Errori: se il thread I/O o SQL presentano errori, appaiono in rosso con il messaggio completo dell'errore di MySQL.

Auto-aggiornamento: il toggle Auto-aggiorna (5 s) attiva l'aggiornamento automatico ogni 5 secondi. Disattivalo se vuoi una lettura statica per ispezionare i valori senza che cambino.

Avvisi di lag: se viene rilevato un lag di replica superiore alla soglia configurata in Avvisi del server (vedi argomento Avvisi del server), viene inviata una notifica di sistema.

Questo pannello mostra dati utili solo se il server MySQL connesso è configurato come replica. Su un server master o standalone, i valori appariranno come —.

Parole chiave: replicazione, replica, slave, master, lag, io thread, sql thread, show replica status, auto-aggiorna, errore replicazione, binlog position

L’intero gruppo a colpo d’occhio, non una macchina vista da dentro.

Dove si trova: Workspace › Strumenti › Topologia

Convive con il Monitor di replica e non lo sostituisce: quello mostra lo stato della macchina a cui sei connesso e permette di avviarla, fermarla o reimpostarla; questo parla con tutte le macchine del gruppo, comprese quelle che non hai aperte, e legge soltanto.

Quale macchina è il primario e quali sono le repliche lo dichiari tu. Non viene rilevato: il rilevamento vedrebbe solo ciò che è connesso in questo istante, produrrebbe gruppi che cambiano da soli e non potresti distinguere «questa replica non è più nel gruppo» da «questa replica è ferma».

Quello che fa è contraddirti: se il primario non vede una replica che hai dichiarato, o se una replica punta a un altro server, te lo dice.

Che un membro non risponda è uno stato normale del gruppo, non un errore: vedrai «7 di 9 raggiunti», con i due mancanti nominati e il loro motivo.

Parole chiave: replica, topologia, gruppo, primario, replica

«Secondi di ritardo» mente in due casi, per questo accanto c’è la deriva di GTID.

Dove si trova: Topologia › Ritardo

Seconds_Behind_Source misura l’evento che si sta applicando, non quello che resta da applicare. Il che inganna in due modi:

- Con il thread IO fermo il server non ha con cosa calcolarlo e restituisce nullo. Qui vedrai «Nessun dato», non uno zero: uno zero direbbe «allineata» di una replica disconnessa.
- Una replica che si è appena riconnessa dopo un'interruzione lunga può dire 0 mentre le mancano ore di binlog da recuperare, semplicemente perché l’evento che applica in questo momento è recente.

Per questo accanto c’è la deriva di GTID: quante transazioni ha il primario che la replica non ha eseguito. Quella cifra dice cosa manca. Quando la replica va per posizione di binlog e non per GTID non c’è nulla da confrontare, e anche questo viene detto.

Parole chiave: ritardo, lag, gtid, deriva

Scegli fra le tue connessioni salvate quale è il primario e quali sono le repliche.

Dove si trova: Topologia › Dichiara gruppi

Un gruppo si dichiara dallo strumento stesso: il pulsante Dichiara gruppi della sua barra. Non è nella configurazione del monitor dei server, che è un altro strumento con un altro interruttore.

I membri escono dalle tue connessioni salvate: ne scegli una come primario e aggiungi le altre come repliche, nell’ordine in cui vuoi vederle. Servono almeno due connessioni salvate — una per il primario e una per la sua replica; se non le hai, salvale prima nel gestore delle connessioni.

Calíope non indovina la topologia: il rilevamento vedrebbe solo ciò che è connesso in questo istante, quindi i gruppi cambierebbero da soli e non potresti distinguere «questa replica non è più nel gruppo» da «questa replica è caduta». Quello che fa, invece, è contraddirti quando il primario non vede una replica che hai dichiarato.

Ogni gruppo ha il proprio intervallo di sondaggio e il proprio interruttore: spegnerlo ferma il sondaggio senza cancellare la topologia. E se elimini una connessione che era membro, il gruppo non sparisce — viene segnalato, e ti si dice quali membri sono stati ritirati.

Parole chiave: dichiarare, gruppo, primario, replica, connessione, configurare

Esplora gli eventi del binary log di MySQL con filtri per tipo (DDL, DML, Sistema) e ricerca testuale.

Dove si trova: Workspace › Strumenti › Binlog

Il Binary Log di MySQL registra tutte le modifiche ai dati sul server. Il visualizzatore di Calíope permette di esplorare questi eventi direttamente dall'app, senza dover usare l'utility mysqlbinlog da riga di comando.

Come aprire il visualizzatore:
Nella barra laterale Strumenti premi Binlog (icona di pergamena). Il visualizzatore si apre in una nuova tab.

Uso:
1. Seleziona il file di log nel selettore della barra superiore. I file disponibili si ottengono con SHOW BINARY LOGS.
2. Regola il Limite di eventi da caricare (utile su log molto grandi).
3. Premi Carica per leggere gli eventi del file selezionato.
4. Filtra per tipo di evento usando i pulsanti: Tutti, DDL, DML o Sistema.
5. Usa il campo di ricerca per filtrare gli eventi in base al contenuto del campo Info.

Tipi di eventi:
- DDL (arancione): istruzioni CREATE, ALTER, DROP, RENAME all'interno di eventi Query.
- DML (blu): eventi di riga — Write_rows, Update_rows, Delete_rows.
- Sistema (grigio): Xid (commit di transazione), Gtid, Rotate, Anonymous_Gtid e altri eventi di controllo.

Informazioni per evento:
Ogni riga mostra il file di log, la posizione iniziale, il tipo di evento, la posizione finale e il campo Info con il contenuto dell'evento (SQL per DDL, descrizione delle righe per DML).

Casi d'uso:
- Audit delle modifiche in produzione: vedere quali istruzioni DDL sono state eseguite e quando.
- Analisi della replica: verificare che gli eventi vengano generati correttamente.
- Point-in-time recovery: identificare la posizione esatta nel binlog fino a cui ripristinare.

Requisiti di privilegi:
- BINLOG_MONITOR (MariaDB 10.5+ o MySQL 8.0.22+)
- REPLICATION SLAVE nelle versioni precedenti di MySQL

Disponibile su macOS, iPad e iPhone.

Parole chiave: binlog, binary log, eventi, replicazione, audit, point-in-time, dml, ddl, SHOW BINARY LOGS, mysqlbinlog, Xid, Gtid, Write_rows, Update_rows