Tryb read-intent

Tryb read-intent kieruje połączenie klienta do repliki tylko do odczytu, jeśli zadeklarowano taki zamiar.

Jak działa deklaracja read-intent w połączeniu z bazą danych

Tryb read-intent oznacza, że klient podczas zestawiania połączenia deklaruje zamiar wykonywania operacji odczytu. Taka deklaracja nie zmienia automatycznie treści zapytania i nie nadaje użytkownikowi dodatkowych uprawnień. Jest informacją przekazywaną do mechanizmu obsługującego grupę replik lub inną konfigurację wysokiej dostępności, aby mógł wybrać instancję przeznaczoną do obsługi odczytów.

Połączenie w tym trybie może zostać skierowane do repliki tylko wtedy, gdy środowisko bazodanowe ma skonfigurowane reguły routingu oraz co najmniej jedną replikę dopuszczoną do odczytu. Samo ustawienie właściwości read-intent nie tworzy repliki, nie uruchamia synchronizacji danych i nie przełącza istniejącego połączenia po zmianie stanu serwera. Jeżeli routing nie jest dostępny, klient może otrzymać połączenie z innym węzłem zgodnie z konfiguracją albo zakończyć próbę błędem.

Różnica między odczytem danych a zapisem do repliki

Deklaracja zamiaru odczytu nie jest równoważna wymuszeniu trybu tylko do odczytu na poziomie uprawnień. O tym, czy konkretna instrukcja może zostać wykonana, decydują reguły silnika bazy danych, stan repliki oraz prawa konta. Replika może przyjmować zapytania SELECT, ale odrzucać INSERT, UPDATE, DELETE, DDL lub inne operacje wymagające zapisu. W niektórych systemach zapytanie odczytowe może również wymagać dostępu do obiektów, które nie są dostępne na replice albo nie zostały jeszcze zsynchronizowane.

Program korzystający z read-intent powinien zakładać, że replika może mieć opóźnienie względem głównego węzła. Dane odczytane bezpośrednio po zapisie wykonanym na serwerze podstawowym nie muszą być natychmiast widoczne na replice. Z tego powodu odczyty kontrolne, które muszą potwierdzać świeżo wykonany zapis, powinny korzystać z właściwego węzła i mechanizmu spójności przewidzianego przez konkretny silnik. Read-intent służy do kierowania obciążenia odczytowego, a nie do zapewniania aktualności danych.

Wpływ routingu na aplikację, sesję i wydajność

Routing read-intent jest wykonywany w czasie ustanawiania sesji. Jeśli aplikacja używa puli połączeń, ważne jest, aby właściwość zamiaru odczytu była ustawiana przy tworzeniu odpowiedniego połączenia, a nie dopiero przed pojedynczym zapytaniem. Połączenie zwrócone z puli zachowuje parametry, z którymi zostało utworzone, dlatego mieszanie zapytań odczytowych i modyfikujących w jednej puli może prowadzić do nieoczekiwanego kierowania ruchu.

Przekierowanie zapytań na replikę może zmniejszyć obciążenie procesora, pamięci masowej i blokad na węźle podstawowym, ale nie gwarantuje krótszego czasu odpowiedzi. Na wynik wpływają między innymi opóźnienie sieciowe, aktualny stan synchronizacji, indeksy, plan wykonania oraz liczba równoległych sesji. Replika może odrzucić nowe połączenie, gdy nie spełnia warunków routingu, jest w trakcie odtwarzania lub została oznaczona jako niedostępna dla odczytów. Aplikacja powinna więc rejestrować docelowy węzeł, czas zestawienia sesji i błędy routingu, aby można było odróżnić problem z konfiguracją od zwykłego przeciążenia.

Tryb read-intent nie zastępuje limitów czasu, ponawiania połączeń ani obsługi awarii. Po utracie repliki klient może wymagać ponownego zestawienia sesji, a zachowanie zależy od sterownika, biblioteki dostępowej i konfiguracji grupy dostępności. Automatyczne ponowienie zapytania powinno uwzględniać jego charakter: ponawianie odczytu jest zwykle bezpieczniejsze niż bezwarunkowe ponawianie operacji zmieniającej dane.

Sprawdzenie konfiguracji i diagnostyka połączenia read-intent

Diagnostykę należy rozpocząć od ustalenia, gdzie faktycznie trafiła sesja. Przydatne są informacje diagnostyczne zwracane przez sterownik, identyfikator instancji, nazwa hosta oraz stan repliki widoczny w narzędziach administracyjnych danego silnika. Następnie trzeba porównać parametry połączenia używane przez aplikację z konfiguracją routingu: nazwą punktu dostępowego, listą replik dopuszczonych do odczytu, stanem synchronizacji i warunkami, przy których węzeł jest uznawany za dostępny.

Warto wykonać osobno prosty odczyt na połączeniu z zadeklarowanym read-intent oraz zapytanie wymagające zapisu. Pierwszy test powinien potwierdzić oczekiwany węzeł, a drugi pokazać, czy aplikacja prawidłowo rozdziela ścieżki odczytu i zapisu. Należy również sprawdzić zachowanie po wyłączeniu repliki, opóźnieniu synchronizacji i ponownym użyciu połączenia z puli. Takie testy ujawniają błędy niewidoczne podczas pojedynczego, ręcznie uruchomionego zapytania.

W przypadku laptopa lub komputera używanego jako stanowisko administracyjne problem z read-intent może wynikać nie z samego sprzętu, lecz z błędnego sterownika, starej biblioteki klienta, niepoprawnego parametru połączenia albo niedostępności sieci. Podczas serwisowej diagnostyki warto rozdzielić awarię systemu operacyjnego, sterownika sieciowego i aplikacji bazodanowej, a następnie odtworzyć połączenie z aktualnymi logami klienta oraz serwera. Pozwala to ustalić, czy sesja została skierowana do repliki, czy tylko zakończyła się lokalnym błędem komunikacji.