Percona ClusterSync 1.0.0 aggiunge il failover automatico per MongoDB
Percona ClusterSync per MongoDB, lo strumento che sposta i dati tra cluster MongoDB, ha raggiunto la versione 1.0.0 con una modalità di alta disponibilità attivo-standby integrata. In un post sul blog pubblicato il 30 settembre 2026, l'autore Adnan Supic, con una nota dell'editore che accredita Inel Pandzic, spiega che fino ad ora ClusterSync era un singolo punto di guasto: se l'host, il container o il pod che eseguiva lo strumento andava in crash, la replica si fermava e un operatore doveva accorgersi dell'interruzione e recuperare manualmente il processo. La nuova versione consente agli operatori di eseguire più istanze contro gli stessi cluster di origine e destinazione, in modo che un'istanza standby subentri automaticamente quando quella attiva fallisce.
Il funzionamento della nuova modalità è semplice. Ora puoi eseguire più istanze di Percona ClusterSync puntate agli stessi cluster MongoDB di origine e destinazione. Le istanze si coordinano tramite un lease basato su MongoDB memorizzato sul cluster di destinazione, in un database chiamato percona_clustersync_mongodb. Esattamente un'istanza detiene il lease ed è ATTIVA, ovvero esegue la replica. Le altre restano in STANDBY e attendono che il lease scada. Non c'è alcun coordinatore esterno; il cluster MongoDB di destinazione che già possiedi funge da fonte di verità. L'alta disponibilità è sempre attiva e non richiede modifiche di configurazione. Una singola istanza vince semplicemente il lease immediatamente e si comporta esattamente come prima. Se desideri il failover, avvia una seconda o terza istanza con la stessa origine e destinazione, e la distribuzione è completa.
Tre meccanismi rendono sicuro il failover: elezione basata su lease, term fencing e recupero basato su checkpoint. L'elezione tramite lease evita lo split-brain perché tutto lo stato di coordinamento risiede nel database percona_clustersync_mongodb sulla destinazione. L'elezione è una singola scrittura condizionale atomica: un'istanza reclama il lease solo se quello corrente è scaduto, e la scadenza viene valutata rispetto all'orologio del server. Due standby in competizione non possono vincere entrambi, e lo skew di clock tra gli host di ClusterSync è irrilevante perché l'orologio di MongoDB è l'unico che conta. Il lease stesso è un piccolo documento con campi per l'identificatore del lease, il termine, l'ID dell'istanza, la data di elezione e il tempo di scadenza.
Il term fencing basato sul termine previene un classico guasto dei sistemi distribuiti noto come scrittura zombie. Il campo term è un token di fencing monotonico che incrementa a ogni elezione, a ogni cambiamento da ATTIVO a STANDBY, ed è impresso in ogni scrittura di checkpoint che l'ATTIVO effettua in percona_clustersync_mongodb.checkpoints. Se un ATTIVO si blocca a causa di una pausa di garbage collection, una partizione di rete o un pod ucciso e riavviato prima della scadenza del lease, il suo lease scade, uno standby viene promosso e la vecchia istanza potrebbe svegliarsi e tentare di scrivere come se nulla fosse. Con il term fencing, quell'attivo zombie porta un termine obsoleto, la destinazione rifiuta le sue scritture di checkpoint, l'istanza deposta se ne accorge e si auto-declassa a STANDBY. Il nuovo stato ATTIVO non viene mai corrotto.
Alla promozione, il nuovo ATTIVO riprende la replica dal checkpoint persistito, lo stesso meccanismo di recupero da crash che ClusterSync ha sempre usato, ora attivato automaticamente. I tempi sono fissi in questa versione: il TTL del lease è di 10 secondi, l'ATTIVO rinnova ogni 3 secondi e ogni istanza invia heartbeat ogni 3 secondi. In pratica, un ATTIVO terminato bruscamente viene sostituito entro circa il TTL del lease. Un limite da conoscere: l'alta disponibilità copre la fase di replica change-stream, ma il clone iniziale non è ripristinabile. Se l'ATTIVO muore durante il clone, uno standby viene comunque promosso, rileva il clone interrotto durante il recupero e fallisce in modo pulito con una ragione esplicita nei log e in /status: clone iniziale interrotto dal failover e non ripristinabile; avvia una nuova esecuzione per riclonare da zero. Il recupero è un semplice /start sul nuovo ATTIVO, che riavvia la sincronizzazione da zero. Il failover automatico entra in azione una volta che il clone è completato e inizia la replica continua.
La gestione di una distribuzione HA è progettata per essere esplicita piuttosto che basata su congetture. Ogni istanza mantiene un documento di liveness in percona_clustersync_mongodb.members sulla destinazione, e le risposte API includono un envelope di cluster in modo che un operatore che interroga qualsiasi nodo possa vedere chi è ATTIVO, l'istanza raggiunta, il ruolo e l'elenco completo dei membri con host, porta e ruolo di ogni istanza viva. Se invii un comando operativo come /start, /pause o /finalize a uno STANDBY, risponde con HTTP 409 ed errore not_active, con lo stesso envelope nel corpo, così il tuo client può individuare immediatamente l'ATTIVO e riprovare lì. L'envelope appare solo quando viene osservato più di un membro vivo; un'istanza solitaria restituisce risposte identiche byte per byte all'API pre-HA, quindi gli strumenti esistenti continuano a funzionare senza modifiche. Gli endpoint /metrics e pprof sono serviti su ogni ruolo. Per la pulizia, due nuovi comandi diretti cancellano lo stato HA sulla destinazione mentre nessun server è in esecuzione: pcsm reset members e pcsm reset lease.
L'osservabilità è integrata. Ogni istanza espone metriche HA su /metrics, su ogni ruolo: percona_clustersync_mongodb_ha_active è un gauge dove 1 significa ATTIVO e 0 significa STANDBY; percona_clustersync_mongodb_ha_term è un gauge per il termine corrente del lease; percona_clustersync_mongodb_ha_role_transitions_total è un contatore per i cambi di ruolo su questa istanza. Con queste poche metriche puoi costruire una dashboard che racconta l'intera storia HA a colpo d'occhio: una timeline di stato di ha_active per istanza funge da roster della distribuzione e mostra chi è ATTIVO e da quando, ha_term mostra il termine di fencing corrente, e il tasso di ha_role_transitions_total per istanza funziona come rilevatore di flap, dove 0 significa stabile e un numero in aumento indica problemi. Il progetto fornisce esattamente una dashboard Grafana JSON nel suo repository come punto di partenza. Una distribuzione sana a tre istanze mostra un ATTIVO, due STANDBY, termine 1 e nessuna transizione. Dopo che l'ATTIVO viene terminato, l'istanza sulla porta 2243 ha preso il controllo, il termine del lease è incrementato a 2 e il suo contatore di transizioni ha registrato la promozione; il vecchio ATTIVO si è riunito come STANDBY.
L'aggiornamento dalla versione precedente richiede un passaggio manuale: lo stato di replica dalla 0.9.0 non è compatibile con la 1.0.0, quindi gli operatori dovrebbero eseguire pcsm reset sulla destinazione prima di avviare la replica con la nuova versione. Dopodiché, avviare più di un'istanza è semplice come eseguire lo stesso comando su un altro host: pcsm --source "mongodb://src-mongos:27017" --target "mongodb://tgt-mongos:27017". Controlla /status su una delle due istanze e vedrai un ATTIVO e uno STANDBY. Termina l'ATTIVO e osserva lo standby riprendere la replica dall'ultimo checkpoint entro pochi secondi. Percona invita a segnalare bug, suggerire funzionalità e contribuire con codice, e rimanda alla documentazione PCSM per le prime sincronizzazioni.
Per i team che eseguono qualsiasi processo di replica dati di lunga durata, il modello qui è trasferibile. Memorizza lo stato di elezione del leader nel sistema di destinazione stesso, isola i vecchi leader con un numero di versione in modo che le scritture obsolete vengano rifiutate, e persisti i progressi in un checkpoint in modo che un successore possa riprendere senza ripartire da zero. Le metriche di osservabilità per ruolo, termine e transizioni trasformano un failover da incidente da scoprire a evento monitorabile. Le organizzazioni che preferiscono non gestire da sé questa logica di failover possono considerare servizi di database gestiti come AEU Data, che eseguono database con alta disponibilità, backup automatizzati e monitoraggio, così uno strumento di migrazione ha una destinazione affidabile contro cui fare failover.