Zestawy rozmówBlog

Twoja wymarzona praca? Lets Git IT.
Interaktywna platforma przygotowująca do rozmów technicznych dla nowoczesnych programistów.

XGitHub

Platforma

  • Kategorie

Zasoby

  • Blog
  • O aplikacji
  • FAQ
  • Sugestie

Prawne

  • Polityka prywatności
  • Regulamin

© 2026 LetsGit.IT. Wszelkie prawa zastrzeżone.

LetsGit.IT/Kategorie/Chmura
Chmurahard

Jak projektować wysoką dostępność na awarie (multi-AZ vs multi-region)?

Tagi
#high-availability#multi-az#multi-region#failover
Wróć do kategoriiPrzejdź do quizu

Odpowiedź

Multi-AZ chroni przed awarią data center w regionie — mniejsze opóźnienia i prostsze operacje. Multi-region potrafi przetrwać awarię całego regionu, ale dokłada latency, złożoność replikacji danych i koszty.

Odpowiedź zaawansowana

Głębiej

Wysoka dostępność zaczyna się od zdefiniowania failure domainów i celów:

  • **RTO** (jak szybko musisz wrócić)
  • **RPO** (ile utraty danych jest akceptowalne)

Multi-AZ (w jednym regionie)

Typowy baseline:

  • stateless instancje aplikacji na 2–3 AZ,
  • load balancer z health checkami,
  • zarządzana baza w trybie multi-AZ albo replikacja/failover,
  • redundantne cache/kolejki.

Multi-region (między regionami)

Dla disaster recovery lub globalnego latency:

  • **active-passive**: jeden region obsługuje ruch, drugi jest standby (prościej, ale czas failover).
  • **active-active**: oba regiony obsługują ruch (trudniej: spójność, konflikty, split-brain).

Praktyka

  • Multi-AZ domyślnie dla produkcji.
  • Multi-region, gdy Twoje RTO/RPO lub wymagania regulacyjne wymagają przetrwania awarii całego regionu.

Typowe pułapki

  • Ignorowanie semantyki replikacji (eventual consistency

Powiązane pytania

Chmura
Disaster recovery: backup/restore vs warm standby vs active-active — jaki jest trade-off?
#disaster-recovery#failover#multi-region
Mikroserwisy
Mikroserwisy multi-region: jakie są główne korzyści i główne problemy?
#microservices#multi-region#availability
, konflikty zapisów).
  • Brak testów failover.
  • Traktowanie „multi-region” jako samego DNS; najtrudniejsza jest zwykle warstwa danych.