La replica circolare MariaDB permette a più nodi di ricevere e propagare scritture, ma non risolve automaticamente i conflitti applicativi. MaxScale può gestire instradamento e monitoraggio delle connessioni: è un componente complementare alla replica.
Nel nostro archivio operativo è documentata una configurazione con due nodi database, proxy MaxScale e sincronizzazione dei file tra server web. Nel luglio 2026 quella struttura è stata smontata durante un consolidamento. È quindi un’esperienza da cui ricavare criteri, non la descrizione dell’architettura attuale né una ricetta universale per WordPress.
Separare disponibilità e correttezza dei dati
Un secondo nodo può aiutare a riprendere il servizio dopo un guasto. La qualità del recupero dipende però da quali transazioni ha ricevuto e da quali scritture continua ad accettare il nodo precedente.
Con replica asincrona, una conferma al client non significa necessariamente che la modifica sia già presente sull’altro nodo. La procedura di failover deve tenere conto del ritardo e impedire che due percorsi incompatibili continuino a ricevere scritture.
Un proxy che vede un server raggiungibile non dimostra che i dati siano coerenti. Servono controlli sul ruolo dei nodi, stato della replica ed esito delle operazioni applicative.
Gli identificatori alternati non risolvono tutti i conflitti
La documentazione MariaDB sulla replica ad anello descrive configurazione e limiti di questa topologia. Offset diversi per gli auto-increment possono evitare alcune collisioni tra nuovi identificatori.
Non impediscono però a due scritture di modificare la stessa riga, né risolvono vincoli univoci su altri campi. Un’applicazione con più writer richiede una strategia coerente per questi casi; non basta osservare che normalmente le redazioni lavorano su articoli diversi.
Il recupero richiede una fonte dati scelta consapevolmente
Quando la replica si interrompe, salterei la tentazione di “far tornare verde” il monitor cancellando la posizione dell’errore. Prima bisogna capire quale transazione manca, se esiste divergenza e quali dati devono essere conservati.
Una ricostruzione da copia consistente può essere più chiara di una riparazione improvvisata, ma va preparata con backup, binlog disponibili e verifica del nodo scelto come sorgente. Non pubblicherei una sequenza di reset come soluzione valida per qualunque incidente.
Database e file devono raccontare la stessa pubblicazione
WordPress comprende anche media, plugin e configurazioni. Replicare il database senza coordinare i file può lasciare allegati assenti; una sincronizzazione bidirezionale dei file introduce a sua volta conflitti e propagazione delle cancellazioni.
Nel consolidamento documentato, il cambio di topologia ha richiesto di aggiornare anche configurazione applicativa e automazioni precedenti. Un vecchio script di failover ancora attivo può interferire con il nuovo assetto.
La lezione che conservo è valutare la disponibilità insieme alla capacità di operare il sistema. Una struttura più semplice può essere una scelta ragionevole quando soddisfa gli obiettivi di ripristino e rende più comprensibili backup, manutenzione e responsabilità.