Tryb read-only dla replik

Tryb read-only dla replik ogranicza je wyłącznie do obsługi zapytań odczytu, odciążając replikę podstawową.

Na czym polega tryb read-only dla repliki

Tryb read-only dla repliki oznacza, że dana instancja bazy danych może przyjmować operacje odczytu, natomiast nie powinna samodzielnie wykonywać zapisów zmieniających dane. Zapytania typu SELECT mogą być kierowane do repliki, a operacje takie jak INSERT, UPDATE i DELETE są odrzucane albo blokowane przez mechanizmy konkretnego silnika. Ograniczenie dotyczy lokalnego przetwarzania zmian na replice i ma zapobiegać sytuacji, w której aplikacja przypadkowo modyfikuje kopię używaną do odczytu.

Replika otrzymuje zmiany z innego źródła, zwykle z instancji podstawowej, za pośrednictwem mechanizmu replikacji właściwego dla danego systemu bazodanowego. W zależności od produktu mogą być przesyłane rekordy dziennika transakcji, operacje logiczne albo inne informacje potrzebne do odtworzenia zmian. Sam termin „read-only” nie wskazuje jednej konkretnej technologii ani jednej komendy konfiguracyjnej, dlatego sposób włączenia i zakres blokady trzeba ustalać na podstawie dokumentacji używanego silnika.

Jak replika przetwarza odczyty i napływające zmiany

Podczas normalnej pracy replika wykonuje dwa różne rodzaje zadań. Pierwszym jest obsługa zapytań kierowanych przez aplikacje, narzędzia raportowe lub administratora. Drugim jest odbieranie zmian ze źródła i odtwarzanie ich w lokalnym magazynie danych. Tryb read-only odnosi się przede wszystkim do pierwszego obszaru: użytkownik odczytu może pobierać dane, ale nie może tworzyć niezależnych zmian konkurujących z procesem replikacji.

Blokada zapisu nie gwarantuje, że odczyt zawsze zwróci dokładnie ten sam stan co instancja podstawowa. Replikacja może działać synchronicznie albo asynchronicznie, a w drugim przypadku występuje opóźnienie replikacji. Oznacza ono, że transakcja zatwierdzona na źródle może przez pewien czas nie być widoczna na replice. Aplikacja powinna więc kierować odczyty wymagające najnowszych danych do właściwego źródła lub korzystać z mechanizmu śledzenia pozycji replikacji, jeśli używany silnik go udostępnia.

Ograniczenia, błędy routingu i spójność danych

Najczęstszym błędem projektowym jest kierowanie wszystkich zapytań do repliki bez rozróżnienia ich znaczenia. Odczyt listy produktów, raportu albo historii operacji może tolerować niewielkie opóźnienie, ale sprawdzenie właśnie utworzonego konta, potwierdzenie płatności lub odczyt wyniku bezpośrednio po zapisie wymaga świadomego wyboru źródła. Jeżeli aplikacja zapisuje dane na instancji podstawowej, a chwilę później odczytuje je z asynchronicznej repliki, może otrzymać starszy wynik mimo poprawnego działania obu serwerów.

Tryb read-only nie rozwiązuje problemów z uszkodzoną replikacją, przerwanym przesyłaniem zmian ani błędną konfiguracją uprawnień. Należy oddzielnie kontrolować stan kanału lub procesu replikacyjnego, opóźnienie względem źródła, liczbę nieprzetworzonych zmian oraz ewentualne błędy odtwarzania. Warto również sprawdzić, czy konto używane przez aplikację nie ma uprawnień administracyjnych pozwalających obejść założony model pracy. Dokładne nazwy statusów, widoków monitorujących i parametrów zależą od konkretnego silnika bazy danych.

Znaczenie ustawienia dla diagnostyki infrastruktury bazodanowej

Podczas diagnostyki należy najpierw ustalić topologię: która instancja jest źródłem, które repliki są przeznaczone do odczytu oraz w jaki sposób aplikacja wybiera miejsce wykonania zapytania. Następnie sprawdza się, czy operacje zapisu są odrzucane na replice zgodnie z założeniem, czy proces odbierania zmian nadal działa i czy dane osiągają oczekiwany poziom aktualności. Sam fakt, że zapytanie SELECT zwraca wynik, nie potwierdza poprawności replikacji ani zgodności danych ze źródłem.

W przypadku problemów warto porównać kontrolowane rekordy na źródle i replice, uwzględniając czas zatwierdzenia transakcji oraz zmierzone opóźnienie. Trzeba też przeanalizować logi aplikacji pod kątem przypadkowych prób zapisu, błędów połączeń i zmian routingu po awarii. Jeżeli replika zostaje czasowo promowana do roli podstawowej, należy zweryfikować, czy procedura promocji zmienia jej tryb pracy, uprawnienia i sposób przyjmowania zapisów. Po zakończeniu testów konfiguracja powinna zostać sprawdzona ponownie, aby instancja przeznaczona wyłącznie do odczytu nie pozostała w niezamierzonym stanie.