Replikering streamer ændringer fra en source (master) til en eller flere replicas. Source'en registrerer hver committet ændring i sin binary log (binlog); hver replicas I/O-tråd kopierer den log, og en SQL-/applier-tråd afspiller den igen, så replicas konvergerer til de samme data.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (logger faktiske række-images, sikker default), STATEMENT eller MIXED.Peg writes mod source'en og spred SELECTs ud over replicas. Læsetunge apps (de fleste webapps) skalerer læsninger næsten lineært ved at tilføje replicas, mens den enkelte source stadig håndterer alle writes.
-- 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 halter efter source'en, ser en bruger, der skriver og derefter straks læser fra en replica, måske ikke sin egen ændring (en overtrædelse af "read-your-writes"). Rut latency-følsomme eller netop-skrevne læsninger til source'en, eller brug semi-sync.
Replikering er det standard første skridt til at skalere læsninger og til at få en varm standby til failover/backups. Dens definerende begrænsning — lag og den enkelte write-flaskehals — former rigtige designs: den forklarer, hvorfor du nogle gange læser forældede data, og hvorfor write-skalering til sidst kræver sharding, ikke bare flere replicas.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér