Replicatie streamt wijzigingen van een source (master) naar een of meer replicas. De source registreert elke gecommitte wijziging in zijn binary log (binlog); de I/O-thread van elke replica kopieert die log en een SQL/applier-thread speelt hem opnieuw af, zodat replicas naar dezelfde data convergeren.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (logt de werkelijke row images, veilige standaard), STATEMENT of MIXED.Richt writes op de source en verdeel SELECTs over de replicas. Leesintensieve apps (de meeste webapps) schalen reads bijna lineair door replicas toe te voegen, terwijl de enkele source nog steeds alle writes afhandelt.
-- 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
Omdat async replicas achter de source aan lopen, ziet een gebruiker die schrijft en dan meteen van een replica leest zijn eigen wijziging mogelijk niet (een "read-your-writes"-schending). Route latency-gevoelige of net-geschreven reads naar de source, of gebruik semi-sync.
Replicatie is de standaard eerste stap om reads te schalen en om een warme standby te krijgen voor failover/backups. De bepalende beperking — lag, en de enkele write-bottleneck — vormt echte ontwerpen: het verklaart waarom je soms verouderde data leest en waarom write scaling uiteindelijk sharding nodig heeft, niet alleen meer replicas.
Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren