Använda MariaDB MaxScale som databasproxy

Konfigurera MaxScale som proxylager

MariaDB MaxScale är ett fristående proxylager mellan applikationen och MariaDB-servrarna. För att driften ska vara stabil måste konfigurationen, de tillgängliga funktionerna och kända begränsningar alltid stämma överens med den version som faktiskt är installerad. Serien MaxScale 25.10 presenteras i den officiella dokumentationen med egna release notes.

Applikationen ansluter till en lyssnare i MaxScale istället för direkt till en databasserver. En tjänst sammanfattar åtkomstlogiken, en router bestämmer backend, och filter kan dessutom bearbeta förfrågningar innan de vidarebefordras. Data förblir på MariaDB-backendarna; MaxScale fungerar inte själv som en databas.

Denna uppdelning är särskilt användbar när en applikation inte själv ska veta vilken server som för tillfället har vilken roll. För grundläggande information om datamodellen, SQL och driften av databasen, se artikeln MariaDB som en öppen källkodsdatabas ett lämpligt komplement. Proxyn kompletterar serverarkitekturen, men ersätter varken databasbehörigheter eller ett koncept för replikering och avbrott.

På Anslutningsruttning MaxScale väljer ett mål när en session upprättas; detta backend förblir ansvarigt för sessionen. Vid satsrouting kan routern tilldela enskilda SQL-satser olika mål beroende på deras innehåll. Vilken variant som är lämplig beror därför på transaktioner, sessionens status och applikationens förmåga att själv tydligt separera läs- och skrivvägar.

En Databasproxy är inte ett generellt prestationslöfte. Det kan centralisera routningen, avkoppla rollbyten mellan applikationer eller fördela lämpliga läsförfrågningar. Ytterligare nätverksnoder, SQL-analys och den konkreta backend-topologin påverkar dock beteendet. Skalbarhet och kapacitet måste därför testas med den egna versionen, konfigurationen och belastningen.

Övervaka primär-replikat-topologin på rätt sätt

En typisk målarkitektur består av en skrivande primärserver och en eller flera läsande repliker. MaxScale är applikationens enda databasändpunkt, till exempel bakom ett fast DNS-namn. Applikationen ansluter sig därför inte direkt till enskilda värdar; valet av en tillgänglig och lämplig backend sker inom proxylagret.

För en primär-replikat-topologi beräknar övervakningsprogrammet mariadbmon backendernas status och identifierar deras roller som primär eller replik. Routrarna kan använda denna information för att välja destination. Monitorn måste därför kunna se den faktiska replikeringstopologin; felaktiga tilldelningar, data som inte replikeras eller oklara roller är inte routningsproblem, utan driftsrisker.

Att identifiera en roll ska skiljas från att ändra den. Med rätt konfiguration och behörighet kan mariadbmon hantera failover, planerade switchover och rejoin. En övergång är ett medvetet förberett rollbyte för underhåll eller drift; en failover är en reaktion på ett fel. Båda processerna kräver en tydlig topologi, övervakning, larmhantering och en dokumenterad incident- eller återställningsprocess.

För rena övervakningsuppgifter bör monitor-kontot fungera enligt principen Lägsta privilegium endast de behörigheter som krävs. I den aktuella dokumentationen kallas detta REPLICA MONITOR. Ytterligare behörigheter krävs beroende på vilka funktioner som är aktiverade, till exempel FILE vid en kontroll av lagringsutrymmet eller andra specifika behörigheter för topologiskanningar och klusterhantering. Generella fullständiga behörigheter är inget substitut för detta.

Innan automatiseringen genomförs bör teamet fastställa vem som godkänner ett rollbyte, hur replikernas status kontrolleras och hur applikationerna informeras om störningar. MaxScale kan anpassa routningsmål utifrån identifierade roller. Huruvida en omkoppling är tekniskt tillåten avgörs dock av högtillgänglighetskonceptet med dess gränser vad gäller data, tid och ansvar.

Att förstå SQL-routing och konsistensgränser

Routern läs-skriv-delning vidarebefordrar skrivande SQL-kommandon till primärservern och fördelar lämpliga läsförfrågningar till replikerna. På så sätt kan ett primär-replik-kluster utnyttja sin läskapacitet på ett mer målinriktat sätt, utan att applikationen själv behöver tilldela varje förfrågan till en specifik server. Monitorens rollinformation utgör grunden för urvalet.

Denna uppdelning garanterar inte i standardutförandet att en läsning direkt efter varje skrivning ser det nya läget. causal_reads är inställt som standard på none. Om en applikation till exempel skriver in en beställningsstatus och sedan läser den via en oberoende förfrågan, kan en replik därför fortfarande leverera den tidigare statusen. En medvetet vald primär läsväg eller ett gemensamt transaktionssammanhang är möjliga strategier, men inte de enda.

För Läs dina skrivningar Med readwritesplit och aktiverade kausala läsningar kan systemet ta hänsyn till tidigare skrivningar trots replikfördröjningen. Läget local säkerställer synligheten för samma anslutning. global håller reda på den GTID-status som tjänsten har lagrat över alla sina anslutningar; en global ”happen-before”-ordning för läsningarna garanteras endast om alla transaktioner ligger inom en och samma GTID-domän. universal beaktar klustrets transaktionsstatus som kan observeras på Primary. De mer omfattande tillämpningsområdena ökar dock synkroniseringsbehovet och därmed potentiellt latensen.

Kausala läsningar använder GTID-information och väntar på replikering i de icke-snabba lägena. Om synkroniseringen tar längre tid än causal_reads_timeout – som standard 10 sekunder – försöker readwritesplit att köra frågan på primärservern. I en skrivskyddad transaktion kan en timeout istället returneras som ett fel, eftersom frågan inte får flyttas till primärservern.

De snabba lägena fast, fast_global och fast_universal väntar inte på en replik och använder vid behov primärservern; tidsgränsen gäller inte där. De passar därför framför allt för arbetsbelastningar som huvudsakligen består av läsningar med få skrivningar. Från och med MaxScale 24.02 konfigurerar MaxScale själv den nödvändiga spårningen för nya backend-anslutningar; äldre versioner kräver för detta last_gtid på session_track_system_variables på alla backend-system.

Inom en öppen läs-skriv-transaktion vidarebefordrar readwritesplit läsåtkomst till primärservern. Detta förhindrar att satser inom samma transaktion körs på backend-servrar med olika replikeringsstatus. Denna konservativa regel befriar inte från skyldigheten att sätta transaktionsgränser på ett tekniskt korrekt sätt och att behandla replikeringsfördröjning som en egen arkitektonisk begränsning.

Även när det gäller lagrade procedurer, UDF-anrop och multikommandon är beslutet medvetet mer försiktigt: I dokumenterade fall dirigeras sådana förfrågningar till Primary. Anledningen är att deras effekt eller sammanhang inte bör behandlas som en enkel läsfråga. SQL-routing är alltså inte enbart en sökning efter ordet SELECT, utan följer regler för säker hantering av sessioner och semantik.

Ett fackmässigt fastställt gränsvärde för Replica-Lag kan utesluta repliker av vissa läsbeslut, men ersätter inte något konsistenskrav. Hur stor fördröjning som är acceptabel beror bland annat på om en föråldrad katalogpost är acceptabel eller om en just bekräftad betalningsstatus absolut måste vara synlig. Detta beslut hör hemma i applikationslogiken och driftsavtalet, inte i en allmän proxy-förinställning.

Konfigurera Readwritesplit på ett säkert sätt

En Read/Write-Split-konfiguration består av separata objektdefinitioner för backend, monitor, tjänst och lyssnare. Följande utdrag visar strukturen på en fil, inte en mall som direkt kan användas i produktion. Värdena inom spetsiga parenteser är uttryckligen inga lösenord, utan hänvisningar till konton och hemligheter som ska tillhandahållas via driftsmiljöns hemlighetshantering. Monitor och Service behöver var för sig egna inloggningsuppgifter för sina olika uppgifter.

[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

Serverobjekten avser endast tillgängliga MariaDB-backends; vilken instans som är primär eller replik avgörs av övervakaren utifrån topologin. Övervakningskontot används för status- och rollförfrågningar. Det separata servicekontot används för att hämta den användar- och behörighetsinformation från backend-servrarna som krävs för klientautentisering och auktorisering. Båda kontona behöver endast de behörigheter som dokumenterats för deras respektive uppgifter. Identifiera roller Att ladda in data och användarinformation är två separata uppgifter.

Platshållarna i exemplet måste ersättas vid driftsättningen via en säker distributionsväg; de är inte avsedda att användas som bokstavliga konfigurationsvärden. Lösenord i klartext, faktiska certifikatvägar eller okontrollerade behörighetspaket hör inte hemma i fritt läsbara filer eller repositorier. MaxScale hanterar internt relevanta användarkonton och behörigheter från systemtabellerna för MariaDB-protokollanslutningar. Om konton eller behörigheter ändras kan föråldrad information påverka inloggningen eller auktoriseringen.

Innan driftsättning ska därför lyssnarporten, nätverksvägarna, användarsynkroniseringen och den faktiska routertilldelningen kontrolleras separat. Inte heller ingår automatiska ingripanden från övervakningssystemet implicit i denna minimikonfiguration: Failover-, switchover- eller rejoin-funktioner kräver ytterligare konfiguration och ett testat driftskoncept. En till synes kortfattad konfiguration ersätter varken hanteringen av hemliga nycklar eller kontrollen av backend-topologin.

Jämför routermodeller efter användningsområde

Valet av router styrs av applikationens beteende, inte enbart av antalet tillgängliga repliker. Direkta anslutningar förenklar uppbyggnaden, men överlåter valet av mål och kunskapen om roller till applikationen. Två separata ändpunkter med readconnroute är lämpligt när applikationen medvetet hanterar läs- och skrivanslutningarna själv. Statement-routing Att använda `readwritesplit` är lämpligt när en session ska dirigeras till primärservern eller replikerna beroende på SQL-kommandot.

readconnroute utvärderar en målserver när anslutningen upprättas och analyserar inte varje efterföljande SQL-sats. Om den valda backenden slutar fungera avslutas sessionen; routern kopplar inte automatiskt om den till en annan server. Detta är ofta acceptabelt för tydligt avgränsade, kortvariga läsanslutningar, men kan vara olämpligt för tillståndsrika applikationsflöden.

Särskild försiktighet bör iakttas när det gäller en tjänst som är avsedd som läs-ändpunkt med router_options=slave. Alternativet prioriterar servrar med replikroll; om alla repliker har slutat fungera och primärservern är tillgänglig kan readconnroute dock fall tillbaka på primärservern. Dessutom skapar alternativet inget skrivskydd. Applikationen måste uteslutande skicka läs-SQL, eller så måste ett extra ReadOnly-filter förhindra skrivåtkomst. Routningsmål och rollpreferens utgör därmed varken en behörighetsgräns eller en ersättning för restriktiva databasrättigheter.

readwritesplit minskar däremot antalet målval i applikationskoden, men kräver en noggrann granskning av semantik. Lämpliga läsningar kan fördelas på repliker, medan skrivoperationer går till primärservern. För processer med strikta krav på aktualitet är det avgörande om en förfrågan efter en skrivning får vänta på replikerade data eller medvetet måste använda primärservern.

Planera möten, lager och omställning

En databassession omfattar mer än en enskild fråga. SET, USE, CHANGE USER och operationer med förberedda satser ändrar sitt sammanhang. readwritesplit replikerar relevanta sessionskommandon till möjliga målservrar, så att senare vidarebefordrade satser kan köras med rätt sessionsstatus. Detta skiljer routern från enkel TCP-lastbalansering, men eliminerar inte alla begränsningar i specialfall.

Denna gräns är särskilt viktig när det gäller förberedda satser för tillfälliga tabeller. Om en sådan sats förbereds på primärservern kan replikerna inte nödvändigtvis köra den. Applikationen bör därför testa tillfälliga objekt, förberedda satser och transaktionsflöden med den avsedda routningsmodellen. Sessionsstatus är inte en sekundär förutsättning, utan avgör om en SQL-fördelning är lämplig ur både affärsmässig och teknisk synvinkel.

För en läsintensiv tillämpning kan teamet definiera ett tekniskt fastställt lag-gränsvärde som ett uteslutningskriterium för repliker. Enbart max_replication_lag garanterar dock inte att en tidigare skrivning på en replik redan är synlig. För kritiska efterföljande läsningar kan, beroende på förloppet, en medveten primärväg, ett gemensamt skrivkontext eller aktiverade kausala läsningar komma i fråga.

Vid kausala avläsningar måste tillämpningsområdet väljas medvetet. local bevarar kausaliteten inom en koppling. global använder ett GTID-värde som lagras för hela tjänsten, men garanterar endast den globala ”happens-before”-ordningen för läsningarna om alla transaktioner ligger inom en enda GTID-domän. universal tar hänsyn till klustrets transaktionsstatus som kan observeras på primärservern. Långsamma lägen synkroniseras med GTID:er; om en replik inte hinner ikapp inom den konfigurerade tidsgränsen upprepas frågan alltid på primärservern, i den mån transaktionsläget tillåter det.

Funktionen beror på versionen. Från och med MaxScale 24.02 har MaxScale lagt till last_gtid för nya backend-anslutningar själv; i äldre versioner var man tvungen att session_track_system_variables måste vara inställda på motsvarande sätt i MariaDB-backendarna. De snabba lägena undviker väntetider, men kan vid repliker som ännu inte hunnit ikapp styra läsningar till primärservern och är därför inte generellt lämpliga för skrivintensiva arbetsbelastningar.

En planerad övergång och en automatisk failover ska också behandlas separat. Vid en övergång förbereds ett rollbyte på ett kontrollerat sätt, medan driften vid en failover reagerar på ett fel. mariadbmon kan övervaka roller och backend-tillstånd och kan, förutsatt att det konfigurerats på rätt sätt, stödja dessa processer. Replikerat datatillstånd, entydig topologi, larmfunktioner och en incidenthanteringsprocess förblir förutsättningar för detta.

I MaxScale 25.10 kan man discover-replicas Identifiera servrar som replikerar direkt till den aktuella primära servern och lägg till dem i Monitor och MaxScale. Denna funktion är inte kompatibel med konfigurationssynkronisering. Innan funktionen tas i bruk måste teamet därför bestämma om topologiförändringar ska upptäckas automatiskt eller styras via en synkroniserad konfiguration; att använda båda samtidigt är inte tillåtet i detta sammanhang.

TLS, säkra rättigheter och filter

TLS måste i MaxScale planeras på två separata sträckor: från applikationen till lyssnaren och från proxyn till MariaDB-backenderna. Båda anslutningarna kräver egna inställningar för kryptering och certifikatverifiering; en säker klientsträcka krypterar inte automatiskt den efterföljande trafiken. Konfigurationen måste därför återspegla säkerhetsbehovet och förtroendekedjan för båda delarna.

TLS är aktiverat ssl=true krypteringen i respektive lyssnare- eller serverkonfiguration. Om en klient förväntar sig ett servercertifikat behöver lyssnaren certifikatet och den privata nyckeln. Ett konto med REQUIRE SSL kan inte ansluta via en lyssnare utan TLS. Certifikatfiler och nycklar hör hemma i en skyddad driftsmiljö, inte i fritt läsbara exempel- eller repositoriekonfigurationer.

Även den Rättsbegreppet Det är fortfarande avgörande på backend-sidan: MaxScale förmedlar anslutningar, men ersätter inte specifika databaskonton. Servicekonton tilldelas endast de behörigheter som krävs för deras uppgift. För inloggning och auktorisering förlitar sig MaxScale på användarkonton och behörigheter från MariaDB:s systemtabeller; ändringar av dessa konton måste därför snabbt bli tillgängliga i den interna användarhanteringen.

Brandväggsfiltret kan kontrollera SQL före vidarebefordran utifrån inlärda eller definierade regler. Det har lägena viloläge, inlärningsläge, övervakningsläge och tvingningsläge; i tvingningsläget besvaras otillåtna satsmönster, beroende på inställning, med ett felmeddelande eller så bryts anslutningen. Inlärningsfasen måste omfatta representativa, tillåtna applikationsflöden så att filtret inte blockerar vanliga frågor.

Filtret är ett extra kontrollskikt för förväntade SQL-mönster, inte en ersättning för behörighetskontroll. Restriktiva databasbehörigheter, skyddade inloggningsuppgifter och granskad applikationskod är fortfarande nödvändiga, eftersom filtret endast utvärderar de förfrågningar som kommer in till det utifrån sina egna regler. Uttalanden om andra filter bör granskas separat utifrån deras respektive dokumentation.

Systematiskt kontrollera konfigurationen och felen

Vid anslutnings- eller routningsfel är det bättre att följa en fast kontrollordning än att göra ändringar på gissning. Kontrollera först monitorns status: Är alla backend-enheter tillgängliga, och identifieras primär- och replikrollerna som förväntat? Först då kan man på ett meningsfullt sätt bedöma routerbesluten. En felaktigt identifierad eller oåtkomlig nod är inte enbart ett problem med lyssnaren.

Därefter följer lyssnare och TLS: port, protokoll, certifikat, nyckel och kraven för de konton som används måste stämma överens. Kontrollera därefter om användarkontohanteringen känner till aktuella backend-konton och behörigheter. Särskilt efter ändringar av användare eller behörigheter kan föråldrade kontouppgifter förhindra inloggningar, även om kontot i MariaDB i sig är korrekt konfigurerat.

Därefter tilldelar du tjänster, routrar och de avsedda servrarna. Vid läs-/skrivuppdelning ingår dessutom replikfördröjning, causal_reads och applikationens transaktionsgränser till kontrollistan. Om kausala läsningar inte är aktiverade kan en läsning utanför den nödvändiga skrivkontexten på en replik ge ett äldre tillstånd; en fördröjningsgräns i sig garanterar inte synligheten för en tidigare skrivning.

Lägg dessutom en enda Konfigurationskälla fast. MaxScale kan spara ändringar under körning; vid omstart kan den sparade konfigurationen ersätta statiska filer. Om ett team delvis redigerar filer och delvis maxctrl När denna körningskonfiguration används måste ändringsförloppet, granskningen och säkerhetskopieringen av den dokumenteras på ett bindande sätt.

Du ska hantera underhållsfönster för schemabändringar som ett separat driftsområde: beroenden, spärrbeteende och replikering måste kontrolleras i förväg och får inte tillskrivas proxyn. För planering av kontrollerade ändringar i stora MariaDB-tabeller finns artikeln om Schemaförändringar utan driftstopp kompletterande sammanhang. MaxScale kan därefter återigen styra anslutningar och routning utifrån backend-rollerna, men genomför ingen DDL-strategi för databasen.

Varning: Ändringar av roller, certifikat, användarrättigheter och routning bör du först testa i en liknande miljö. Inför en produktiv åtgärd ingår återställningsprocessen, övervakning av applikationsfel och tydliga ansvarsområden. På så sätt går det att avgöra om ett fel härrör från proxykonfigurationen, backend-systemet eller klientens beteende.

Använda MaxScale på rätt sätt eller avstå från det

För en enskild MariaDB-server utan krav på routning, omkoppling eller SQL-filter är direkta anslutningar oftast det enklaste driftsättet. Applikationen måste då dock själv hantera ett eventuellt senare byte av mål. MaxScale är ett bra val om den extra slutpunkten fyller en specifik funktion, till exempel att hantera rollbyten, filtrera åtkomst eller på ett kontrollerat sätt fördela läsningar på repliker.

Om applikationen själv medvetet kan välja läs- och skrivvägar, kan separata ändpunkter med readconnroute ofta förståeligt. Denna router väljer ett backend när anslutningen upprättas, men analyserar inte varje SQL-sats och flyttar inte en avbruten session till en annan server. Vid router_options=slave Repliker prioriteras; om alla repliker har slutat fungera och primärservern fortfarande är tillgänglig kan routern använda primärservern. Alternativet gör dessutom inte slutpunkten skrivskyddad. För detta krävs ett lämpligt ReadOnly-filter, restriktiva backend-behörigheter eller strikt kontrollerad applikations-SQL.

För primär-replika-arbetsbelastningar vars ORM och transaktionsmodell är anpassade för detta gäller att läs-skriv-delning programmet väljer SQL-mål för varje sats. Vid standardinställningen causal_reads=none Replikationsfördröjningen förblir dock synlig. Efter kritiska skrivningar kan applikationen använda en primär läsväg eller ett lämpligt gemensamt transaktionssammanhang; alternativt kan kausala läsningar konfigureras specifikt för det önskade synlighetsområdet.

Causal Reads skiljer mellan synlighet inom samma session, en globalt GTID-tillstånd som hanteras av tjänsten och klustrets tillstånd som kan observeras på primärservern. local gäller för samma anslutning. Vid global Den globala ”happens-before”-ordningen för läsningarna garanteras endast om alla transaktioner tillhör en och samma GTID-domän; läget får därför inte generellt tolkas som en obegränsad konsistensgaranti för hela tjänsten. universal Kontrollerar det observerbara läget på primärservern före läsningar. Synkroniseringslägena kan medföra ytterligare väntetid; snabba varianter väntar inte, men kan vid skrivningar förskjuta belastningen i större utsträckning till primärservern.

Gränsfall bör testas noggrant med den faktiska drivrutinen och datamodellen innan de införs. Tillfälliga tabeller och förberedda SQL-satser kanske inte är tillgängliga på replikerna om förberedelsen sker på primärservern. Även lagrade procedurer, UDF-anrop, multikommandon och sessionstillstånd påverkar om routern dirigerar trafiken konservativt till primärservern.

Transaction Replay garanterar inte att transaktionerna sker utan förluster. Om en anslutning bryts under COMMIT kan frågan om huruvida committen redan har genomförts framgångsrikt lämnas öppen. Riskfyllda replay-konfigurationer kan utföra skrivoperationer två gånger; serverberoende resultat såsom NOW() eller . @@server_id kan dessutom orsaka avvikelser i kontrollsummorna. Bedöm därför användningen utifrån krav på konsistens, felhantering och repeterbarhet hos skrivoperationerna, inte utifrån generella prestandalöften.