Replikacja to utrzymywanie tej samej porcji danych na wielu serwerach jednocześnie, tak żeby zmiana zapisana w jednym miejscu trafiła też do pozostałych kopii. Robisz to z dwóch głównych powodów: dostępności (gdy jeden serwer padnie, drugi przejmuje ruch) oraz skalowania odczytów (kilka kopii obsługuje zapytania SELECT, zamiast męczyć jeden węzeł). Replikacja to nie to samo co backup — kopia odzwierciedla też Twoje pomyłki, więc skasowana przez przypadek tabela zniknie ze wszystkich węzłów w mgnieniu oka.
Jak to działa
Najczęściej spotkasz model master-slave (dziś częściej nazywany primary-replica): jeden węzeł przyjmuje zapisy, a resztę synchronizuje, wysyłając im strumień zmian — zwykle w postaci logu transakcji (WAL w PostgreSQL, binlog w MySQL). Repliki odtwarzają te operacje u siebie i mogą serwować odczyty. W modelu multi-master zapisywać można na kilku węzłach naraz, co brzmi świetnie, dopóki dwóch użytkowników nie zmieni tego samego wiersza w tej samej chwili — wtedy musisz rozwiązać konflikt zapisu, a to potrafi być droga przez mękę.
Druga ważna oś to replikacja synchroniczna kontra asynchroniczna. Synchroniczna potwierdza zapis dopiero, gdy replika go odbierze (bezpieczniej, ale wolniej). Asynchroniczna potwierdza od razu, a kopie doganiają primary z drobnym opóźnieniem (replication lag) — szybciej, ale ryzykujesz utratę ostatnich transakcji przy awarii.
Przykład z praktyki
W PostgreSQL klasyk to streaming replication. Na nowym serwerze robisz kopię bazową komendą:
pg_basebackup -h primary-host -D /var/lib/postgresql/data -U replikator -R
Flaga -R generuje konfigurację trybu standby, a replika sama łączy się z primary i ciągnie WAL. Lag sprawdzisz zapytaniem SELECT now() - pg_last_xact_replay_timestamp(); uruchomionym na replice. Gdy primary padnie, awansujesz standby na nowy primary (pg_ctl promote) — najlepiej automatycznie, narzędziem typu Patroni.
Częste błędy i mity
- „Mam replikację, więc nie potrzebuję backupów.” Nie.
DROP TABLEzreplikuje się tak samo sprawnie jak każda inna komenda. - Czytanie z repliki tuż po zapisie. Przez lag możesz nie zobaczyć danych, które przed chwilą zapisałeś (problem read-your-writes).
- Multi-master „bo brzmi mocniej”. Jeśli nie masz realnej potrzeby zapisu w wielu lokalizacjach, primary-replica jest prostszy i mniej zawodny.
Pojęcia powiązane: sharding, klaster bazodanowy, failover, twierdzenie CAP, eventual consistency, load balancing, backup.