A replikáció a változásokat egy source (master)-ről egy vagy több replica-ra streameli. A source minden commitolt változást rögzít a binary logjában (binlog); minden replica I/O szála lemásolja azt a logot, és egy SQL/applier szál visszajátssza, így a replicák ugyanahhoz az adathoz konvergálnak.
íások
app ---------> --- binlog ---> <-- olvasások
| <-- olvasások
+---------- binlog ---> <-- olvasások
ROW (a tényleges sor-képeket logolja, biztonságos alapértelmezett), STATEMENT vagy MIXED.Az írásokat a source-ra irányítsd, a SELECT-eket pedig terítsd szét a replicák között. Az olvasás-intenzív appok (a legtöbb webalkalmazás) szinte lineárisan skálázzák az olvasásokat replicák hozzáadásával, miközben az egyetlen source továbbra is minden írást kezel.
-- Egy replicán figyeld, mennyire van lemaradva:
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source: 2 <- replikációs lemaradás (lag)
-- Replica_IO_Running: Yes
-- Replica_SQL_Running: Yes
Mivel az async replicák a source mögött kullognak, egy felhasználó, aki ír, majd azonnal olvas egy replicáról, esetleg nem látja a saját változását ("read-your-writes" megsértés). A latencia-érzékeny vagy éppen most írt olvasásokat a source-ra irányítsd, vagy használj semi-synct.
A replikáció a standard első lépés az olvasások skálázásához és egy meleg tartalék (warm standby) megszerzéséhez failoverhez/mentésekhez. A meghatározó korlátja — a lag és az egyetlen írási szűk keresztmetszet — alakítja a valós terveket: megmagyarázza, miért olvasol néha elavult adatot, és miért igényel az írás-skálázás végül shardingot, nem csak több replicát.
IT interjúkérdések gyűjteménye részletes válaszokkal — Juniortól Seniorig.
Adományozás