Load balancing read-only

Load balancing read-only to kierowanie zapytań tylko do odczytu na repliki pomocnicze, odciążające serwer podstawowy.

Ruch odczytowy kierowany do replik

Load balancing read-only oznacza rozdzielanie zapytań, które nie zmieniają danych, pomiędzy kilka instancji obsługujących kopie bazy lub innego źródła informacji. Serwer podstawowy, nazywany także primary albo writer, przyjmuje operacje zapisu, natomiast repliki pomocnicze, określane jako read replica lub reader, odpowiadają na zapytania odczytowe. Taki model pozwala wykorzystać zasoby kilku maszyn i ograniczyć liczbę odczytów wykonywanych bezpośrednio na serwerze podstawowym.

Mechanizm nie polega na przypadkowym przekazywaniu każdego żądania do dowolnego hosta. Warstwa równoważenia musi rozpoznać, które operacje są bezpieczne do wykonania na replice. Typowym przykładem jest zapytanie SQL SELECT, ale sama obecność słowa SELECT nie zawsze wystarcza do poprawnej klasyfikacji. Procedura składowana może wykonywać zapis mimo interfejsu odczytowego, a niektóre zapytania mogą wymagać bieżącego, spójnego obrazu danych. Reguły routingu powinny więc uwzględniać charakter całej transakcji oraz wymagania aplikacji.

Replikacja, opóźnienie i spójność wyników

Read-only load balancing jest zależny od sposobu replikacji danych. W replikacji synchronicznej potwierdzenie zapisu następuje dopiero po zapisaniu informacji także w określonych replikach, dzięki czemu różnica pomiędzy serwerem podstawowym a repliką może być niewielka. Replikacja asynchroniczna pozwala szybciej zakończyć zapis na serwerze podstawowym, lecz replika może przez pewien czas nie zawierać najnowszych zmian. To opóźnienie jest nazywane replication lag albo replay lag, zależnie od używanego systemu.

Opóźnienie tworzy problem określany jako read-after-write consistency. Użytkownik może zapisać dane, a następnie natychmiast wysłać zapytanie odczytowe, które trafi do repliki jeszcze niezsynchronizowanej. Wynik może wtedy wyglądać tak, jakby zapis się nie powiódł, chociaż został poprawnie wykonany na serwerze podstawowym. Aplikacje wymagające natychmiastowego potwierdzenia własnych zmian powinny przez określony czas kierować powiązane odczyty do primary albo używać mechanizmu śledzenia pozycji replikacji. Sam algorytm round-robin nie zapewnia spójności danych i nie zastępuje kontroli opóźnienia.

Algorytmy wyboru zdrowej repliki

Warstwa równoważenia może wybierać repliki według różnych kryteriów. Round-robin przekazuje kolejne żądania do kolejnych hostów, lecz zakłada podobną wydajność i dostępność wszystkich instancji. Weighted round-robin uwzględnia różnice w mocy obliczeniowej, pamięci lub przepustowości sieci. Wariant least connections wybiera host z najmniejszą liczbą aktywnych połączeń, co może lepiej reagować na nierównomierny czas wykonywania zapytań. W systemach bazodanowych często stosuje się także routing oparty na roli instancji, stanie replikacji i aktualnym opóźnieniu.

Każda replika powinna przechodzić test zdrowia, który sprawdza nie tylko dostępność portu TCP, ale również możliwość wykonania kontrolnego odczytu oraz aktualność danych. Host może odpowiadać na połączenia sieciowe, a mimo to być nieprzydatny jako reader, jeśli zatrzymał odtwarzanie dziennika zmian, osiągnął limit połączeń albo ma zbyt duże opóźnienie. Po przekroczeniu ustalonego progu replika powinna zostać czasowo wyłączona z puli. Po przywróceniu synchronizacji można ją ponownie dopuścić do ruchu, najlepiej stopniowo, aby uniknąć nagłego przeciążenia.

Granice zastosowania w środowisku komputerowym

Konfiguracja read-only load balancing wymaga sprawdzenia kilku warstw: topologii replikacji, sposobu nawiązywania połączeń, reguł rozpoznawania zapytań oraz zachowania aplikacji po błędzie odczytu. Należy ustalić, czy pula readerów jest wskazywana przez osobny adres DNS, usługę pośredniczącą, proxy bazodanowe czy funkcję wbudowaną w sterownik klienta. Trzeba także zweryfikować, czy połączenie jest utrzymywane przez długi czas, ponieważ decyzja o wyborze serwera może być podejmowana przy otwieraniu sesji, a nie dla każdego pojedynczego zapytania.

Podczas diagnostyki sprawdza się logi routingu, liczbę połączeń, czasy odpowiedzi, błędy timeout, status każdej repliki oraz różnicę pomiędzy pozycją zmian na serwerze podstawowym i pomocniczym. Szczególnej uwagi wymagają transakcje mieszane, w których odczyt i zapis są wykonywane w ramach jednej operacji biznesowej. Błędne przekierowanie zapytania może prowadzić do odczytu nieaktualnego stanu, a automatyczne ponowienie żądania na innym hoście może dodatkowo utrudnić ustalenie przyczyny. Prawidłowo zaprojektowany mechanizm rozdziela obciążenie, ale jednocześnie zachowuje świadome reguły spójności, monitorowania i obsługi awarii.