Cel nauki: rozpoznać, kiedy replika danych jest potrzebnym mechanizmem architektonicznym, a kiedy zwiększa koszt i ryzyko bez mierzalnego zysku.

Fikcyjny scenariusz edukacyjny. Projekt nowej usługi zakłada dodatkową kopię danych „dla wydajności i bezpieczeństwa”. Nie określono jednak obciążenia, dopuszczalnej nieaktualności danych, zachowania podczas awarii ani osoby odpowiedzialnej za uzgadnianie rozbieżności. To modelowy przykład, nie opis konkretnego projektu.

Najpierw pytanie: jaką własność chcemy uzyskać?

Replika może odciążyć odczyty, skrócić odległość do danych albo zapewnić alternatywną ścieżkę obsługi. Sama kopia nie oznacza wysokiej dostępności: jeśli aplikacja nie potrafi przełączyć ruchu, replika nie skraca przerwy. Nie oznacza też kopii zapasowej: błędne zmiany i usunięcia mogą zostać zreplikowane.

WariantKiedy ma sensKonsekwencja do sprawdzenia
A. Bez repliki, optymalizacja źródłaProblemem są nieefektywne zapytania, indeksy lub niepotrzebne odczyty.Czy pomiary potwierdzają poprawę opóźnienia i przepustowości bez dodatkowej kopii?
B. Replika tylko do odczytuOddzielne zapytania analityczne przeciążają ścieżkę transakcyjną.Jaki lag jest akceptowalny? Co z odczytem po zapisie i ponowieniem zapytania po awarii?
C. Replika do przełączenia awaryjnegoWymagania odtwarzania uzasadniają drugi ośrodek lub węzeł.Jak wykryć awarię, uniknąć dwóch aktywnych źródeł zapisu, przełączyć i wrócić?

Decyzja nie jest automatycznie „B” ani „C”. Jeśli brak wymagań RPO/RTO i pomiarów, pierwszym krokiem jest określenie kryteriów, nie instalacja kolejnej bazy. Często tańsze są poprawne indeksy, cache ze świadomą polityką spójności albo asynchroniczny strumień do raportowania; każda alternatywa ma własne ryzyka.

Brama dowodowa

Przed zatwierdzeniem repliki zapisz: obciążenie i punkt odniesienia, wymaganą świeżość, model spójności, RPO/RTO, tryb przełączania, zakres danych i retencję oraz koszt operacyjny. Zmierz opóźnienie replikacji pod obciążeniem i wykonaj próbę awarii oraz powrotu. Jeżeli odczyt nie może tolerować nieaktualnych danych, kieruj go do autorytatywnego źródła.

Przykładowy ADR: „Nie wdrażamy repliki na etapie startu. Najpierw mierzymy obciążenie i opóźnienia, definiujemy dopuszczalną nieaktualność oraz cel odtworzenia. Replikę odczytową rozważymy dopiero, gdy test wykaże, że optymalizacja źródła nie spełnia SLO. Decyzja o HA wymaga osobnej próby przełączenia i powrotu”.

Powiązania: RPO i RTO: próba odtworzenia, decyzja warunkowa, SLO i budżet błędów.