Replikering strømmer endringer fra en source (master) til en eller flere replicas. Source-en registrerer hver committet endring i sin binary log (binlog); hver replicas I/O-tråd kopierer den loggen og en SQL/applier-tråd spiller den av, slik at replicas konvergerer mot samme data.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (logger faktiske rad-bilder, trygg standard), STATEMENT eller MIXED.Rett skriving mot source-en og fordel SELECT-er utover replicas. Lesetunge apper (de fleste web-apper) skalerer lesing nesten lineært ved å legge til replicas, mens den ene source-en fortsatt håndterer all skriving.
-- On a replica, watch how far behind it is:
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source: 2 <- replication lag
-- Replica_IO_Running: Yes
-- Replica_SQL_Running: Yes
Fordi async-replicas henger etter source-en, kan en bruker som skriver og deretter umiddelbart leser fra en replica, ikke se sin egen endring (brudd på "read-your-writes"). Rut latensfølsomme eller nettopp skrevne lesninger til source-en, eller bruk semi-sync.
Replikering er det standardiserte første steget for å skalere lesing og for å få en varm standby til failover/backuper. Dens definerende begrensning — lag, og den ene skriveflaskehalsen — former reelle design: den forklarer hvorfor du av og til leser utdaterte data og hvorfor skriveskalering til slutt trenger sharding, ikke bare flere replicas.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner