Replication hupitisha mabadiliko kutoka source (master) hadi replicas moja au zaidi. Source hurekodi kila badiliko lililo-commit katika binary log (binlog) yake; I/O thread ya kila replica hunakili log hiyo na SQL/applier thread huirudia, hivyo replicas hufikia data ile ile.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (hurekodi row images halisi, chaguo-msingi salama), STATEMENT, au MIXED.Elekeza writes kwenye source na sambaza SELECTs kwenye replicas. Programu zenye reads nyingi (web apps nyingi) huongeza reads karibu kwa mstari (linearly) kwa kuongeza replicas, huku source moja bado ikishughulikia writes zote.
-- 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
Kwa sababu replicas za async zinafuata nyuma ya source, mtumiaji anayeandika kisha mara moja anasoma kutoka replica anaweza asione badiliko lake mwenyewe (ukiukaji wa "read-your-writes"). Elekeza reads nyeti kwa latency au zilizoandikwa hivi punde kwenda kwenye source, au tumia semi-sync.
Replication ni hatua ya kwanza ya kawaida ya kuongeza reads na kupata standby ya joto kwa failover/backups. Kikwazo chake kikuu — lag, na bottleneck ya write moja — huunda designs halisi: kinaeleza kwa nini wakati mwingine unasoma data iliyopitwa na wakati na kwa nini kuongeza writes hatimaye kunahitaji sharding, siyo tu replicas zaidi.
Maktaba ya maswali ya mahojiano ya IT yenye majibu ya kina — kutoka Junior hadi Senior.
Changia