Replica MySQL dopo una caduta VPN: leggete prima le due fasi

Il monitoraggio della replica diventa rosso quando la VPN cade, e l’istinto è reimpostare una posizione. È proprio quell’istinto a trasformare un’interruzione di rete in un problema di dati. Un percorso caduto non dice nulla su ciò che la replica ha ricevuto o applicato, e quelle sono due fasi con due stati. Leggetele separatamente prima di cambiare qualsiasi cosa.

Due fasi, due risposte separate

Una replica asincrona tradizionale svolge due compiti. Il ricevitore si connette alla sorgente, preleva gli eventi e li scrive localmente nel registro di inoltro. L’applicatore legge quel registro ed esegue gli eventi sulla replica. Quando il percorso si spezza, il ricevitore si ferma subito mentre l’applicatore continua a lavorare l’arretrato già presente sul disco. Un’interruzione produce quindi due domande diverse: la connessione è tornata e il lavoro accumulato è stato applicato? Trattarle come un’unica domanda media due stati in una risposta fuorviante.

Il recupero del ricevitore vi dice che il percorso è attivo. Non dice nulla su quanto l’applicatore sia indietro, né se abbia incontrato un errore durante la disconnessione.

Leggete il canale con l’istruzione giusta

Su MySQL 8.4, SHOW REPLICA STATUS restituisce una riga per ogni canale configurato, quindi leggete la riga del canale che vi interessa e non la prima dell’elenco. Replica_IO_Running distingue un ricevitore connesso da uno che si sta connettendo o è fermo, e Replica_SQL_Running descrive l’applicatore. Leggete anche le colonne di errore accanto, perché un ricevitore che si riconnette e fallisce subito lascia un messaggio che nessun indicatore di stato mostrerà. Le versioni più vecchie usano nomi di colonna diversi, quindi non traducete una vecchia ricetta limitandovi a rinominare i comandi.

Verificate anche l’identità della sorgente e i filtri configurati. Una replica puntata alla sorgente sbagliata, o filtrata più strettamente di quanto pensiate, segnala salute mentre replica qualcosa di diverso da ciò che vi aspettate.

Perché un ritardo zero può mentire

Il valore di ritardo confronta la marca temporale dell’ultimo evento applicato con l’ora corrente. Quando il ricevitore è fermo da un’ora, l’applicatore può lavorare l’arretrato e raggiungere la fine di ciò che ha ricevuto, e allora il numero scende a zero anche se la replica è un’ora indietro rispetto alla sorgente. La metrica misura la coda dell’applicatore, non l’attualità della replica.

Confrontate invece le transazioni eseguite con ciò che la sorgente ha disponibile. Quel confronto sopravvive a un ricevitore bloccato.

La conservazione fissa la vera finestra di recupero

Recuperare richiede che la sorgente conservi ancora le transazioni di cui la replica ha bisogno. Una volta eliminate, la replica non può più prelevarle, e nessuna riconnessione lo cambia.

Con il posizionamento automatico GTID il guasto è esplicito: la replica chiede una cronologia che la sorgente non conserva più e rifiuta di continuare. Le opzioni sono allora recuperare gli eventi mancanti da una sorgente che li ha ancora, oppure ricostruire da un backup e lasciarla recuperare. Saltare il divario non è recuperare, e lascia una replica i cui dati sono silenziosamente incompleti. Pianificate la finestra confrontando la durata prevista dell’interruzione con la conservazione del registro binario sulla sorgente e il ritmo di cambiamento, perché quei tre numeri decidono se un’interruzione è recuperabile.

Verificate il recupero, non il colore di un indicatore

Ripristinate il percorso, inclusi la risoluzione dei nomi e la sicurezza del trasporto, poi osservate se il canale esistente si riconnette secondo la propria politica. Concedetegli un intervallo definito prima di intervenire e registrate l’avanzamento di ricezione e applicazione ai due estremi di quell’intervallo. Un canale che si riavvia e un canale aggiornato sono riscontri diversi.

Confermate che l’applicatore ha raggiunto la posizione attuale della sorgente, non solo la fine del vecchio arretrato. Verificate che nessun errore sia in attesa nell’applicatore, perché un solo evento fallito ferma l’avanzamento mentre il ricevitore continua a segnalare la connessione. Poi registrate le prove: nome del canale, entrambi gli stati di fase, la posizione eseguita e l’ora. Un indicatore verde è un’affermazione; la posizione è un fatto.