MariaDB MaxScale als database-proxy gebruiken

MaxScale als proxylaag instellen

MariaDB MaxScale is een zelfstandige proxylaag tussen de applicatie en de MariaDB-servers. Voor een betrouwbare werking moeten de configuratie, de beschikbare functies en de bekende beperkingen altijd overeenkomen met de daadwerkelijk geïnstalleerde versie. De MaxScale 25.10-serie wordt in de officiële documentatie vermeld met eigen release notes.

De applicatie maakt verbinding met een listener van MaxScale in plaats van rechtstreeks met een databaseserver. Een service bundelt daarbij de toegangslogica, een router bepaalt de backend en filters kunnen verzoeken bovendien verwerken voordat ze worden doorgestuurd. De gegevens blijven op de MariaDB-backends staan; MaxScale wordt zelf geen database.

Deze scheiding is vooral handig wanneer een toepassing niet zelf hoeft te weten welke server op dat moment welke rol vervult. Voor basisinformatie over het gegevensmodel, SQL en het beheer van de database, zie het artikel MariaDB als open-source-database een geschikte aanvulling. De proxy vormt een aanvulling op de serverarchitectuur, maar vervangt noch de databaserechten, noch een concept voor replicatie en storingen.

Op Verbindingsroutering MaxScale kiest bij het opzetten van een sessie een doel; deze backend blijft verantwoordelijk voor de sessie. Bij statement-routing kan de router afzonderlijke SQL-instructies op basis van hun inhoud op verschillende manieren toewijzen. Welke variant geschikt is, hangt daarom af van transacties, de sessiestatus en het vermogen van de toepassing om lees- en schrijfpaden zelf netjes te scheiden.

A Database-proxy Dit is geen algemene prestatiegarantie. Het kan de routing centraliseren, rolwisselingen van applicaties ontkoppelen of geschikte leesverzoeken verdelen. Extra netwerkknooppunten, SQL-analyse en de concrete backend-topologie beïnvloeden het gedrag echter. De belastbaarheid en capaciteit moeten daarom worden getest met de eigen versie, configuratie en belasting.

De primary-replica-topologie correct monitoren

Een typische doelarchitectuur bestaat uit een schrijvende primaire server en een of meer lezende replica’s. MaxScale is het enige database-eindpunt van de applicatie, bijvoorbeeld achter een vaste DNS-naam. De applicatie maakt dus geen rechtstreekse verbinding met afzonderlijke hosts; de selectie van een bereikbare en geschikte backend vindt plaats binnen de proxylaag.

Voor een primary-replica-topologie bepaalt de monitor mariadbmon de status van de backends en identificeert hun rol als ‘Primary’ of ‘Replica’. Routers kunnen deze informatie gebruiken bij het kiezen van een bestemming. De monitor moet daarom de werkelijke replicatietopologie kunnen zien; onjuiste toewijzingen, niet-gerepliceerde gegevens of onduidelijke rollen zijn geen routeringsproblemen, maar operationele risico’s.

Het herkennen van een rol moet worden onderscheiden van het wijzigen ervan. Met de juiste configuratie en machtigingen kan mariadbmon failover, geplande switchover en rejoin beheren. Een switchover is een bewust voorbereide rolwisseling voor onderhoud of exploitatie; een failover is een reactie op een storing. Beide processen vereisen een eenduidige topologie, monitoring, alarmering en een gedocumenteerd incident- of herstelproces.

Voor louter toezichtstaken moet het monitoraccount volgens het principe Minste voorrecht alleen de benodigde rechten krijgen. In de huidige documentatie wordt hiervoor de term REPLICA MONITOR gebruikt. Afhankelijk van de geactiveerde functies zijn aanvullende rechten vereist, zoals FILE bij het controleren van de opslagruimte of andere specifiek gecontroleerde rechten voor topologiescans en clusterbewerkingen. Algemene volledige rechten zijn hiervoor geen vervanging.

Voordat er tot automatisering wordt overgegaan, moet het team vastleggen wie een rolwisseling goedkeurt, hoe de status van de replica’s wordt gecontroleerd en hoe applicaties op de hoogte worden gebracht van storingen. MaxScale kan routeringsdoelen aanpassen op basis van herkende rollen. Of een omschakeling technisch toegestaan is, wordt echter bepaald door het hoogbeschikbaarheidsconcept met zijn grenzen op het gebied van gegevens, tijd en verantwoordelijkheid.

Inzicht krijgen in SQL-routing en consistentiegrenzen

De router readwritesplit stuurt schrijfopdrachten in SQL door naar de primaire server en verdeelt geschikte leesverzoeken over de replica’s. Hierdoor kan een cluster van primaire en replica-servers zijn leescapaciteit gerichter benutten, zonder dat de applicatie elke query zelf aan een server hoeft toe te wijzen. De rolinformatie van de monitor vormt daarbij de basis voor de selectie.

Deze indeling garandeert in de standaardversie niet dat een leesbewerking direct na elke schrijfbewerking de nieuwe status ziet. causal_reads is standaard ingesteld op none. Als een applicatie bijvoorbeeld een bestelstatus schrijft en deze vervolgens via een onafhankelijke query opvraagt, kan een replica daarom nog steeds de vorige stand weergeven. Een bewust gekozen primair leespad of een gemeenschappelijke transactiecontext zijn mogelijke strategieën, maar niet de enige.

Voor Read-your-writes Met ‘readwritesplit’ en ingeschakelde ‘Causal Reads’ kan rekening worden gehouden met eerdere schrijfbewerkingen, ondanks de replicavergaging. De modus local zorgt ervoor dat dezelfde verbinding zichtbaar blijft. global houdt de door de service opgeslagen GTID-status bij voor al zijn verbindingen; een globale ‘happens-before’-volgorde van de leesbewerkingen wordt daarbij alleen gegarandeerd als alle transacties binnen één enkel GTID-domein vallen. universal houdt rekening met de transactiestatus van het cluster zoals die op de Primary waarneembaar is. De grotere toepassingsgebieden verhogen echter de synchronisatie-inspanning en daarmee mogelijk ook de latentie.

Causal Reads maken gebruik van GTID-informatie en wachten bij de niet-snelle modi op de replicatie. Duurt de synchronisatie langer dan causal_reads_timeout – standaard 10 seconden –, probeert readwritesplit de query op de primaire server uit te voeren. In een schrijfbeveiligde transactie kan in plaats daarvan een time-out als fout worden geretourneerd, omdat de query niet naar de primaire server mag worden verplaatst.

De snelle modi fast, fast_global en fast_universal wachten niet op een replica en maken indien nodig gebruik van de primaire server; de time-out geldt daar niet. Ze zijn daarom vooral geschikt voor workloads die voornamelijk uit leesbewerkingen bestaan, met weinig schrijfbewerkingen. Vanaf MaxScale 24.02 stelt MaxScale zelf de benodigde tracking voor nieuwe backend-verbindingen in; oudere versies hebben daarvoor last_gtid in session_track_system_variables op alle backends.

Binnen een open lees-schrijf-transactie leidt `readwritesplit` leesverzoeken door naar de primaire server. Dit voorkomt dat instructies van dezelfde transactie worden uitgevoerd op backends met een verschillende replicatiestatus. Deze conservatieve regel ontslaat u niet van de plicht om transactiegrenzen vakkundig in te stellen en replicatievertraging te behandelen als een afzonderlijke architecturale beperking.

Ook bij opgeslagen procedures, UDF-aanroepen en multi-statements wordt bewust voor een voorzichtiger aanpak gekozen: in gedocumenteerde gevallen worden dergelijke query’s naar de primaire database doorgestuurd. De reden hiervoor is dat het effect of de context ervan niet op dezelfde manier moet worden behandeld als een eenvoudige leesquery. SQL-routing is dus niet louter een zoekactie naar het woord SELECT, maar volgt regels voor een veilige afhandeling van sessies en semantiek.

Een op basis van vakkennis vastgestelde grenswaarde voor Replica-Lag kan replica’s van bepaalde leesbeslissingen uitsluiten, maar vervangt geen consistentie-eis. De aanvaardbare vertraging hangt bijvoorbeeld af van de vraag of een verouderde catalogusvermelding aanvaardbaar is of dat een zojuist bevestigde betalingsstatus absoluut zichtbaar moet zijn. Deze beslissing hoort thuis in de applicatielogica en de serviceovereenkomst, niet in een algemene proxy-standaardinstelling.

Readwritesplit veilig configureren

Een Read/Write-Split-configuratie bestaat uit afzonderlijke objectdefinities voor backends, monitor, service en listener. Het volgende fragment toont de structuur van een bestand; het is geen sjabloon dat direct in productie kan worden gebruikt. De waarden tussen puntige haakjes zijn uitdrukkelijk geen wachtwoorden, maar verwijzingen naar accounts en geheimen die via het geheimenbeheer van de productieomgeving moeten worden verstrekt. De monitor en de service hebben daarbij elk hun eigen toegangsgegevens nodig voor hun verschillende taken.

[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

De serverobjecten verwijzen uitsluitend naar bereikbare MariaDB-backends; de monitor bepaalt aan de hand van de topologie welke instantie de primaire en welke de replica is. Het monitoraccount wordt gebruikt voor het opvragen van statussen en rollen. Het afzonderlijke serviceaccount dient om de gebruikers- en rechteninformatie die nodig is voor clientauthenticatie en -autorisatie op te halen bij de backends. Beide accounts hebben alleen de rechten nodig die voor hun respectievelijke taak zijn gedocumenteerd. Rollen herkennen Het laden van gegevens en gebruikersinformatie zijn afzonderlijke taken.

De plaatshouders in het voorbeeld moeten bij de implementatie via een beveiligd implementatiekanaal worden vervangen; ze zijn niet bedoeld als letterlijke configuratiewaarden. Wachtwoorden in leesbare tekst, echte certificaatpaden of ongecontroleerde rechtenpakketten horen niet thuis in vrij toegankelijke bestanden of repositories. MaxScale beheert intern relevante gebruikersaccounts en rechten uit de systeemtabellen voor MariaDB-protocolverbindingen. Als accounts of rechten worden gewijzigd, kan verouderde informatie de aanmelding of autorisatie belemmeren.

Vóór de vrijgave moeten daarom de listener-poort, de netwerkpaden, de gebruikersafstemming en de daadwerkelijke routertoewijzing afzonderlijk worden gecontroleerd. Ook automatische ingrepen van de monitor maken niet impliciet deel uit van deze minimale opzet: failover-, switchover- of rejoin-functies vereisen aanvullende configuratie en een getest bedrijfsconcept. Een ogenschijnlijk korte configuratie is geen vervanging voor geheimbeheer noch voor de controle van de backend-topologie.

Routermodellen vergelijken op basis van toepassing

De keuze van de router hangt af van het gedrag van de toepassing, en niet alleen van het aantal beschikbare replica’s. Directe verbindingen houden de opbouw eenvoudig, maar laten het wisselen van bestemming en de kennis van de rol over aan de toepassing. Twee afzonderlijke eindpunten met readconnroute van toepassing zijn wanneer de toepassing bewust zelf lees- en schrijfverbindingen tot stand brengt. Statement-routing Het gebruik van `readwritesplit` is zinvol wanneer een sessie op basis van SQL naar de primaire server of naar replica's moet worden doorgestuurd.

readconnroute beoordeelt bij het tot stand brengen van de verbinding een doelserver en analyseert niet elke daaropvolgende SQL-instructie. Als de gekozen backend uitvalt, wordt de sessie beëindigd; de router verbindt u niet automatisch met een andere server. Dit is vaak begrijpelijk voor duidelijk gescheiden, kortstondige leesverbindingen, maar kan ongeschikt zijn voor toepassingen met veel statusinformatie.

Bijzondere voorzichtigheid is geboden bij een service die bedoeld is als lees-eindpunt met router_options=slave. De optie geeft de voorkeur aan servers met de rol van replica; als alle replica’s zijn uitgevallen en de primaire server beschikbaar is, kan readconnroute echter terugvallen op de primaire server. Bovendien zorgt de optie niet voor schrijfbeveiliging. De toepassing moet uitsluitend lees-SQL-opdrachten verzenden, of er moet een extra ReadOnly-filter worden gebruikt om schrijftoegang te blokkeren. De routeringsbestemming en rolvoorkeur vormen dus noch een autorisatiebeperking, noch een vervanging voor restrictieve databaserechten.

readwritesplit vermindert daarentegen het aantal beslissingen over de bestemming in de applicatiecode, maar vereist een nauwkeurige controle van de semantiek. Geschikte leesbewerkingen kunnen over replica’s worden verdeeld, terwijl schrijfbewerkingen naar de primaire server gaan. Voor processen met strenge eisen aan de actualiteit blijft het doorslaggevend of een query na een schrijfbewerking mag wachten op gerepliceerde gegevens of bewust de primaire server moet gebruiken.

Vergaderingen, voorraad en omschakeling plannen

Een databasesessie omvat meer dan alleen die ene query. SET, USE, CHANGE USER en Prepared Statement-bewerkingen veranderen hun context. readwritesplit repliceert relevante sessiecommando’s naar mogelijke doelservers, zodat later doorgestuurde statements met de juiste sessiestatus kunnen worden uitgevoerd. Dit onderscheidt de router van eenvoudige TCP-load-balancing, maar neemt niet alle beperkingen in speciale gevallen weg.

Bij prepared statements voor tijdelijke tabellen is deze limiet bijzonder belangrijk. Als een dergelijke statement op de primaire server wordt voorbereid, kunnen replica’s deze niet noodzakelijkerwijs uitvoeren. De applicatie moet daarom tijdelijke objecten, prepared statements en transacties testen met het daarvoor bestemde routingmodel. Toestand sessie is geen nevenvoorwaarde, maar bepaalt of een SQL-verdeling inhoudelijk en technisch geschikt is.

Voor een toepassing waarbij veel leesbewerkingen plaatsvinden, kan het team een technisch vastgestelde lag-drempelwaarde definiëren als uitsluitingscriterium voor replica’s. Alleen max_replication_lag garandeert echter niet dat een eerdere schrijfbewerking op een replica al zichtbaar is. Voor kritieke vervolglezingen kunnen, afhankelijk van het verloop, een bewuste primaire route, een gedeelde schrijfcontext of geactiveerde causale lezingen in aanmerking komen.

Bij causale lezingen moet het toepassingsgebied bewust worden gekozen. local behoudt de causaliteit binnen een verband. global maakt gebruik van een GTID-stand die voor de hele service wordt opgeslagen, maar garandeert de globale ‘happens-before’-volgorde van de leesbewerkingen alleen als alle transacties binnen één GTID-domein vallen. universal houdt rekening met de transactiestatus van het cluster zoals die op de primaire server waarneembaar is. Niet-snelle modi synchroniseren met GTID’s; als een replica niet binnen de geconfigureerde time-out wordt ingehaald, wordt de query in principe op de primaire server herhaald, voor zover de transactiemodus dit toestaat.

De functie moet per versie worden ingedeeld. Vanaf MaxScale 24.02 voegt MaxScale toe last_gtid voor nieuwe backend-verbindingen zelf; in oudere versies moest session_track_system_variables moeten op de MariaDB-backends dienovereenkomstig zijn ingesteld. De snelle modi voorkomen wachttijden, maar kunnen bij replica’s die nog niet zijn bijgewerkt het lezen naar de primaire server leiden en zijn daarom niet zonder meer geschikt voor schrijfintensieve werklasten.

Een geplande switchover en een automatische failover moeten eveneens apart worden behandeld. Bij een switchover wordt een rolwisseling op gecontroleerde wijze voorbereid, terwijl bij een failover het systeem reageert op een foutconditie. mariadbmon kan rollen en backend-statussen bewaken en kan, mits bewust geconfigureerd, deze processen ondersteunen. Een gerepliceerde gegevensstatus, een eenduidige topologie, alarmmeldingen en een incidentprocedure blijven daarbij vereisten.

In MaxScale 25.10 is het mogelijk om discover-replicas Servers herkennen die rechtstreeks naar de huidige primaire server repliceren, en deze toevoegen aan Monitor en MaxScale. Deze functie is niet compatibel met configuratiesynchronisatie. Voordat deze functie wordt gebruikt, moet het team daarom bepalen of topologiewijzigingen automatisch worden gedetecteerd of via een gesynchroniseerde configuratie worden geregeld; beide tegelijk is in dit kader geen toegestane aanname.

TLS, rechten en filters beveiligen

Bij MaxScale moet TLS over twee afzonderlijke verbindingen worden geconfigureerd: van de applicatie naar de listener en van de proxy naar de MariaDB-backends. Beide verbindingen vereisen eigen instellingen voor versleuteling en certificaatcontrole; een beveiligde clientverbinding versleutelt het daaropvolgende verkeer niet automatisch. De configuratie moet daarom rekening houden met de beveiligingsbehoeften en de vertrouwensketen voor beide delen.

TLS is ingeschakeld ssl=true de versleuteling in de betreffende listener- of serverconfiguratie. Als een client een servercertificaat verwacht, heeft de listener een certificaat en een privésleutel nodig. Een account met REQUIRE SSL kan zich niet aanmelden via een listener zonder TLS. Certificaatbestanden en sleutels horen thuis in een beveiligde productieomgeving, niet in vrij toegankelijke voorbeeld- of repository-configuraties.

Ook de Rechtenconcept Op de backends blijft het volgende van cruciaal belang: MaxScale regelt de verbindingen, maar vervangt geen specifieke databaseaccounts. Serviceaccounts krijgen alleen de rechten die nodig zijn voor hun taak. Voor het inloggen en autoriseren vertrouwt MaxScale op gebruikersaccounts en rechten uit de MariaDB-systeemtabellen; wijzigingen aan deze accounts moeten daarom tijdig beschikbaar zijn in het interne gebruikersbeheer.

Het firewallfilter kan SQL vóór het doorsturen controleren aan de hand van aangeleerde of gedefinieerde regels. Het beschikt over een rust-, leer-, bewakings- en afdwingingsmodus; in de afdwingingsmodus worden niet-toegestane statementpatronen, afhankelijk van de instelling, met een foutmelding beantwoord of wordt de verbinding verbroken. De leerfase moet representatieve, toegestane applicatiestromen omvatten, zodat het filter geen reguliere query's blokkeert.

Het filter is een extra controlaar voor verwachte SQL-patronen, geen vervanging voor toegangsrechten. Beperkende databaserechten, beveiligde inloggegevens en geteste applicatiecode blijven noodzakelijk, omdat het filter alleen de verzoeken die erin binnenkomen beoordeelt op basis van zijn regels. Uitspraken over andere filters moeten afzonderlijk worden getoetst aan de hand van de betreffende documentatie.

Configuratie en fouten systematisch controleren

Bij verbindings- of routeringsfouten helpt een vaste controlevolgorde in plaats van wijzigingen op goed geluk. Controleer eerst de monitorstatus: zijn alle backends bereikbaar en worden de primaire en replica-rollen zoals verwacht herkend? Pas dan kunnen routerbeslissingen zinvol worden beoordeeld. Een verkeerd herkend of onbereikbaar knooppunt is niet louter een listener-probleem.

Vervolgens komen de listener en TLS: de poort, het protocol, het certificaat, de sleutel en de vereisten van de gebruikte accounts moeten op elkaar aansluiten. Controleer vervolgens of het gebruikersaccountbeheer op de hoogte is van de actuele backend-accounts en rechten. Vooral na wijzigingen aan gebruikers of rechten kunnen verouderde accountgegevens aanmeldingen verhinderen, ook al is het account in MariaDB zelf correct ingesteld.

Vervolgens wijs je de service, de router en de daarvoor bestemde servers toe. Bij read/write-splitting moet je bovendien rekening houden met de replica-lag, causal_reads en de transactielimieten van de toepassing op de controlelijst. Zonder geactiveerde causale leesbewerkingen kan een leesbewerking buiten de vereiste schrijfcontext op een replica een oudere stand opleveren; een lag-drempelwaarde alleen garandeert niet de zichtbaarheid van een eerdere schrijfbewerking.

Zet er bovendien één Configuratiebron vast. MaxScale kan wijzigingen tijdens de uitvoering opslaan; bij het opnieuw opstarten kan de opgeslagen configuratie statische bestanden overschrijven. Als een team deels bestanden bewerkt en deels maxctrl Als deze wordt gebruikt, moeten het wijzigingstraject, de beoordeling en de back-up van deze runtime-configuratie verplicht worden gedocumenteerd.

Onderhoudsvensters voor schemawijzigingen behandel je als een apart werkgebied: afhankelijkheden, vergrendelingsgedrag en replicatie moeten vooraf worden gecontroleerd en mogen niet aan de proxy worden toegeschreven. Voor het plannen van gecontroleerde wijzigingen aan grote MariaDB-tabellen biedt het artikel over Schemawijzigingen zonder downtime aanvullende context. MaxScale kan vervolgens verbindingen en routing weer op basis van de backend-rollen regelen, maar voert geen DDL-strategie voor de database uit.

Waarschuwing: Wijzigingen aan rollen, certificaten, gebruikersrechten en routing moet je eerst in een vergelijkbare omgeving testen. Bij een ingreep in de productieve omgeving horen een terugzetprocedure, het monitoren van applicatiefouten en duidelijke verantwoordelijkheden. Zo blijft het duidelijk of een storing voortkomt uit de proxyconfiguratie, de backend of het gedrag van de client.

MaxScale op de juiste manier gebruiken of weglaten

Bij een enkele MariaDB-server zonder vereisten op het gebied van routing, omschakeling of SQL-filters zijn directe verbindingen meestal de eenvoudigste manier van werken. De applicatie moet dan echter zelf zorgen voor een latere doelwijziging. MaxScale is de moeite waard als het extra eindpunt een specifieke taak vervult, zoals het opvangen van rolwisselingen, het filteren van verzoeken of het gecontroleerd verdelen van leesbewerkingen over replica's.

Als de toepassing zelf bewust lees- en schrijfpaden kan kiezen, zijn afzonderlijke eindpunten met readconnroute vaak begrijpelijk. Deze router kiest bij het tot stand brengen van de verbinding een backend, analyseert echter niet elke SQL-opdracht en verplaatst een onderbroken sessie niet naar een andere server. Bij router_options=slave Er wordt de voorkeur gegeven aan replica's; als alle replica's zijn uitgevallen en de primaire server nog beschikbaar is, kan de router de primaire server gebruiken. Deze optie maakt het eindpunt bovendien niet schrijfbeveiligd. Hiervoor zijn een geschikt ReadOnly-filter, restrictieve backend-rechten of strikt gecontroleerde applicatie-SQL nodig.

Voor Primary-Replica-workloads waarvan de ORM en het transactiemodel hiervoor geschikt zijn, geldt readwritesplit de toepassing bepaalt de SQL-bestemming per instructie. Bij de standaardinstelling causal_reads=none blijft er echter een replicatievertraging zichtbaar. Na kritieke schrijfbewerkingen kan de toepassing gebruikmaken van een primair leespad of een geschikte gemeenschappelijke transactiecontext; als alternatief kunnen causale leesbewerkingen gericht worden geconfigureerd voor het vereiste zichtbaarheidsbereik.

Causal Reads maken onderscheid tussen zichtbaarheid binnen dezelfde sessie, een door de service bijgehouden globale GTID-status en de toestand van het cluster zoals die op de primaire server waarneembaar is. local geldt voor dezelfde verbinding. Bij global De globale 'happens-before'-volgorde van de leesbewerkingen is alleen gegarandeerd als alle transacties tot één enkel GTID-domein behoren; de modus mag daarom niet zonder meer worden opgevat als een onbeperkte garantie voor consistentie op serviceniveau. universal controleert vóór leesbewerkingen de waarneembare status op de primaire server. De synchronisatiemodi kunnen extra wachttijd veroorzaken; snelle varianten wachten niet, maar kunnen bij schrijfbewerkingen de belasting sterker naar de primaire server verschuiven.

Grensgevallen moeten vóór de implementatie gericht worden getest met de daadwerkelijke driver en het gegevensmodel. Tijdelijke tabellen en daarop afgestemde statements zijn mogelijk niet beschikbaar op replica's als de voorbereiding op de primaire server plaatsvindt. Ook opgeslagen procedures, UDF-aanroepen, multi-statements en de sessiestatus beïnvloeden of de router conservatief naar de primaire server routeert.

Transaction Replay is geen garantie voor transacties zonder verlies. Als een verbinding wordt verbroken tijdens COMMIT kan in het midden worden gelaten of de commit al succesvol was. Risicovolle replay-configuraties kunnen schrijfbewerkingen dubbel uitvoeren; serverafhankelijke resultaten zoals NOW() of @@server_id kunnen bovendien afwijkingen in de controlesom veroorzaken. Beoordeel het gebruik daarom op basis van de vereiste consistentie, foutpatronen en de herhaalbaarheid van de schrijfbewerkingen, en niet op basis van algemene prestatiebeloften.