Replikacja synchroniczna i asynchroniczna danych

Replikacja synchroniczna ma zastosowanie w niektórych przypadkach, ale jej użycie zależy od wymagań konkretnej aplikacji, dostępnej infrastruktury oraz tolerancji na opóźnienia. Omówmy szczegółowo różnice między replikacją synchroniczną a asynchroniczną i dlaczego ta druga jest częściej rekomendowana w scenariuszach takich jak ten.

1. Różnice między replikacją synchroniczną a asynchroniczną

---

Cechy	Replikacja synchroniczna	Replikacja asynchroniczna
Mechanizm zapisu	Transakcja jest zatwierdzana dopiero, gdy dane zostaną zapisane na replikach.	Transakcja jest zatwierdzana natychmiast po zapisaniu na głównej instancji.
Opóźnienia	Większe opóźnienia, szczególnie przy dużych odległościach geograficznych.	Minimalne opóźnienia, dane są przesyłane w tle.
Trwałość danych	Gwarantuje brak utraty danych w przypadku awarii głównego serwera.	Możliwe jest niewielkie opóźnienie w synchronizacji danych, które może skutkować utratą pewnej ilości danych.
Odporność na awarie	Lepsza, ponieważ dane na replikach są zawsze aktualne.	Gorsza, bo repliki mogą mieć dane opóźnione o kilka sekund lub minut.
Zastosowania	Środowiska wymagające wysokiej spójności (np. systemy bankowe).	Środowiska o dużym rozproszeniu geograficznym i wysokiej dostępności.

2. Zalety i wady replikacji synchronicznej

Zalety:

• Gwarancja spójności danych:
  • Wszystkie zapisy są natychmiast dostępne na replikach, co eliminuje ryzyko utraty danych w przypadku awarii głównego serwera.
• Idealna dla krytycznych aplikacji:
  • W systemach wymagających najwyższego poziomu niezawodności (np. systemy finansowe, medyczne) spójność jest kluczowa.

Wady:

• Większe opóźnienia:
  • Transakcje czekają na potwierdzenie zapisu na replikach. Przy dużych odległościach geograficznych lub słabym połączeniu sieciowym może to powodować znaczące opóźnienia.
• Obciążenie infrastruktury:
  • Synchronizacja wymaga szybkiej i stabilnej sieci oraz dużej mocy obliczeniowej.
• Złożoność:
  • Konfiguracja i utrzymanie replikacji synchronicznej jest bardziej skomplikowane.

---

3. Dlaczego replikacja asynchroniczna jest często preferowana?

W wielu przypadkach, takich jak w Twoim scenariuszu, replikacja asynchroniczna jest bardziej praktyczna. Powody to:

1. Lepsza wydajność:
   • Replikacja asynchroniczna minimalizuje opóźnienia zapisu. Użytkownicy aplikacji nie muszą czekać na potwierdzenie zapisu na replikach, co poprawia wydajność.
2. Geograficzna redundancja:
   • W przypadku replikacji między regionami lub odległymi lokalizacjami, opóźnienia związane z synchronizacją mogą być znaczne. Asynchroniczność eliminuje ten problem.
3. Tolerancja na chwilowe opóźnienia:
   • Jeśli utrata danych w ciągu kilku sekund lub minut jest akceptowalna, replikacja asynchroniczna jest prostsza i bardziej niezawodna.
4. Mniejsze wymagania infrastrukturalne:
   • Nie wymaga szybkiego połączenia sieciowego ani natychmiastowego potwierdzania zapisu na replikach.

---

4. Kiedy replikacja synchroniczna ma sens?

Replikacja synchroniczna może być stosowana w środowiskach wymagających najwyższej spójności danych i minimalnej utraty informacji, takich jak:

1. Krytyczne aplikacje transakcyjne:
   • Systemy bankowe, giełdowe lub inne aplikacje finansowe.
2. Środowiska o niskim opóźnieniu sieciowym:
   • Replikacja w tym samym centrum danych lub między serwerami połączonymi szybkim i stabilnym łączem.
3. Wymóg RPO = 0 (Recovery Point Objective):
   • Jeśli każda transakcja musi być w pełni zapisana na replikach przed jej zatwierdzeniem.

---

5. Co można zrobić, aby zbliżyć replikację asynchroniczną do poziomu bezpieczeństwa synchronicznej?

1. Ustawienia opóźnienia replikacji:
   • PostgreSQL umożliwia monitorowanie opóźnienia replikacji (np. przy użyciu pg_stat_replication), aby upewnić się, że dane są szybko przesyłane na replikę.
2. Częstsze archiwizowanie WAL:
   • W środowisku z replikacją asynchroniczną regularne kopiowanie logów WAL dodatkowo zwiększa bezpieczeństwo danych.
3. Dodatkowe mechanizmy monitorowania:
   • Narzędzia do automatycznego przełączania na replikę (np. Patroni, repmgr) mogą skrócić czas przestoju w przypadku awarii.
4. Zastosowanie synchronous_commit:
   • PostgreSQL pozwala na hybrydowe podejście: główny serwer może czekać na potwierdzenie od jednej z replik synchronicznych, ale pozostałe mogą działać asynchronicznie.

---

5.1 Podsumowanie

Replikacja synchroniczna ma zastosowanie w środowiskach wymagających najwyższego poziomu spójności danych, ale wiąże się z opóźnieniami i większymi wymaganiami infrastrukturalnymi. W większości przypadków replikacja asynchroniczna jest bardziej praktyczna, zwłaszcza jeśli serwery znajdują się w różnych lokalizacjach fizycznych lub regionach geograficznych.

6. Utrata danych przy replikacji synchronicznej i asynchronicznej

Podczas awarii większą utratę danych może wprowadzić replikacja asynchroniczna, ponieważ dane nie są zapisywane jednocześnie na wszystkich replikach, a transakcje mogą zostać utracone w czasie pomiędzy ich zatwierdzeniem na serwerze głównym a przesłaniem ich na replikę.

6.1 Dlaczego replikacja asynchroniczna może prowadzić do większej utraty danych?

W przypadku replikacji asynchronicznej:

1. Mechanizm działania:
   • Serwer główny zatwierdza transakcję (commit) bez czekania na potwierdzenie, że dane zostały zapisane na replikach.
   • Dane są przesyłane do replik w tle (z opóźnieniem), co oznacza, że w momencie awarii głównego serwera niektóre transakcje mogły nie dotrzeć na replikę.
2. Skutki awarii:
   • Transakcje zatwierdzone na serwerze głównym, ale niezreplikowane, zostaną utracone.
   • Im większe opóźnienie replikacji (lag), tym większa potencjalna utrata danych.

6.2 Dlaczego replikacja synchroniczna minimalizuje utratę danych?

W przypadku replikacji synchronicznej:

1. Mechanizm działania:
   • Serwer główny zatwierdza transakcję dopiero po otrzymaniu potwierdzenia, że dane zostały zapisane na przynajmniej jednej (lub więcej) replikach.
   • Dzięki temu wszystkie dane są spójne między serwerem głównym a replikami w momencie zakończenia transakcji.
2. Skutki awarii:
   • Jeśli główny serwer ulegnie awarii lub niekontrolowanemu restartowi, repliki będą miały wszystkie dane do momentu ostatniej zatwierdzonej transakcji.
   • Utrata danych jest praktycznie wyeliminowana (RPO = 0), ponieważ każda zatwierdzona transakcja została zapisana na replikach.

---

6.3 Podsumowanie porównania

Cecha	Replikacja synchroniczna	Replikacja asynchroniczna
Możliwość utraty danych	Minimalna (RPO = 0)	Może dojść do utraty danych, zależy od opóźnienia replikacji (lag).
Przyczyna utraty danych	Awaria między zapisem danych na głównym serwerze i replikach nie występuje, bo transakcje są potwierdzane dopiero po zapisaniu na replikach.	Awaria może spowodować utratę transakcji zatwierdzonych na głównym serwerze, ale jeszcze nie przesłanych na repliki.
Zastosowanie	Środowiska wymagające wysokiej spójności (np. finansowe, krytyczne aplikacje).	Środowiska tolerujące niewielką utratę danych (np. aplikacje o dużym rozproszeniu geograficznym).

---

6.4 Którą replikacje wybrać?

• Replikacja synchroniczna: Jeśli utrata danych jest absolutnie niedopuszczalna.
• Replikacja asynchroniczna: Jeśli priorytetem są niskie opóźnienia, wydajność lub redundancja geograficzna, a niewielka utrata danych jest akceptowalna.

Wniosek: Synchroniczna replikacja oferuje większe bezpieczeństwo danych, ale kosztem wydajności i tolerancji na opóźnienia w sieci.