Replikering strömmar ändringar från en source (master) till en eller flera replicas. Källan registrerar varje committad ändring i sin binary log (binlog); varje replicas I/O-tråd kopierar den loggen och en SQL/applier-tråd spelar upp den, så att replicas konvergerar mot samma data.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (loggar faktiska radavbildningar, säkert standardval), STATEMENT eller MIXED.Rikta skrivningar mot källan och sprid SELECT:er över replicas. Lästunga appar (de flesta webbappar) skalar läsningar nästan linjärt genom att lägga till replicas, medan den enda källan fortfarande hanterar alla skrivningar.
-- 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
Eftersom asynkrona replicas släpar efter källan kan en användare som skriver och sedan omedelbart läser från en replica inte se sin egen ändring ("read-your-writes"-överträdelse). Dirigera latenskänsliga eller nyss skrivna läsningar till källan, eller använd semi-sync.
Replikering är det vanliga första steget för att skala läsningar och för att få en varm standby för failover/backuper. Dess definierande begränsning — fördröjning, och den enda skrivflaskhalsen — formar verkliga designer: den förklarar varför du ibland läser inaktuell data och varför skrivskalning så småningom behöver sharding, inte bara fler replicas.
Ett bibliotek med IT-intervjufrågor och detaljerade svar — från Junior till Senior.
Donera