Replikacija prenosi promjene s izvora (master) na jednu ili više replika. Izvor bilježi svaku potvrđenu promjenu u svoj binarni log (binlog); I/O nit svake replike kopira taj log, a SQL/applier nit ga ponovno izvodi, pa se replike konvergiraju na iste podatke.
upisi
app ---------> --- binlog ---> <-- čitanja
| <-- čitanja
+---------- binlog ---> <-- čitanja
ROW (bilježi stvarne slike redaka, sigurno zadano), STATEMENT ili MIXED.Usmjerite upise na izvor i raspodijelite SELECT-ove po replikama. Aplikacije s puno čitanja (većina web aplikacija) skaliraju čitanja gotovo linearno dodavanjem replika, dok jedini izvor i dalje obrađuje sve upise.
-- Na replici, promatrajte koliko zaostaje:
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source: 2 <- zaostajanje replikacije
-- Replica_IO_Running: Yes
-- Replica_SQL_Running: Yes
Budući da async replike zaostaju za izvorom, korisnik koji upiše pa odmah pročita s replike možda neće vidjeti vlastitu promjenu (kršenje "read-your-writes"). Usmjerite čitanja osjetljiva na latenciju ili upravo upisana na izvor, ili koristite semi-sync.
Replikacija je standardni prvi korak za skaliranje čitanja i za dobivanje toplog rezervnog poslužitelja za failover/sigurnosne kopije. Njezino ključno ograničenje — zaostajanje, i usko grlo jedinstvenog upisa — oblikuje stvarne dizajne: objašnjava zašto ponekad čitate zastarjele podatke i zašto skaliranje upisa naposljetku treba sharding, a ne samo više replika.
Knjižnica IT pitanja za razgovore za posao s detaljnim odgovorima — od Juniora do Seniora.
Doniraj