Load balancing dla replik

Load balancing dla replik to rozdzielanie zapytań odczytu między repliki drugorzędne grupy dostępności.

Rola replik drugorzędnych w grupie dostępności

Load balancing dla replik w SQL Server Always On Availability Groups polega na kierowaniu wybranych żądań odczytu do replik drugorzędnych, które mają włączoną możliwość obsługi połączeń odczytujących. Replika podstawowa nadal przyjmuje operacje zapisu i koordynuje replikację dziennika transakcji, natomiast repliki drugorzędne mogą udostępniać dane aplikacjom wykonującym zapytania tylko do odczytu. Dzięki temu odczyty nie muszą w całości obciążać instancji podstawowej.

Mechanizm nie dzieli dowolnych zapytań automatycznie pomiędzy wszystkie serwery. SQL Server wykorzystuje właściwość intencji aplikacji w połączeniu, konfigurację routingu odczytu oraz stan poszczególnych replik. Replika musi być skonfigurowana jako czytelna, a połączenie klienta powinno deklarować zamiar wykonywania odczytów, na przykład przez parametr ApplicationIntent=ReadOnly. Zwykłe połączenie bez takiej deklaracji nie jest traktowane jako żądanie kierowane do routingu odczytu.

Routing odczytu przez listener grupy Always On

Klient powinien łączyć się z nazwą sieciową listenera grupy dostępności, a nie bezpośrednio z nazwą konkretnej repliki drugorzędnej. Listener przekazuje połączenie do instancji podstawowej albo, dla połączenia z intencją odczytu, do repliki wskazanej przez konfigurację read-only routing. Na każdej odpowiedniej replice konfiguruje się adres read-only routing URL, który określa punkt końcowy dostępny dla takich połączeń. Na replice podstawowej ustawia się następnie listę replik przeznaczonych do obsługi odczytów.

Lista routingu ma znaczenie zarówno dla dostępności, jak i dla rozłożenia obciążenia. Jeżeli wskazano kilka czytelnych replik drugorzędnych, SQL Server może kierować kolejne połączenia odczytujące do różnych członków tej listy zgodnie z mechanizmem obsługiwanym przez daną wersję silnika. Nie oznacza to dzielenia jednego zapytania na fragmenty wykonywane jednocześnie na kilku serwerach. Rozdzielane są połączenia lub żądania zgodnie z działaniem puli połączeń i konfiguracją klienta, a pojedyncze zapytanie jest wykonywane przez jedną wybraną instancję.

Warunki poprawnego rozdzielania zapytań

Load balancing działa prawidłowo tylko wtedy, gdy repliki mają odpowiedni stan synchronizacji i dopuszczają połączenia odczytujące. W grupie dostępności można używać replik synchronicznych oraz asynchronicznych. Replika asynchroniczna może mieć opóźniony dziennik transakcji, dlatego odczyt wykonany po przekierowaniu nie musi jeszcze zawierać najnowszych zmian zatwierdzonych na replice podstawowej. Jest to istotne przy raportach, wyszukiwaniu danych oraz procesach, które wymagają natychmiastowej spójności odczytu po zapisie.

Read-only routing nie zmienia uprawnień użytkownika i nie pozwala wykonywać operacji modyfikujących na replice skonfigurowanej wyłącznie do odczytu. Zapytania zawierające INSERT, UPDATE, DELETE lub polecenia zmieniające schemat nie stają się odczytami tylko dlatego, że połączenie ma ustawione ApplicationIntent=ReadOnly. Aplikacja powinna rozdzielać ścieżkę obsługującą zapis od ścieżki raportowej i prawidłowo reagować na błędy połączenia, zmianę roli repliki, brak dostępnej repliki czy przerwę w działaniu listenera.

Rzeczywisty efekt równoważenia zależy także od sposobu używania puli połączeń. Jeśli aplikacja długo utrzymuje niewielką liczbę połączeń, rozkład obciążenia może być nierówny mimo poprawnej konfiguracji listy routingu. W ocenie działania należy sprawdzić, do których instancji trafiają sesje, jaki jest czas odpowiedzi, ile zapytań wykonuje każda replika oraz czy opóźnienie replikacji nie powoduje odczytu nieaktualnych danych. Sam fakt, że połączenie zostało zaakceptowane przez listener, nie potwierdza jeszcze równomiernego wykorzystania wszystkich replik.

Diagnostyka konfiguracji i obciążenia replik

Diagnostykę zaczyna się od potwierdzenia ról replik w grupie dostępności, ich stanu synchronizacji oraz ustawienia opcji dopuszczających połączenia odczytujące. Następnie sprawdza się read-only routing URL na każdej replice i listę routingu zdefiniowaną dla repliki podstawowej. Należy również zweryfikować, czy klient rzeczywiście korzysta z listenera oraz przekazuje parametr ApplicationIntent=ReadOnly. Bez tego połączenie może zostać obsłużone przez podstawową instancję, nawet jeśli w grupie istnieją wolne repliki drugorzędne.

W środowisku produkcyjnym warto porównywać obciążenie procesora, pamięci, operacji wejścia-wyjścia i czasów trwania zapytań na każdej replice. Równocześnie trzeba kontrolować opóźnienie transportu i odtwarzania dziennika transakcji, ponieważ przeciążona replika może odpowiadać wolniej albo prezentować starszy stan danych. Jeśli routing nie daje oczekiwanego rezultatu, przyczyną może być nieczytelna replika, błędny adres endpointu, niedostępny port, niewłaściwa lista routingu, brak intencji odczytu w połączeniu lub utrzymywanie sesji przez pulę połączeń.

W przypadku problemów z laptopem lub komputerem używanym jako stanowisko klienckie sprawdza się przede wszystkim poprawność sterownika, parametrów połączenia, rozwiązywania nazwy listenera i dostępu sieciowego do skonfigurowanych adresów. Błąd po stronie aplikacji klienckiej może wyglądać jak nieskuteczny load balancing, chociaż sam mechanizm grupy dostępności działa poprawnie. Rozdzielenie tych obszarów pozwala ustalić, czy problem znajduje się w konfiguracji SQL Server, infrastrukturze sieciowej, bibliotece klienckiej czy w logice zarządzania połączeniami.