Replikace streamuje změny ze zdroje (master) na jednu nebo více replik. Zdroj zaznamenává každou potvrzenou změnu do svého binárního logu (binlog); I/O vlákno každé repliky ten log kopíruje a SQL/aplikační vlákno jej znovu přehrává, takže repliky konvergují ke stejným datům.
zápisy
app ---------> --- binlog ---> <-- čtení
| <-- čtení
+---------- binlog ---> <-- čtení
ROW (loguje skutečné obrazy řádků, bezpečné výchozí), STATEMENT nebo MIXED.Zápisy směřujte na zdroj a SELECTy rozprostřete mezi repliky. Aplikace s velkým čtením (většina webových aplikací) škálují čtení téměř lineárně přidáváním replik, zatímco jediný zdroj stále zvládá všechny zápisy.
-- Na replice sledujte, jak moc zaostává:
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source: 2 <- zpoždění replikace
-- Replica_IO_Running: Yes
-- Replica_SQL_Running: Yes
Protože async repliky vlečou za zdrojem, uživatel, který zapíše a pak si okamžitě čte z repliky, nemusí vidět svou vlastní změnu (porušení "read-your-writes"). Latenčně citlivá nebo právě zapsaná čtení směrujte na zdroj, nebo použijte semi-sync.
Replikace je standardní první krok ke škálování čtení a k získání teplé zálohy pro failover/zálohy. Její definující omezení — zpoždění a jediné hrdlo zápisu — utváří reálné návrhy: vysvětluje, proč někdy čtete zastaralá data a proč škálování zápisu nakonec potřebuje shardování, ne jen více replik.
Knihovna IT otázek k pohovoru s podrobnými odpověďmi — od Junior po Senior.
Přispět