Replikacja przesyła strumieniowo zmiany ze źródła (master) do jednej lub więcej replik. Źródło zapisuje każdą zatwierdzoną zmianę w swoim dzienniku binarnym (binlog); wątek I/O każdej repliki kopiuje ten dziennik, a wątek SQL/aplikujący odtwarza go, tak że repliki zbiegają się do tych samych danych.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (loguje faktyczne obrazy wierszy, bezpieczna wartość domyślna), STATEMENT lub MIXED.Kieruj zapisy do źródła i rozłóż SELECT-y na repliki. Aplikacje zdominowane przez odczyty (większość aplikacji webowych) skalują odczyty niemal liniowo poprzez dodawanie replik, podczas gdy pojedyncze źródło nadal obsługuje wszystkie zapisy.
-- 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
Ponieważ asynchroniczne repliki pozostają w tyle za źródłem, użytkownik, który zapisuje, a następnie natychmiast odczytuje z repliki, może nie zobaczyć własnej zmiany (naruszenie „read-your-writes"). Kieruj odczyty wrażliwe na opóźnienia lub dopiero co zapisane do źródła albo używaj semi-sync.
Replikacja to standardowy pierwszy krok do skalowania odczytów oraz do uzyskania gorącej rezerwy na potrzeby przełączania awaryjnego/kopii zapasowych. Jej definiujące ograniczenie — opóźnienie oraz pojedyncze wąskie gardło zapisu — kształtuje rzeczywiste projekty: wyjaśnia, dlaczego czasami odczytujesz nieaktualne dane i dlaczego skalowanie zapisów ostatecznie wymaga shardingu, a nie tylko większej liczby replik.
Biblioteka pytań rekrutacyjnych IT ze szczegółowymi odpowiedziami — od Juniora do Seniora.
Wesprzyj