La replica trasmette le modifiche da una source (master) a una o più replica. La source registra ogni modifica committata nel suo binary log (binlog); il thread di I/O di ogni replica copia quel log e un thread SQL/applier lo riapplica, così le replica convergono verso gli stessi dati.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (registra le immagini effettive delle righe, default sicuro), STATEMENT o MIXED.Indirizza le scritture alla source e distribuisci le SELECT tra le replica. Le app read-heavy (la maggior parte delle web app) scalano le letture quasi linearmente aggiungendo replica, mentre la singola source gestisce comunque tutte le scritture.
-- Su una replica, controlla quanto è indietro:
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source: 2 <- ritardo di replica
-- Replica_IO_Running: Yes
-- Replica_SQL_Running: Yes
Poiché le replica async sono in ritardo rispetto alla source, un utente che scrive e poi legge immediatamente da una replica potrebbe non vedere la propria modifica (violazione del "read-your-writes"). Indirizza alla source le letture sensibili alla latenza o appena scritte, oppure usa il semi-sync.
La replica è il primo passo standard per scalare le letture e ottenere uno standby caldo per failover/backup. Il suo limite caratteristico — il ritardo e il singolo collo di bottiglia in scrittura — plasma i progetti reali: spiega perché a volte leggi dati obsoleti e perché lo scaling delle scritture prima o poi richiede lo sharding, non solo più replica.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona