Wykorzystanie MariaDB MaxScale jako proxy bazy danych

Skonfigurowanie MaxScale jako warstwy proxy

MariaDB MaxScale stanowi niezależną warstwę proxy pomiędzy aplikacją a serwerami MariaDB. Aby zapewnić niezawodne działanie, konfiguracja, dostępne funkcje i znane ograniczenia muszą zawsze odpowiadać faktycznie zainstalowanej wersji. Seria MaxScale 25.10 jest opisana w oficjalnej dokumentacji wraz z własnymi informacjami o wydaniu.

Aplikacja łączy się z modułem nasłuchującym MaxScale, a nie bezpośrednio z serwerem bazy danych. Usługa skupia w sobie logikę dostępu, router określa backend, a filtry mogą dodatkowo przetwarzać zapytania przed ich przekazaniem. Dane pozostają na backendach MariaDB; MaxScale sam w sobie nie staje się bazą danych.

Takie rozdzielenie jest szczególnie przydatne, gdy aplikacja nie powinna sama wiedzieć, który serwer pełni aktualnie daną rolę. Podstawowe informacje na temat modelu danych, języka SQL oraz działania bazy danych można znaleźć w artykule MariaDB jako baza danych typu open source odpowiednie uzupełnienie. Serwer proxy uzupełnia architekturę serwerową, ale nie zastępuje ani uprawnień do bazy danych, ani koncepcji replikacji i postępowania w przypadku awarii.

Na stronie Trasowanie połączeń Podczas nawiązywania sesji MaxScale wybiera cel; ten backend pozostaje odpowiedzialny za daną sesję. W przypadku routingu instrukcji router może różnie przyporządkowywać poszczególne instrukcje SQL na podstawie ich treści. Wybór odpowiedniego wariantu zależy zatem od transakcji, stanu sesji oraz zdolności aplikacji do samodzielnego, wyraźnego rozdzielenia ścieżek odczytu i zapisu.

A Proxy bazy danych nie stanowi ogólnej gwarancji wydajności. Może on scentralizować routing, oddzielić zmiany ról aplikacji lub rozdzielić odpowiednie zapytania odczytowe. Jednak dodatkowe węzły sieciowe, analiza SQL oraz konkretna topologia zaplecza mają wpływ na jego działanie. Dlatego też odporność na obciążenia i przepustowość należy sprawdzić w oparciu o własną wersję, konfigurację i obciążenie.

Prawidłowe monitorowanie topologii „primary-replica”

Typowa architektura docelowa składa się z serwera głównego (primary) obsługującego zapisy oraz jednej lub kilku replik (replic) obsługujących odczyty. MaxScale jest jedynym punktem końcowym aplikacji dla bazy danych, na przykład za stałą nazwą DNS. W związku z tym aplikacja nie łączy się bezpośrednio z poszczególnymi hostami; wybór dostępnego i odpowiedniego serwera zaplecza odbywa się w warstwie proxy.

W przypadku topologii „primary-replica” monitor określa mariadbmon stan elementów zaplecza i rozpoznaje ich role jako „Primary” lub „Replica”. Routery mogą wykorzystywać te informacje do wyboru miejsca docelowego. Monitor musi zatem mieć wgląd w rzeczywistą topologię replikacji; błędne przypisania, dane niepoddane replikacji lub niejasne role nie stanowią problemów związanych z routingiem, lecz ryzyko operacyjne.

Rozróżnienie roli należy oddzielić od jej zmiany. Przy odpowiedniej konfiguracji i uprawnieniach mariadbmon może zarządzać przełączeniem awaryjnym, planowanym przełączeniem oraz ponownym dołączeniem. Przełączenie to celowo przygotowana zmiana roli w celu przeprowadzenia konserwacji lub obsługi; przełączenie awaryjne jest reakcją na błąd. Oba procesy wymagają jednoznacznej topologii, monitorowania, systemu alarmowego oraz udokumentowanego procesu postępowania w przypadku incydentów lub powrotu do normalnego trybu pracy.

W przypadku zadań związanych wyłącznie z monitorowaniem konto monitorujące powinno działać zgodnie z zasadą Najmniejszy przywilej otrzymują wyłącznie niezbędne uprawnienia. W aktualnej dokumentacji funkcja ta nosi nazwę REPLICA MONITOR. Dodatkowe uprawnienia są wymagane w zależności od aktywowanych funkcji, na przykład uprawnienie FILE w przypadku sprawdzania miejsca na dysku lub inne, ściśle określone uprawnienia do skanowania topologii i operacji na klastrach. Ogólne uprawnienia pełne nie stanowią w tym przypadku zamiennika.

Przed wdrożeniem automatyzacji zespół powinien określić, kto zatwierdza zmianę roli, w jaki sposób sprawdzany jest stan replik oraz w jaki sposób aplikacje są informowane o awariach. MaxScale może dostosowywać cele routingu na podstawie rozpoznanych ról. Jednak to koncepcja wysokiej dostępności, wraz z jej ograniczeniami dotyczącymi danych, czasu i zakresu odpowiedzialności, decyduje o tym, czy przełączenie jest dopuszczalne z technicznego punktu widzenia.

Zrozumienie routingu SQL i granic spójności

Router readwritesplit przekazuje instrukcje SQL zapisu do serwera głównego i rozdziela odpowiednie zapytania odczytu między repliki. Dzięki temu klaster serwerów głównych i replik może bardziej efektywnie wykorzystywać swoją przepustowość odczytu, bez konieczności samodzielnego przypisywania każdego zapytania do konkretnego serwera przez aplikację. Podstawą doboru jest informacja o rolach zawarta w monitorze.

W standardzie taki podział nie gwarantuje, że operacja odczytu wykryje nowy stan bezpośrednio po każdej operacji zapisu. causal_reads domyślnie jest ustawione na none. Jeśli na przykład aplikacja zapisuje status zamówienia, a następnie odczytuje go za pomocą niezależnego zapytania, replika może w związku z tym nadal zwracać poprzedni stan. Świadomie wybrana ścieżka odczytu typu „primary” lub wspólny kontekst transakcyjny to możliwe strategie, ale nie jedyne.

Dla Odczytuj swoje zapisy Gdy funkcja readwritesplit jest włączona wraz z opcją Causal Reads, może uwzględniać wcześniejsze operacje zapisu pomimo opóźnienia replikacji. Tryb local zapewnia widoczność dla tego samego połączenia. global przekazuje wartość GTID zapisaną przez usługę do wszystkich swoich połączeń; globalna kolejność „happens-before” operacji odczytu jest przy tym gwarantowana tylko wtedy, gdy wszystkie transakcje znajdują się w obrębie jednej domeny GTID. universal uwzględnia stan transakcji klastra obserwowany na serwerze głównym. Szersze obszary obowiązywania powodują jednak wzrost nakładu związanego z synchronizacją, a tym samym potencjalnie zwiększają opóźnienia.

Odczyty przyczynowe wykorzystują informacje GTID i w trybach nieszybkich czekają na replikację. Jeśli synchronizacja trwa dłużej niż causal_reads_timeout – domyślnie 10 sekund – funkcja readwritesplit próbuje wykonać zapytanie na serwerze głównym. W transakcji z ochroną przed zapisem limit czasu może zamiast tego zostać zwrócony jako błąd, ponieważ zapytanie nie może zostać przeniesione na serwer główny.

Tryby szybkie fast, fast_global oraz fast_universal nie czekają na replikę i w razie potrzeby korzystają z serwera głównego; limit czasu nie ma tam zastosowania. Dlatego nadają się przede wszystkim do obciążeń polegających głównie na odczycie, z niewielką liczbą operacji zapisu. Od wersji MaxScale 24.02 MaxScale samodzielnie konfiguruje niezbędne śledzenie nowych połączeń z serwerami zaplecza; starsze wersje wymagają do tego last_gtid w session_track_system_variables we wszystkich systemach backendowych.

W ramach otwartej transakcji typu „read-write” funkcja readwritesplit kieruje operacje odczytu do serwera głównego. Zapobiega to wykonywaniu instrukcji tej samej transakcji na serwerach zaplecza o różnym stanie replikacji. Ta konserwatywna zasada nie zwalnia z obowiązku prawidłowego ustalania granic transakcji pod kątem merytorycznym oraz traktowania opóźnienia replikacji jako odrębnego ograniczenia architektonicznego.

Również w przypadku procedur przechowywanych, wywołań funkcji UDF i instrukcji wielokrotnych decyzja jest celowo bardziej ostrożna: w udokumentowanych przypadkach takie zapytania są kierowane do serwera głównego. Powodem jest to, że ich skutków lub kontekstu nie należy traktować tak samo jak w przypadku zwykłego zapytania odczytowego. Routing SQL nie polega zatem wyłącznie na wyszukiwaniu słowa SELECT, lecz opiera się na zasadach zapewniających bezpieczne zarządzanie sesjami i semantyką.

Wartość graniczna ustalona na podstawie wiedzy fachowej dla Replica-Lag może wykluczyć repliki wynikające z określonych decyzji dotyczących odczytu, ale nie zastępuje wymogu spójności. Dopuszczalne opóźnienie zależy między innymi od tego, czy przestarzały wpis w katalogu jest dopuszczalny, czy też właśnie potwierdzony status płatności musi być bezwzględnie widoczny. Decyzja ta należy do logiki aplikacji i umowy operacyjnej, a nie do ogólnych ustawień domyślnych serwera proxy.

Bezpieczna konfiguracja funkcji Readwritesplit

Konfiguracja typu „read/write split” składa się z oddzielnych definicji obiektów dla backendów, monitora, usługi i modułu nasłuchującego. Poniższy fragment przedstawia strukturę pliku, a nie szablon gotowy do bezpośredniego wdrożenia w środowisku produkcyjnym. Wartości w nawiasach ostrych nie są w żadnym wypadku hasłami, lecz odniesieniami do kont i sekretów, które należy udostępnić za pośrednictwem systemu zarządzania sekretami w środowisku operacyjnym. Monitor i usługa wymagają przy tym własnych danych dostępowych do realizacji swoich różnych zadań.

[db-primary]
type=server
address=db-primary.example.invalid
port=3306

[db-replica-1]
type=server
address=db-replica-1.example.invalid
port=3306

[db-replica-2]
type=server
address=db-replica-2.example.invalid
port=3306

[cluster-monitor]
type=monitor
module=mariadbmon
servers=db-primary,db-replica-1,db-replica-2
user=<monitor-account-from-secret-management>
password=<monitor-secret-reference>

[RW-Service]
type=service
router=readwritesplit
servers=db-primary,db-replica-1,db-replica-2
user=<service-account-from-secret-management>
password=<service-secret-reference>

[RW-Listener]
type=listener
service=RW-Service
protocol=MariaDBClient
port=3306

Obiekty serwerowe oznaczają jedynie dostępne serwery zaplecza MariaDB; monitor określa na podstawie topologii, która instancja jest instancją główną (Primary), a która repliką (Replica). Konto monitora służy do sprawdzania statusu i ról. Oddzielne konto serwisowe służy do pobierania z backendów informacji o użytkownikach i uprawnieniach niezbędnych do uwierzytelniania i autoryzacji klientów. Oba konta wymagają jedynie uprawnień udokumentowanych dla ich odpowiednich zadań. Rozpoznawanie rolek a ładowanie informacji o użytkowniku to odrębne zadania.

Symbole zastępcze w przykładzie muszą zostać zastąpione podczas wdrażania za pomocą zabezpieczonej ścieżki wdrożeniowej; nie są one przeznaczone do stosowania jako dosłowne wartości konfiguracyjne. Hasła w postaci zwykłego tekstu, rzeczywiste ścieżki do certyfikatów ani niesprawdzone pakiety uprawnień nie powinny znajdować się w plikach lub repozytoriach dostępnych do swobodnego odczytu. W przypadku połączeń protokołu MariaDB MaxScale wewnętrznie zarządza odpowiednimi kontami użytkowników i uprawnieniami na podstawie tabel systemowych. W przypadku zmiany kont lub uprawnień nieaktualne informacje mogą utrudniać logowanie lub autoryzację.

Przed uruchomieniem należy zatem oddzielnie sprawdzić port słuchacza, ścieżki sieciowe, synchronizację użytkowników oraz faktyczne przypisanie routerów. Również automatyczne interwencje monitora nie są domyślnie uwzględnione w tej minimalnej konfiguracji: funkcje przełączania awaryjnego (failover), przełączania (switchover) lub ponownego dołączania (rejoin) wymagają dodatkowej konfiguracji oraz przetestowanej koncepcji działania. Pozornie prosta konfiguracja nie zastępuje ani zarządzania sekretami, ani weryfikacji topologii zaplecza.

Porównaj modele routerów według zastosowania

Wybór routera zależy od zachowania aplikacji, a nie wyłącznie od liczby dostępnych replik. Połączenia bezpośrednie upraszczają konfigurację, pozostawiając jednak zmianę celu i rozpoznawanie ról aplikacji. Dwa oddzielne punkty końcowe z readconnroute są odpowiednie, gdy aplikacja sama świadomie zarządza połączeniami do odczytu i zapisu. Routing oparty na oświadczeniach Użycie opcji `readwritesplit` ma sens, gdy sesja ma być kierowana – w zależności od zapytania SQL – do serwera głównego lub do replik.

Funkcja readconnroute ocenia serwer docelowy podczas nawiązywania połączenia i nie analizuje każdego kolejnego polecenia SQL. W przypadku awarii wybranego serwera sesja zostaje zakończona; router nie łączy użytkownika automatycznie z innym serwerem. Jest to często uzasadnione w przypadku wyraźnie oddzielonych, krótkotrwałych połączeń odczytowych, ale może być nieodpowiednie dla procesów aplikacyjnych wymagających śledzenia stanu.

Szczególną ostrożność należy zachować w przypadku usługi przeznaczonej jako punkt końcowy odczytu z router_options=slave. Opcja ta preferuje serwery pełniące rolę repliki; jeśli jednak wszystkie repliki ulegną awarii, a serwer główny jest dostępny, readconnroute może przełączyć się na serwer główny. Ponadto opcja ta nie zapewnia ochrony przed zapisem. Aplikacja musi wysyłać wyłącznie zapytania SQL typu „read-only” lub też dodatkowy filtr „ReadOnly” musi blokować dostęp do zapisu. Cel routingu i preferencja roli nie stanowią zatem ani ograniczenia uprawnień, ani substytutu restrykcyjnych uprawnień do bazy danych.

Z kolei model readwritesplit ogranicza liczbę decyzji dotyczących wyboru docelowego serwera w kodzie aplikacji, wymaga jednak dokładnej analizy semantyki. Odpowiednie operacje odczytu mogą być rozdzielane między repliki, podczas gdy operacje zapisu trafiają do serwera głównego. W przypadku procesów o rygorystycznych wymaganiach dotyczących aktualności kluczowe znaczenie ma to, czy zapytanie po operacji zapisu może czekać na dane z replik, czy też musi świadomie korzystać z serwera głównego.

Planowanie sesji, pozycjonowania i zmiany ustawień

Sesja bazy danych obejmuje więcej niż tylko pojedyncze zapytanie. SET, USE, CHANGE USER a operacje typu „prepared statement” zmieniają swój kontekst. Funkcja `readwritesplit` replikuje odpowiednie polecenia sesji na potencjalne serwery docelowe, aby później można było wykonać przekierowane instrukcje z odpowiednim stanem sesji. To odróżnia router od prostego równoważenia obciążenia TCP, nie eliminuje jednak wszystkich ograniczeń związanych ze szczególnymi przypadkami.

W przypadku przygotowanych instrukcji dotyczących tabel tymczasowych ograniczenie to ma szczególne znaczenie. Jeśli taka instrukcja zostanie przygotowana na serwerze głównym, repliki niekoniecznie będą w stanie ją wykonać. Aplikacja powinna zatem przetestować obiekty tymczasowe, przygotowane instrukcje oraz przebieg transakcji z wykorzystaniem przewidzianego modelu routingu. Stan sesji nie jest warunkiem dodatkowym, lecz decyduje o tym, czy podział SQL jest odpowiedni pod względem merytorycznym i technicznym.

W przypadku aplikacji intensywnie wykorzystującej odczyt zespół może zdefiniować ustaloną przez ekspertów wartość graniczną opóźnienia jako kryterium wykluczenia replik. Tylko max_replication_lag nie gwarantuje jednak, że poprzedni zapis na replice jest już widoczny. W przypadku krytycznych kolejnych odczytów, w zależności od przebiegu operacji, można rozważyć świadome wykorzystanie ścieżki głównej, wspólny kontekst zapisu lub aktywowane odczyty przyczynowe.

W przypadku odczytów przyczynowych należy świadomie wybrać zakres zastosowania. local zachowuje związek przyczynowo-skutkowy w ramach danego połączenia. global wykorzystuje wartość GTID przechowywaną w całej usłudze, ale gwarantuje globalną kolejność „happens-before” operacji odczytu tylko wtedy, gdy wszystkie transakcje znajdują się w jednej domenie GTID. universal uwzględnia stan transakcji klastra obserwowany na serwerze głównym. Tryby inne niż szybkie synchronizują się za pomocą identyfikatorów GTID; jeśli replika nie nadrobi zaległości w ciągu skonfigurowanego limitu czasu, zapytanie jest zasadniczo powtarzane na serwerze głównym, o ile pozwala na to tryb transakcji.

Funkcję tę należy klasyfikować w zależności od wersji. Od wersji MaxScale 24.02 MaxScale uzupełnia last_gtid dla nowych połączeń z backendem; w starszych wersjach trzeba było session_track_system_variables muszą być odpowiednio ustawione w serwerach MariaDB. Tryby szybkie pozwalają uniknąć oczekiwania, ale w przypadku replik, które jeszcze nie nadrobiły zaległości, mogą kierować operacje odczytu do serwera głównego, dlatego nie nadają się one ogólnie do obciążeń wymagających intensywnego zapisu.

Planowane przełączenie i automatyczne przełączenie awaryjne należy również traktować oddzielnie. W przypadku przełączenia planowanego zmiana ról jest przygotowywana w sposób kontrolowany, natomiast w przypadku przełączenia awaryjnego system reaguje na stan awarii. mariadbmon może monitorować role i stany zaplecza oraz, o ile zostanie odpowiednio skonfigurowany, wspierać te procesy. Warunkiem koniecznym pozostają przy tym zreplikowany stan danych, jednoznaczna topologia, system alarmowy oraz proces obsługi incydentów.

W programie MaxScale 25.10 można discover-replicas Wykrywanie serwerów, które replikują dane bezpośrednio na bieżącym serwerze głównym, oraz dodawanie ich do Monitor i MaxScale. Ta funkcja nie jest zgodna z synchronizacją konfiguracji. Przed jej wdrożeniem zespół musi zatem określić, czy zmiany topologii mają być wykrywane automatycznie, czy też kontrolowane za pomocą zsynchronizowanej konfiguracji; jednoczesne stosowanie obu tych metod nie jest w tym kontekście dopuszczalne.

TLS, zabezpieczanie uprawnień i filtrów

W przypadku MaxScale protokół TLS należy zaplanować na dwóch oddzielnych ścieżkach: od aplikacji do nasłuchującego serwera oraz od serwera proxy do serwerów MariaDB działających w tle. Oba połączenia wymagają własnych ustawień dotyczących szyfrowania i weryfikacji certyfikatów; zabezpieczona ścieżka kliencka nie szyfruje automatycznie ruchu w dalszej części sieci. Konfiguracja musi zatem odzwierciedlać wymagania dotyczące bezpieczeństwa oraz łańcuch zaufania dla obu odcinków.

Włączono TLS ssl=true szyfrowanie w danej konfiguracji modułu nasłuchującego lub serwera. Jeśli klient oczekuje certyfikatu serwera, moduł nasłuchujący wymaga certyfikatu i klucza prywatnego. Konto z REQUIRE SSL Nie można zalogować się przez słuchacz bez TLS. Pliki certyfikatów i klucze powinny znajdować się w zabezpieczonym środowisku operacyjnym, a nie w ogólnodostępnych przykładowych konfiguracjach lub konfiguracjach w repozytorium.

Również Koncepcja praw W przypadku backendów kluczowe znaczenie ma to, że MaxScale pośredniczy w nawiązywaniu połączeń, ale nie zastępuje konkretnych kont bazodanowych. Konta serwisowe otrzymują wyłącznie uprawnienia niezbędne do wykonywania powierzonych im zadań. W zakresie logowania i autoryzacji MaxScale opiera się na kontach użytkowników i uprawnieniach z tabel systemowych MariaDB; zmiany dotyczące tych kont muszą zatem być niezwłocznie dostępne w wewnętrznym systemie zarządzania użytkownikami.

Filtr zapory sieciowej może sprawdzać zapytania SQL przed ich przekazaniem na podstawie wyuczonych lub zdefiniowanych reguł. Dysponuje trybami bezczynności, uczenia się, monitorowania i wymuszania; w trybie wymuszania niedozwolone wzorce instrukcji są, w zależności od ustawień, traktowane jako błąd lub powodują rozłączenie połączenia. Faza uczenia się musi obejmować reprezentatywne, dozwolone przebiegi aplikacji, aby filtr nie blokował prawidłowych zapytań.

Filtr stanowi dodatkową warstwę kontroli pod kątem oczekiwanych wzorców SQL, a nie zastępuje uprawnień. Nadal konieczne są restrykcyjne uprawnienia do bazy danych, zabezpieczone dane dostępowe oraz sprawdzony kod aplikacji, ponieważ filtr ocenia jedynie zapytania przychodzące do niego na podstawie swoich reguł. Informacje dotyczące innych filtrów należy weryfikować oddzielnie na podstawie ich odpowiedniej dokumentacji.

Systematyczne sprawdzanie konfiguracji i błędów

W przypadku błędów połączeń lub routingu pomocna jest ustalona kolejność sprawdzania, a nie wprowadzanie zmian na oślep. Najpierw sprawdź stan monitora: czy wszystkie serwery zaplecza są dostępne i czy role serwerów głównych oraz replik są rozpoznawane zgodnie z oczekiwaniami? Dopiero wtedy można sensownie ocenić decyzje routera. Nieprawidłowo rozpoznany lub niedostępny węzeł nie jest wyłącznie problemem modułu nasłuchującego.

Następnie należy sprawdzić moduł nasłuchujący i TLS: port, protokół, certyfikat, klucz oraz wymagania dotyczące używanych kont muszą być ze sobą zgodne. Następnie sprawdź, czy system zarządzania kontami użytkowników rozpoznaje aktualne konta backendowe i uprawnienia. Zwłaszcza po wprowadzeniu zmian dotyczących użytkowników lub uprawnień nieaktualne dane kont mogą uniemożliwić logowanie, mimo że konto w samej bazie MariaDB jest poprawnie skonfigurowane.

Następnie przypisz usługę, router i przewidziane serwery. W przypadku podziału odczytu i zapisu należy również uwzględnić opóźnienie replikacji, causal_reads oraz limity transakcji aplikacji do listy kontrolnej. Bez włączonej funkcji „Causal Reads” odczyt poza wymaganym kontekstem zapisu na replice może dostarczyć starszy stan; sam limit opóźnienia nie gwarantuje widoczności poprzedniego zapisu.

Dodatkowo umieść jedną Źródło konfiguracji na stałe. MaxScale może zapisywać zmiany w czasie wykonywania; po ponownym uruchomieniu zapisana konfiguracja może zastąpić pliki statyczne. Jeśli zespół częściowo edytuje pliki, a częściowo maxctrl W przypadku jej zastosowania należy obowiązkowo udokumentować przebieg zmian, proces weryfikacji oraz zabezpieczenie tej konfiguracji środowiska uruchomieniowego.

Okno serwisowe na zmiany schematu należy traktować jako odrębny obszar operacyjny: zależności, zachowanie blokad i replikację należy sprawdzić z wyprzedzeniem; nie należy tego przypisywać serwerowi proxy. Jeśli chodzi o planowanie kontrolowanych zmian w dużych tabelach MariaDB, artykuł na temat Zmiany schematów bez przestojów dodatkowy kontekst. MaxScale może następnie ponownie sterować połączeniami i routingiem na podstawie ról backendu, ale nie realizuje strategii DDL bazy danych.

Ostrzeżenie: Zmiany dotyczące ról, certyfikatów, uprawnień użytkowników i routingu należy najpierw przetestować w podobnym środowisku. W przypadku ingerencji w środowisku produkcyjnym należy uwzględnić procedurę przywracania stanu poprzedniego, monitorowanie błędów aplikacji oraz jasny podział obowiązków. Dzięki temu można rozróżnić, czy awaria wynika z konfiguracji serwera proxy, zaplecza czy zachowania klienta.

Właściwe wykorzystanie MaxScale lub rezygnacja z niego

W przypadku pojedynczego serwera MariaDB, bez wymagań dotyczących routingu, przełączania czy filtrów SQL, połączenia bezpośrednie są zazwyczaj prostszym rozwiązaniem. Aplikacja musi wówczas jednak sama zająć się ewentualną zmianą docelowego serwera w późniejszym czasie. Warto skorzystać z MaxScale, jeśli dodatkowy punkt końcowy pełni konkretną funkcję, na przykład przejmowanie zmian ról, filtrowanie dostępu lub kontrolowane rozdzielanie odczytów między replikami.

Jeśli aplikacja może samodzielnie wybierać ścieżki odczytu i zapisu, oddzielne punkty końcowe z readconnroute często zrozumiałe. Ten router wybiera serwer zaplecza podczas nawiązywania połączenia, nie analizuje jednak każdego polecenia SQL i nie przenosi przerwanej sesji na inny serwer. W przypadku router_options=slave Preferowane są repliki; jeśli wszystkie repliki uległy awarii, a serwer główny jest nadal dostępny, router może korzystać z serwera głównego. Opcja ta nie powoduje ponadto, że punkt końcowy staje się chroniony przed zapisem. W tym celu konieczne jest zastosowanie odpowiedniego filtra „ReadOnly”, restrykcyjnych uprawnień backendu lub ściśle kontrolowanego kodu SQL aplikacji.

W przypadku obciążeń typu „primary-replica”, których ORM i model transakcyjny są do tego dostosowane, stosuje się readwritesplit aplikacja określa docelowy wybór SQL dla każdego polecenia. W ustawieniu domyślnym causal_reads=none opóźnienie replikacji pozostaje jednak widoczne. Po wykonaniu krytycznych operacji zapisu aplikacja może skorzystać ze ścieżki odczytu na serwerze głównym lub odpowiedniego wspólnego kontekstu transakcyjnego; alternatywnie można celowo skonfigurować odczyty przyczynowe tak, aby obejmowały wymagany zakres widoczności.

Causal Reads rozróżniają widoczność w ramach tej samej sesji, globalny stan GTID zarządzany przez usługę oraz stan klastra obserwowany na serwerze głównym. local dotyczy tego samego połączenia. W przypadku global Globalna kolejność operacji odczytu typu „happens-before” jest gwarantowana tylko wtedy, gdy wszystkie transakcje należą do jednej domeny GTID; tryb ten nie może zatem być ogólnie rozumiany jako nieograniczona gwarancja spójności w całym serwisie. universal Przed operacjami odczytu sprawdza aktualny stan na serwerze głównym. Tryby synchronizacji mogą powodować dodatkowe opóźnienia; szybkie warianty nie czekają, ale podczas operacji zapisu mogą w większym stopniu przenosić obciążenie na serwer główny.

Przed wdrożeniem przypadki graniczne wymagają przeprowadzenia ukierunkowanych testów z wykorzystaniem rzeczywistego modułu sterującego i modelu danych. Tabele tymczasowe i przygotowane na ich podstawie instrukcje mogą być niedostępne na replikach, jeśli przygotowanie odbywa się na serwerze głównym. Również procedury przechowywane, wywołania funkcji UDF, instrukcje wielokrotne oraz stan sesji mają wpływ na to, czy router kieruje połączenia w sposób konserwatywny do serwera głównego.

Funkcja Transaction Replay nie gwarantuje, że transakcje będą przebiegać bez strat. Jeśli połączenie zostanie przerwane podczas COMMIT można pominąć kwestię, czy operacja zatwierdzenia zakończyła się już powodzeniem. Ryzykowne konfiguracje odtwarzania mogą powodować podwójne wykonanie operacji zapisu; wyniki zależne od serwera, takie jak NOW() lub @@server_id mogą ponadto powodować rozbieżności w sumach kontrolnych. Dlatego też należy oceniać wdrożenie na podstawie wymagań dotyczących spójności, przebiegu błędów oraz powtarzalności operacji zapisu, a nie na podstawie ogólnych obietnic dotyczących wydajności.