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 › Monitor della replica

Il Monitor della replica mostra SHOW REPLICA STATUS (SHOW SLAVE STATUS prima di MariaDB 10.5 e di MySQL 8.0.22) del server a cui sei connesso, e lo rilegge ogni 5 secondi.

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

Indicatori principali:
- Thread IO: il thread che legge gli eventi dal server di origine. Mostra ciò che dice il server — Yes, No o Connecting — ed è verde solo con Yes.
- Thread SQL: il thread che applica quegli eventi su questo server, con gli stessi valori.
- Ritardo: secondi di ritardo rispetto al server di origine.
- Verde — meno di 5 s
- Arancione — da 5 s a 30 s
- Rosso — 30 s o più
Con un thread fermo il server non ha una cifra, e la scheda dice Nessun dato: uno zero direbbe «aggiornata» di una replica che non sta applicando nulla.
- Server di origine: l'host da cui legge questa replica.
- Posizione del log binario: il file del log binario dell'origine, la posizione fino a cui ha letto il thread IO e quella eseguita dal thread SQL. Finché le due differiscono, ci sono eventi ricevuti e non ancora applicati.

Errori: se un thread si ferma per un errore, compare la sezione Errori di replica con il messaggio completo del server.

Stato completo: tutte le colonne di SHOW REPLICA STATUS con il loro valore grezzo, anche quelle che le schede non mostrano: le posizioni GTID, Master_Server_Id (da quale macchina legge questa replica) o il ritardo configurato.

Auto-aggiornamento: l'interruttore Auto-aggiorna (5 s) legge lo stato ogni 5 secondi, e Aggiornato dice quando è stato letto l'ultima volta. Spegnilo per tenere una lettura statica, e premi Aggiorna per rileggerlo quando vuoi.

Avvisi di ritardo: se il ritardo raggiunge la soglia configurata in Avvisi del server (vedi argomento Avvisi del server), viene inviata una notifica di sistema.

Il monitor legge soltanto: non avvia né ferma la replica. Su un server che non è una replica — un primario o un server autonomo — mostra Il server non è una replica al posto delle schede.

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, vista dall’interno; 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.

Una replica che legge da un'altra replica del gruppo — una cascata — non è una contraddizione: il diagramma disegna la sua freccia da quella replica, e il primario conta solo quelle che leggono da lui.

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.

Vengono proposte solo le connessioni a un motore di cui lo strumento sa interrogare la replica; le altre non compaiono nell’elenco. Se un membro già salvato non può più essere interrogato, il gruppo continua a mostrarlo, non raggiunto e con il motivo.

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

Una riga della tabella delle repliche apre tutto di quel membro: ruoli, canali, deriva GTID e ultimi errori.

Dove si trova: Workspace › Strumenti › Topologia

Fai clic o tocca una riga della tabella delle repliche —o attivala con VoiceOver o la tastiera— per aprire tutto di quel membro: il ruolo dichiarato e quello osservato, l’indirizzo, la versione e quando è stato misurato. Per ogni canale mostra l’origine, il ritardo, i thread IO e SQL, il file e la posizione del binlog, la deriva GTID e gli ultimi errori IO e SQL con il loro codice. Sul primario aggiunge lo stato del binlog e quante repliche vede connesse.

La deriva GTID si legge in uno di quattro modi: allineata; indietro, in ambra quando il distacco è significativo; entro quanto il primario è avanzato durante il sondaggio; o non confrontabile, senza GTID.

In fondo, Precedente e Successivo scorrono i membri, Copia copia un riepilogo tecnico e Pronto chiude. Un membro che ha lasciato il gruppo lo dice.

Parole chiave: replica, membro, replicazione, GTID, ritardo, thread, errori

Leggi il binary log del server evento per evento, con filtro per classe (DDL, DML, Sistema) e per testo.

Dove si trova: Workspace › Strumenti › Binary Log

Il binary log è il registro che il server tiene di ogni modifica: ciò che copiano le repliche e ciò che riproduce un ripristino a un istante preciso. Il visualizzatore lo legge dall'app, senza l'utility mysqlbinlog da riga di comando.

Come aprirlo:
Nella barra laterale Strumenti premi Binary Log (icona di pergamena). Si apre in una nuova scheda e legge subito il file più recente.

Utilizzo:
1. File: elenca i file del binary log del server (SHOW BINARY LOGS) con la loro dimensione. Sceglierne uno ne legge gli eventi.
2. Limite è quanti eventi si leggono, dall'inizio del file (da 100 a 2000). Cambiarlo rilegge il file. Se il file ha più eventi, una riga sopra l'elenco lo dice: aumenta il limite per leggere oltre.
3. Tipo filtra per classe: Tutti, DDL, DML o Sistema.
4. Il campo Cerca… tiene gli eventi il cui tipo o contenuto contiene il testo.
5. Ricarica log rilegge l'elenco dei file e, con esso, il file scelto: così si vedono le modifiche fatte dopo l'apertura della scheda. Se stavi leggendo il file più recente e il server ne ha iniziato un altro, passa al nuovo.

Classi di eventi:
- DDL (arancione): istruzioni che modificano lo schema o gli account — CREATE, ALTER, DROP, RENAME, TRUNCATE, GRANT, REVOKE.
- DML (blu): modifiche ai dati. Con il log per righe una modifica è un gruppo: l'istruzione che l'ha prodotta (Annotate_rows in MariaDB, Rows_query in MySQL, se il server la registra), la tabella che tocca (Table_map) e le righe (Write_rows, Update_rows, Delete_rows). Con il log per istruzioni, l'INSERT, l'UPDATE, il DELETE, il REPLACE o il LOAD DATA stesso.
- Sistema (grigio): tutto ciò che non è una modifica — BEGIN, la conferma (Xid), Gtid, Rotate, l'intestazione del file (Format_desc), gli altri eventi di controllo, e le istruzioni che non modificano né i dati né lo schema, come FLUSH PRIVILEGES.

Ogni riga mostra:
il tipo di evento, la posizione di inizio (Pos) e, se il server la registra, quella di fine; la sua classe; e il campo Info: l'SQL di un'istruzione, la tabella di un Table_map, il numero di transazione di una conferma.

Casi d'uso:
- Audit delle modifiche: quale DDL è stato eseguito, e in che ordine.
- Analisi della replica: cosa stanno copiando le repliche.
- Ripristino a un istante preciso: la posizione esatta fino a cui ripristinare.

Il visualizzatore legge soltanto: non elimina né modifica alcun binary log.

Privilegi richiesti:
- MariaDB 10.5 e successive: BINLOG MONITOR.
- MySQL: REPLICATION CLIENT per elencare i file e REPLICATION SLAVE per leggerne gli eventi.

Senza di essi, o con il binary log spento, il visualizzatore dice che non ha accesso. Se il server non risponde, lo dice, e Ricarica log riprova.

Disponibile su macOS, iPad, iPhone e Apple Vision Pro.

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