Cos'è la replicazione dei dati?

La replicazione è il meccanismo con cui più copie dello stesso dato restano sincronizzate su nodi diversi, così che il guasto di un nodo o un carico eccessivo non fermino il sistema. Esistono due strategie opposte. La replicazione sincrona conferma una scrittura solo dopo che almeno un'altra copia l'ha ricevuta: nessuna perdita se si guasta il solo primario, a costo di una latenza più alta su ogni scrittura, perché il client aspetta la conferma di un nodo remoto. La replicazione asincrona conferma subito e propaga il cambiamento un istante dopo: scritture veloci, ma una finestra in cui il nodo primario può perdere dati non ancora arrivati alle repliche se si guasta in quel momento. La topologia più diffusa è primary-replica, con un solo nodo che accetta scritture e gli altri in sola lettura; alcuni sistemi adottano invece il multi-primary, dove più nodi accettano scritture in parallelo e serve una regola esplicita di risoluzione dei conflitti quando due nodi modificano lo stesso dato quasi nello stesso istante.

Il ritardo che si paga e la distanza che lo aggrava

Il costo pratico della replicazione asincrona si chiama replication lag: il tempo tra la scrittura sul primario e il suo arrivo su una replica. Ha una conseguenza applicativa diretta: un utente che scrive un dato e lo rilegge subito dopo, se la lettura finisce su una replica indietro di qualche centinaio di millisecondi, non lo trova, o trova la versione precedente, come il carrello che sembra svuotarsi dopo un ordine appena confermato. Il quorum, nei sistemi multi-primary o distribuiti, decide quante copie devono confermare una scrittura prima che l'operazione sia valida: un quorum stretto è veloce e resta scrivibile anche con più nodi guasti, ma offre garanzie più deboli su consistenza e durabilità; uno largo è più sicuro su entrambe, al prezzo di più latenza e di una soglia di guasti tollerati più bassa. Quando la replica è geografica, tra continenti, il vincolo non è più solo ingegneristico: tra Irlanda e Virginia ci sono circa 5.500 chilometri, che alla velocità della luce nella fibra fanno un pavimento di circa 55 millisecondi per andata e ritorno, prima ancora di contare instradamento e apparati. È un limite fisico che nessun software elimina.

Un esempio enterprise

Una banca che sposta i saldi conto su un cluster multi-region, per garantire continuità anche se un intero data center va offline, sceglie quasi sempre la replicazione sincrona sul quorum minimo che tollera un guasto, accettando qualche millisecondo di latenza in più su ogni bonifico pur di non perdere mai una transazione confermata. Un e-commerce che replica il catalogo prodotti su più region sceglie l'opposto: replicazione asincrona, perché un prezzo aggiornato con un secondo di ritardo non causa danno, mentre la latenza sincrona su ogni lettura di catalogo ucciderebbe i tempi di risposta. La stessa piattaforma può usare strategie diverse per dati diversi, e l'errore da evitare è applicare a tutto il regime più costoso.

Perché conta per chi decide

La replicazione è il meccanismo su cui poggiano durabilità e disponibilità, ma le due non coincidono: un dato può essere durevole, scritto su più copie che sopravvivono al guasto di una, e insieme temporaneamente non disponibile in lettura coerente su tutte, per via del ritardo. Confondere le due proprietà porta a promettere obiettivi di continuità che l'architettura scelta non sostiene: la scelta tra replica sincrona e asincrona, tra primary-replica e multi-primary, va decisa insieme agli obiettivi di tempo e punto di ripristino, non dopo. Un RPO vicino allo zero richiede replica sincrona o quasi; uno di ore si accontenta dell'asincrona. Quando lo scopo non è la continuità del database operativo ma alimentare analisi o altri sistemi, la risposta è spesso una read replica o il change data capture, non un ulteriore livello di replicazione sincrona.