Brug af MariaDB MaxScale som database-proxy

Konfigurer MaxScale som proxylag

MariaDB MaxScale er et selvstændigt proxylag mellem applikationen og MariaDB-serverne. For at sikre en stabil drift skal konfigurationen, de tilgængelige funktioner og de kendte begrænsninger altid stemme overens med den faktisk installerede version. MaxScale 25.10-serien er beskrevet i den officielle dokumentation med egne release notes.

Applikationen opretter forbindelse til en MaxScale-listener i stedet for direkte til en databaseserver. En tjeneste samler adgangslogikken, en router bestemmer backendet, og filtre kan desuden behandle forespørgsler, inden de videresendes. Dataene forbliver på MariaDB-backendene; MaxScale fungerer ikke selv som en database.

Denne opdeling er især nyttig, når et program ikke selv skal vide, hvilken rolle den enkelte server aktuelt har. For grundlæggende oplysninger om datamodellen, SQL og driften af databasen henvises til artiklen MariaDB som open source-database et passende supplement. Proxyserveren supplerer serverarkitekturen, men erstatter hverken databaserettigheder eller et koncept for replikering og nedbrud.

På Forbindelsesrouting Når der oprettes en session, vælger MaxScale en destination; denne backend forbliver ansvarlig for sessionen. Ved statement-routing kan routeren fordele de enkelte SQL-sætninger forskelligt ud fra deres indhold. Hvilken variant der passer, afhænger derfor af transaktioner, sessionens tilstand og applikationens evne til selv at adskille læse- og skrivestier på en klar måde.

En Database-proxy er ikke et generelt løfte om ydeevne. Det kan centralisere routing, adskille rolleændringer i applikationer eller fordele relevante læseforespørgsler. Yderligere netværksknudepunkter, SQL-analyse og den konkrete backend-topologi påvirker dog adfærden. Robusthed og kapacitet skal derfor testes med den egne version, konfiguration og belastning.

Korrekt overvågning af primær-replika-topologien

En typisk målarkitektur består af en skrivende primærserver og en eller flere læsende replikaer. MaxScale er applikationens eneste database-endepunkt, f.eks. bag et fast DNS-navn. Applikationen opretter derfor ikke forbindelse direkte til de enkelte værter; udvælgelsen af et tilgængeligt og passende backend foregår inden for proxylaget.

For en primær-replika-topologi beregner monitoren mariadbmon backend-systemernes tilstand og identificerer deres roller som primær eller replika. Routere kan bruge disse oplysninger til at vælge destination. Monitoren skal derfor kunne se den faktiske replikeringstopologi; forkerte tildelinger, data, der ikke er replikeret, eller uklare roller er ikke routingproblemer, men driftsrisici.

Det er vigtigt at skelne mellem at genkende en rolle og at ændre den. Med den rette konfiguration og de rette rettigheder kan mariadbmon håndtere failover, planlagte switchover og rejoin. En switchover er et bevidst forberedt rollebytte med henblik på vedligeholdelse eller drift; en failover er en reaktion på en fejl. Begge processer kræver en entydig topologi, overvågning, alarmering og en dokumenteret hændelses- eller genopretningsproces.

Til rene overvågningsopgaver bør monitor-kontoen fungere efter princippet Mindste privilegium kun de nødvendige rettigheder. I den aktuelle dokumentation kaldes dette REPLICA MONITOR. Der kræves yderligere rettigheder afhængigt af de aktiverede funktioner, f.eks. FILE ved en kontrol af lagerpladsen eller andre specifikt kontrollerede rettigheder til topologiscanninger og clustermanipulationer. Generelle fuldrettigheder er ikke en erstatning herfor.

Inden automatiseringen iværksættes, bør teamet fastlægge, hvem der godkender et rollebytte, hvordan replikernes tilstand kontrolleres, og hvordan applikationerne informeres om forstyrrelser. MaxScale kan tilpasse routingmål på baggrund af de identificerede roller. Det er dog højtilgængelighedskonceptet med dets grænser for data, tid og ansvar, der afgør, om en omskiftning er fagligt tilladt.

Forståelse af SQL-routing og konsistensgrænser

Routeren readwritesplit videresender skrivende SQL-sætninger til primærserveren og fordeler relevante læseforespørgsler på replikerne. På den måde kan et primær-replik-netværk udnytte sin læsekapacitet mere målrettet, uden at applikationen selv skal tildele hver enkelt forespørgsel til en bestemt server. Monitorens rolleoplysninger danner grundlaget for udvælgelsen.

Denne opdeling garanterer ikke som standard, at en læseoperation ser den nye tilstand umiddelbart efter hver skriveoperation. causal_reads er som standard indstillet til none. Hvis et program f.eks. skriver en ordrestatus og derefter læser den via en uafhængig forespørgsel, kan en replika derfor stadig levere den tidligere status. En bevidst valgt primær læsevej eller en fælles transaktionskontekst er mulige strategier, men ikke de eneste.

For Læs-dine-skrivninger kan readwritesplit med aktiverede kausale læsninger tage højde for tidligere skrivninger på trods af replikaforsinkelse. Tilstanden local sikrer synligheden for den samme forbindelse. global fører den GTID-status, som tjenesten har gemt, på tværs af sine forbindelser; en global »happens-before«-rækkefølge for læsningerne er dog kun garanteret, hvis alle transaktioner ligger inden for et enkelt GTID-domæne. universal tager højde for den transaktionsstatus i klyngen, der kan observeres på Primary. De større anvendelsesområder øger dog synkroniseringsomkostningerne og dermed potentielt også latenstiden.

Kausale læsninger arbejder med GTID-oplysninger og venter på replikering i de ikke-hurtige tilstande. Hvis synkroniseringen varer længere end causal_reads_timeout – som standard 10 sekunder – forsøger readwritesplit at udføre forespørgslen på primærserveren. I en skrivebeskyttet transaktion kan der i stedet returneres en timeout som en fejl, fordi forespørgslen ikke må flyttes til primærserveren.

De hurtige tilstande fast, fast_global og fast_universal venter ikke på en replika og bruger i stedet primærserveren, hvis det er nødvendigt; timeout-reglen gælder ikke der. De er derfor især velegnede til arbejdsbelastninger, der hovedsageligt består af læsninger med få skrivninger. Fra og med MaxScale 24.02 konfigurerer MaxScale selv den nødvendige sporing for nye backend-forbindelser; ældre versioner kræver til dette last_gtid på session_track_system_variables på alle backends.

Inden for en åben læse-skrive-transaktion videresender readwritesplit læseadgange til primærserveren. Dette forhindrer, at instruktioner fra samme transaktion udføres på backends med forskellige replikeringsniveauer. Denne konservative regel fritager ikke for at fastsætte transaktionsgrænser fagligt korrekt og behandle replikeringsforsinkelse som en separat arkitektonisk begrænsning.

Også når det gælder lagrede procedurer, UDF-kald og multi-statements, er beslutningen bevidst mere forsigtig: I dokumenterede tilfælde dirigeres sådanne forespørgsler til Primary. Årsagen er, at deres virkning eller kontekst ikke bør behandles som en simpel læseforespørgsel. SQL-routing er således ikke blot en søgning efter ordet SELECT, men følger regler for sikker håndtering af sessioner og semantik.

En fagligt fastsat grænseværdi for Replica-Lag kan udelukke replikaer fra bestemte læsebeslutninger, men erstatter ikke et konsistenskrav. Hvor stor en forsinkelse der er acceptabel, afhænger blandt andet af, om en forældet katalogpost kan tolereres, eller om en netop bekræftet betalingsstatus absolut skal være synlig. Denne beslutning hører hjemme i applikationslogikken og driftsaftalen, ikke i en generel proxy-standardindstilling.

Konfigurer Readwritesplit korrekt

En Read/Write-Split-konfiguration består af separate objektdefinitioner for backends, monitor, service og listener. Det følgende uddrag viser strukturen i en fil, ikke en skabelon, der umiddelbart kan bruges i produktion. Værdierne i spidse parenteser er udtrykkeligt ikke adgangskoder, men henvisninger til konti og hemmeligheder, der skal stilles til rådighed via driftsmiljøets hemmelighedsadministration. Monitor og Service har hver især brug for egne adgangsdata til deres forskellige opgaver.

[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

Serverobjekterne angiver udelukkende tilgængelige MariaDB-backends; monitoren fastslår ud fra topologien, hvilken instans der er primær eller replika. Monitor-kontoen bruges til status- og rolleforespørgsler. Den separate servicekonto bruges til at hente de bruger- og rettighedsoplysninger fra backendene, der er nødvendige for klientautentificering og -autorisation. Begge konti har kun brug for de rettigheder, der er dokumenteret for deres respektive opgaver. Genkende roller og indlæsning af brugeroplysninger er to separate opgaver.

Pladsholderne i eksemplet skal udfyldes ved implementeringen via en beskyttet implementeringsvej; de er ikke tænkt som bogstavelige konfigurationsværdier. Klartekstadgangskoder, reelle certifikatstier eller ukontrollerede rettighedspakker hører ikke hjemme i frit tilgængelige filer eller repositorier. MaxScale administrerer internt relevante brugerkonti og rettigheder fra systemtabellerne til MariaDB-protokolforbindelser. Hvis konti eller rettigheder ændres, kan forældede oplysninger forringe log-in eller autorisation.

Inden idriftsættelsen skal lytterporten, netværksstierne, brugersammenkoblingen og den faktiske routertildeling derfor kontrolleres hver for sig. Heller ikke monitorens automatiske indgreb indgår implicit i denne minimalkonfiguration: Failover-, switchover- eller rejoin-funktioner kræver yderligere konfiguration og et afprøvet driftskoncept. En tilsyneladende kort konfiguration erstatter hverken hemmelighedsstyring eller kontrollen af backend-topologien.

Sammenlign routermodeller efter anvendelse

Valget af router afhænger af applikationens adfærd og ikke alene af antallet af tilgængelige replikaer. Direkte forbindelser gør opbygningen enkel, men overlader skift af destination og kendskab til roller til applikationen. To adskilte endepunkter med readconnroute er relevant, når applikationen bevidst selv håndterer læse- og skriveforbindelser. Statement-routing Det er hensigtsmæssigt at bruge `readwritesplit`, hvis en session skal dirigeres til primærserveren eller replikaerne afhængigt af SQL-forespørgslen.

readconnroute vurderer en målserver, når forbindelsen oprettes, og analyserer ikke hver eneste efterfølgende SQL-sætning. Hvis det valgte backend går ned, afsluttes sessionen; routeren forbinder den ikke automatisk til en anden server. Dette er ofte forståeligt for klart adskilte, kortvarige læseforbindelser, men kan være uegnet til tilstandsbaserede applikationsforløb.

Der skal udvises særlig forsigtighed i forbindelse med en tjeneste, der er beregnet som et læse-endepunkt, med router_options=slave. Indstillingen foretrækker servere med replikarolle; hvis alle replikaer er nede, og primærserveren er tilgængelig, kan readconnroute dog falde tilbage på primærserveren. Desuden skaber indstillingen ingen skrivebeskyttelse. Applikationen skal udelukkende sende læse-SQL, eller et yderligere ReadOnly-filter skal forhindre skriveadgang. Routingmål og rollepræference udgør således hverken en autorisationsgrænse eller en erstatning for restriktive databaserettigheder.

readwritesplit reducerer derimod antallet af målvalg i applikationskoden, men kræver en nøje gennemgang af semantikken. Egnede læseoperationer kan fordeles på replikaer, mens skriveoperationer sendes til primærserveren. For processer med strenge krav til aktualitet er det afgørende, om en forespørgsel efter en skrivning må vente på replikerede data eller bevidst skal bruge primærserveren.

Planlægning af møder, lagerbeholdning og omstilling

En databasesession omfatter mere end blot den enkelte forespørgsel. SET, USE, CHANGE USER og Prepared Statement-operationer ændrer deres kontekst. readwritesplit replikerer relevante sessionskommandoer til mulige målservere, så senere omdirigerede sætninger kan udføres med den korrekte sessionstilstand. Dette adskiller routeren fra simpel TCP-load-balancing, men fjerner ikke alle begrænsninger i særlige tilfælde.

Denne begrænsning er særlig vigtig i forbindelse med forberedte sætninger til midlertidige tabeller. Hvis en sådan sætning forberedes på primærserveren, kan replikaerne ikke nødvendigvis udføre den. Applikationen bør derfor teste midlertidige objekter, forberedte sætninger og transaktionsforløb ved hjælp af den fastlagte routingmodel. Sessionens tilstand er ikke en sekundær betingelse, men afgør, om en SQL-fordeling er hensigtsmæssig både fagligt og teknisk.

I forbindelse med en læseintensiv anvendelse kan teamet definere en fagligt fastsat lag-grænseværdi som et udelukkelseskriterium for replikaer. Alene max_replication_lag Dette sikrer dog ikke, at en tidligere skrivning på en replika allerede er synlig. For kritiske efterfølgende læsninger kan der, afhængigt af forløbet, være tale om en bevidst primærsti, en fælles skrivningskontekst eller aktiverede kausale læsninger.

Ved kausale læsninger skal anvendelsesområdet vælges bevidst. local bevarer kausaliteten inden for en sammenhæng. global bruger en GTID-værdi, der er gemt på tværs af tjenesten, men garanterer kun den globale »happens-before«-rækkefølge for læsningerne, hvis alle transaktioner befinder sig i et enkelt GTID-domæne. universal tager højde for den transaktionsstatus i klyngen, der kan observeres på primærserveren. Ikke-hurtige tilstande synkroniseres med GTID’er; hvis en replika ikke indhenter forsinkelsen inden for den konfigurerede timeout, gentages forespørgslen som udgangspunkt på primærserveren, forudsat at transaktionstilstanden tillader det.

Funktionen skal klassificeres efter version. Fra og med MaxScale 24.02 tilføjer MaxScale last_gtid til nye backend-forbindelser selv; i ældre versioner var man nødt til session_track_system_variables skal være indstillet korrekt på MariaDB-backends. De hurtige tilstande undgår ventetid, men kan, hvis replikaerne endnu ikke er kommet ajour, omdirigere læsninger til primærserveren og er derfor ikke generelt egnede til skriveintensive belastninger.

En planlagt switchover og en automatisk failover skal ligeledes behandles hver for sig. Ved en switchover forberedes et rollebytte på en kontrolleret måde, mens driften ved en failover reagerer på en fejltilstand. mariadbmon kan overvåge roller og backend-tilstande og kan, hvis det er konfigureret hertil, understøtte disse processer. Replikeret datatilstand, entydig topologi, alarmering og en hændelsesproces er fortsat forudsætninger herfor.

I MaxScale 25.10 kan man discover-replicas Identificere servere, der replikerer direkte til den aktuelle primære server, og tilføje dem til Monitor og MaxScale. Denne funktion er ikke kompatibel med konfigurationssynkronisering. Inden anvendelsen skal teamet derfor fastlægge, om topologiske ændringer skal opdages automatisk eller styres via en synkroniseret konfiguration; begge dele på samme tid er ikke en tilladt antagelse i denne sammenhæng.

TLS, beskyttelse af rettigheder og filtre

I MaxScale skal TLS planlægges på to separate forbindelser: fra applikationen til listeneren og fra proxyen til MariaDB-backends. Begge forbindelser kræver egne indstillinger for kryptering og certifikatvalidering; en sikker klientforbindelse krypterer ikke automatisk den efterfølgende trafik. Konfigurationen skal derfor afspejle sikkerhedsbehovet og tillidskæden for begge sektioner.

TLS er aktiveret ssl=true krypteringen i den pågældende listener- eller serverkonfiguration. Hvis en klient forventer et servercertifikat, skal listeneren have et certifikat og en privat nøgle. En konto med REQUIRE SSL kan ikke logge på via en listener uden TLS. Certifikatfiler og nøgler hører hjemme i et beskyttet driftsmiljø, ikke i frit tilgængelige eksempel- eller repository-konfigurationer.

Også den Rettighedsbegrebet Det er stadig afgørende på backend-siden: MaxScale formidler forbindelser, men erstatter ikke specifikke databasekonti. Servicekonti tildeles kun de rettigheder, som deres opgave kræver. Til login og autorisation baserer MaxScale sig på brugerkonti og rettigheder fra MariaDB-systemtabellerne; ændringer af disse konti skal derfor være tilgængelige i den interne brugeradministration med det samme.

Firewall-filteret kan kontrollere SQL før videresendelse på baggrund af indlærte eller definerede regler. Det har tilstandene inaktiv, indlæring, overvågning og håndhævelse; i håndhævelsestilstanden besvares ikke-tilladte sætningsmønstre, afhængigt af indstillingen, med en fejlmeddelelse, eller forbindelsen afbrydes. Indlæringsfasen skal omfatte repræsentative, tilladte applikationsforløb, så filteret ikke blokerer almindelige forespørgsler.

Filtret er et ekstra kontrollag for forventede SQL-mønstre, ikke en erstatning for adgangsrettigheder. Restriktive databaserettigheder, beskyttede adgangsoplysninger og kontrolleret applikationskode er fortsat nødvendige, da filteret kun vurderer de forespørgsler, der modtages, ud fra sine egne regler. Oplysninger om andre filtre bør kontrolleres separat ved hjælp af deres respektive dokumentation.

Systematisk kontrol af konfiguration og fejl

Ved forbindelses- eller routingfejl er det en fordel at følge en fast kontrolrækkefølge i stedet for at foretage ændringer på mavefornemmelse. Kontroller først monitorstatus: Er alle backends tilgængelige, og genkendes primær- og replikaroller som forventet? Først derefter kan routerbeslutninger vurderes på en fornuftig måde. En forkert genkendt eller utilgængelig node er ikke udelukkende et listener-problem.

Derefter følger lytteren og TLS: Port, protokol, certifikat, nøgle og kravene til de anvendte konti skal stemme overens. Kontroller derefter, om brugerkontoadministrationen kender de aktuelle backend-konti og rettigheder. Især efter ændringer af brugere eller rettigheder kan forældede kontodata forhindre log-in, selvom kontoen i MariaDB selv er korrekt oprettet.

Dernæst skal du tildele tjenester, routere og de påtænkte servere. Ved læse-/skriveopdeling skal du desuden angive replikaforsinkelse, causal_reads og applikationens transaktionsgrænser til tjeklisten. Uden aktiverede kausale læsninger kan en læsning uden for den nødvendige skrivekontekst på en replika levere en ældre tilstand; en forsinkelsesgrænseværdi alene garanterer ikke synligheden af en tidligere skrivning.

Læg desuden en enkelt Konfigurationskilde fast. MaxScale kan gemme ændringer under kørsel; ved genstart kan den gemte konfiguration overskrive statiske filer. Hvis et team dels redigerer filer og dels maxctrl Når denne kørselskonfiguration anvendes, skal ændringsforløbet, gennemgangen og sikkerhedskopieringen af den være dokumenteret på en forpligtende måde.

Vedligeholdelsesvinduer til skemaændringer skal du behandle som et særskilt driftsområde: Afhængigheder, låseadfærd og replikering skal kontrolleres på forhånd og må ikke tilskrives proxyen. Til planlægning af kontrollerede ændringer i store MariaDB-tabeller indeholder artiklen om Skemaændringer uden nedetid supplerende kontekst. MaxScale kan derefter igen styre forbindelser og routing ud fra backend-rollerne, men udfører ikke nogen DDL-strategi for databasen.

Advarsel: Ændringer af roller, certifikater, brugerrettigheder og routing bør du først gennemføre i et tilsvarende miljø. Når der foretages ændringer i produktionsmiljøet, er det vigtigt at have en genoprettelsesplan, overvågning af applikationsfejl og klare ansvarsforhold. På den måde kan man skelne mellem, om en fejl stammer fra proxykonfigurationen, backend-systemet eller klientens adfærd.

Brug MaxScale på den rigtige måde, eller lad være med at bruge det

På en enkelt MariaDB-server uden krav til routing, omdirigering eller SQL-filtrering er direkte forbindelser som regel den enkleste driftsform. Applikationen skal dog selv håndtere et eventuelt senere skift af mål. MaxScale er en fordel, hvis det ekstra endepunkt udfører en konkret opgave, f.eks. at håndtere rolleændringer, filtrere adgang eller fordele læsninger kontrolleret på replikaer.

Hvis applikationen selv bevidst kan vælge læse- og skrivestier, er der separate slutpunkter med readconnroute ofte forståeligt. Denne router vælger et backend, når der oprettes forbindelse, men analyserer ikke hver enkelt SQL-sætning og flytter ikke en afbrudt session over til en anden server. Ved router_options=slave Der foretrækkes replikaer; hvis alle replikaer er nede, og primærserveren stadig er tilgængelig, kan routeren bruge primærserveren. Indstillingen gør desuden ikke slutpunktet skrivebeskyttet. Til dette kræves et passende ReadOnly-filter, restriktive backend-rettigheder eller strengt kontrolleret applikations-SQL.

For Primary-Replica-arbejdsbelastninger, hvis ORM og transaktionsmodel passer til dette, anvender readwritesplit I applikationen angives SQL-målet for hver enkelt sætning. I standardindstillingen causal_reads=none Replikationsforsinkelsen forbliver dog synlig. Efter kritiske skrivninger kan applikationen anvende en primær læsevej eller en passende fælles transaktionskontekst; alternativt kan kausale læsninger konfigureres målrettet til det påkrævede synlighedsområde.

Causal Reads skelner mellem synlighed inden for samme session, en tjenestestyret global GTID-status og den tilstand af klyngen, der kan observeres på primærserveren. local gælder for den samme forbindelse. Ved global Den globale »happens-before«-rækkefølge for læsningerne er kun garanteret, hvis alle transaktioner tilhører et enkelt GTID-domæne; denne tilstand må derfor ikke generelt opfattes som en ubegrænset konsistensgaranti på tværs af tjenesterne. universal Kontrollerer den observerbare tilstand på primærserveren før læsninger. Synkroniseringsmoderne kan medføre ekstra ventetid; hurtige varianter venter ikke, men kan ved skrivninger flytte belastningen i højere grad over på primærserveren.

Grænsetilfælde bør testes målrettet med den faktiske driver og datamodellen, inden de implementeres. Midlertidige tabeller og forberedte sætninger, der er baseret på disse, er muligvis ikke tilgængelige på replikaer, hvis forberedelsen foregår på primærserveren. Også gemte procedurer, UDF-kald, multisætninger og sessionstilstand har indflydelse på, om routeren dirigerer trafikken konservativt til primærserveren.

Transaction Replay er ingen garanti for tabsløse transaktioner. Hvis en forbindelse afbrydes under COMMIT ... kan det stå åbent, om commit’et allerede er gennemført. Risikable replay-konfigurationer kan udføre skriveoperationer to gange; serverafhængige resultater som NOW() eller @@server_id kan desuden udløse afvigelser i kontrolsummen. Vurder derfor brugen ud fra krav til konsistens, fejlforløb og gentagelsesmulighederne for skrivningerne, ikke ud fra generelle løfter om ydeevne.