MariaDB MaxScale als Datenbank-Proxy einsetzen

MaxScale als Proxy-Schicht einordnen

MariaDB MaxScale ist eine eigenständige Proxy-Schicht zwischen Anwendung und MariaDB-Servern. Für einen belastbaren Betrieb müssen Konfiguration, verfügbare Funktionen und bekannte Grenzen stets zur tatsächlich installierten Version passen. Die Serie MaxScale 25.10 ist in der offiziellen Dokumentation mit eigenen Release Notes geführt.

Die Anwendung verbindet sich mit einem Listener von MaxScale statt unmittelbar mit einem Datenbankserver. Ein Dienst fasst dabei die Zugriffslogik zusammen, ein Router bestimmt das Backend, und Filter können Anfragen vor der Weiterleitung zusätzlich verarbeiten. Die Daten bleiben auf den MariaDB-Backends; MaxScale wird nicht selbst zur Datenbank.

Diese Trennung ist besonders hilfreich, wenn eine Anwendung nicht selbst wissen soll, welcher Server aktuell welche Rolle besitzt. Für Grundlagen zu Datenmodell, SQL und dem Betrieb der Datenbank ist der Beitrag MariaDB als Open-Source-Datenbank eine passende Ergänzung. Der Proxy ergänzt die Serverarchitektur, ersetzt aber weder Datenbankrechte noch ein Konzept für Replikation und Ausfälle.

Beim Verbindungs-Routing wählt MaxScale beim Aufbau einer Sitzung ein Ziel; dieses Backend bleibt für die Sitzung zuständig. Beim Statement-Routing kann der Router einzelne SQL-Anweisungen anhand ihres Inhalts unterschiedlich zuordnen. Welche Variante passt, hängt deshalb von Transaktionen, Sitzungszustand und der Fähigkeit der Anwendung ab, Lese- und Schreibpfade selbst sauber zu trennen.

Ein Database Proxy ist keine pauschale Leistungszusage. Er kann Routing zentralisieren, Rollenwechsel von Anwendungen entkoppeln oder geeignete Leseanfragen verteilen. Zusätzliche Netzwerkknoten, SQL-Analyse und die konkrete Backend-Topologie beeinflussen jedoch das Verhalten. Belastbarkeit und Kapazität müssen daher mit der eigenen Version, Konfiguration und Last geprüft werden.

Primary-Replica-Topologie richtig überwachen

Eine typische Zielarchitektur besteht aus einem schreibenden Primary und einer oder mehreren lesenden Replicas. MaxScale ist der einzige Datenbank-Endpunkt der Anwendung, etwa hinter einem festen DNS-Namen. Die Anwendung verbindet sich folglich nicht direkt mit einzelnen Hosts; die Auswahl eines erreichbaren und passenden Backends findet innerhalb der Proxy-Schicht statt.

Für eine Primary-Replica-Topologie ermittelt der Monitor mariadbmon den Zustand der Backends und erkennt ihre Rollen als Primary oder Replica. Router können diese Informationen für ihre Zielauswahl verwenden. Der Monitor muss daher die reale Replikationstopologie sehen können; falsche Zuordnungen, nicht replizierte Daten oder unklare Rollen sind keine Routingprobleme, sondern Betriebsrisiken.

Das Erkennen einer Rolle ist von ihrer Veränderung zu trennen. Mit passender Konfiguration und Berechtigung kann mariadbmon Failover, geplante Switchover und Rejoin verwalten. Ein Switchover ist ein bewusst vorbereiteter Rollenwechsel für Wartung oder Betrieb; ein Failover reagiert auf einen Fehler. Beide Vorgänge verlangen eindeutige Topologie, Überwachung, Alarmierung und einen dokumentierten Incident- oder Rückkehrprozess.

Für reine Überwachungsaufgaben sollte das Monitor-Konto nach dem Prinzip Least Privilege nur die benötigten Rechte erhalten. Die aktuelle Dokumentation nennt dafür REPLICA MONITOR. Zusätzliche Rechte sind abhängig von aktivierten Funktionen erforderlich, etwa FILE bei einer Prüfung des Speicherplatzes oder weitere gezielt geprüfte Rechte für Topologiescans und Cluster-Manipulationen. Pauschale Vollrechte sind dafür kein Ersatz.

Vor einer Automatisierung sollte das Team festlegen, wer einen Rollenwechsel freigibt, wie der Zustand der Replicas geprüft wird und wie Anwendungen über Störungen informiert werden. MaxScale kann Routingziele anhand erkannter Rollen anpassen. Ob eine Umschaltung fachlich zulässig ist, entscheidet aber das Hochverfügbarkeitskonzept mit seinen Daten-, Zeit- und Verantwortungsgrenzen.

SQL-Routing und Konsistenzgrenzen verstehen

Der Router readwritesplit leitet schreibende SQL-Anweisungen zum Primary und verteilt geeignete Leseanfragen auf Replicas. Damit kann ein Primary-Replica-Verbund seine Lesekapazität gezielter nutzen, ohne dass die Anwendung jede Abfrage selbst einem Server zuordnen muss. Die Rolleninformation des Monitors bildet dabei die Grundlage für die Auswahl.

Diese Aufteilung garantiert im Standard nicht, dass ein Read direkt nach jedem Write den neuen Stand sieht. causal_reads steht standardmäßig auf none. Schreibt eine Anwendung beispielsweise einen Bestellstatus und liest ihn anschließend über eine unabhängige Abfrage, kann eine Replica daher noch den vorherigen Stand liefern. Ein bewusst gewählter Primary-Lesepfad oder ein gemeinsamer Transaktionskontext sind mögliche Strategien, aber nicht die einzigen.

Für Read-your-writes kann readwritesplit mit aktivierten Causal Reads vorausgehende Writes trotz Replica-Lag berücksichtigen. Der Modus local sichert die Sichtbarkeit für dieselbe Verbindung. global führt den vom Service gespeicherten GTID-Stand über seine Verbindungen hinweg; eine globale Happens-before-Ordnung der Reads ist dabei nur garantiert, wenn alle Transaktionen innerhalb einer einzigen GTID-Domäne liegen. universal bezieht den am Primary beobachtbaren Transaktionsstand des Clusters ein. Die stärkeren Geltungsbereiche erhöhen jedoch den Synchronisations- und damit potenziell den Latenzaufwand.

Causal Reads arbeiten mit GTID-Informationen und warten bei den nicht schnellen Modi auf die Replikation. Läuft die Synchronisation länger als causal_reads_timeout – standardmäßig 10 Sekunden –, versucht readwritesplit die Abfrage auf dem Primary auszuführen. In einer schreibgeschützten Transaktion kann ein Timeout stattdessen als Fehler zurückkehren, weil die Abfrage nicht auf den Primary verschoben werden darf.

Die schnellen Modi fast, fast_global und fast_universal warten nicht auf eine Replica und verwenden bei Bedarf den Primary; der Timeout gilt dort nicht. Sie passen deshalb vor allem zu überwiegend lesenden Workloads mit wenigen Writes. Ab MaxScale 24.02 richtet MaxScale das erforderliche Tracking für neue Backend-Verbindungen selbst ein; ältere Versionen benötigen dafür last_gtid in session_track_system_variables auf allen Backends.

Innerhalb einer offenen Read-Write-Transaktion leitet readwritesplit Lesezugriffe an den Primary. Das vermeidet, dass Anweisungen derselben Transaktion auf Backends mit unterschiedlichem Replikationsstand ausgeführt werden. Diese konservative Regel entbindet nicht davon, Transaktionsgrenzen fachlich korrekt zu setzen und Replikationsverzug als eigene Architekturgrenze zu behandeln.

Auch bei Stored Procedures, UDF-Aufrufen und Multi-Statements fällt die Entscheidung bewusst vorsichtiger aus: In dokumentierten Fällen werden solche Anfragen zum Primary geleitet. Der Grund ist, dass ihre Wirkung oder ihr Kontext nicht wie eine einfache Leseabfrage behandelt werden sollte. SQL-Routing ist damit keine bloße Suche nach dem Wort SELECT, sondern folgt Regeln zur sicheren Sitzungs- und Semantikbehandlung.

Ein fachlich gewählter Grenzwert für Replica-Lag kann Replicas von bestimmten Leseentscheidungen ausschließen, ersetzt aber keine Konsistenzanforderung. Der akzeptable Rückstand hängt etwa davon ab, ob ein veralteter Katalogeintrag tolerierbar ist oder ob ein gerade bestätigter Zahlungsstatus zwingend sichtbar sein muss. Diese Entscheidung gehört in die Anwendungslogik und den Betriebsvertrag, nicht in eine allgemeine Proxy-Voreinstellung.

Readwritesplit sicher konfigurieren

Eine Read/Write-Split-Konfiguration besteht aus getrennten Objektdefinitionen für Backends, Monitor, Service und Listener. Der folgende Ausschnitt zeigt die Struktur einer Datei, nicht eine unmittelbar produktionsfähige Vorlage. Die Werte in spitzen Klammern sind ausdrücklich keine Kennwörter, sondern Verweise auf Konten und Geheimnisse, die über die Secret-Verwaltung des Betriebsumfelds bereitzustellen sind. Monitor und Service benötigen dabei jeweils eigene Zugangsdaten für ihre unterschiedlichen Aufgaben.

[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

Die Serverobjekte bezeichnen lediglich erreichbare MariaDB-Backends; welche Instanz Primary oder Replica ist, ermittelt der Monitor anhand der Topologie. Das Monitor-Konto wird für die Status- und Rollenabfragen verwendet. Das getrennte Servicekonto dient dazu, die für Client-Authentifizierung und Autorisierung benötigten Benutzer- und Rechteinformationen von den Backends abzurufen. Beide Konten benötigen nur die für ihre jeweilige Aufgabe dokumentierten Rechte. Rollen erkennen und Benutzerinformationen laden sind getrennte Aufgaben.

Die Platzhalter im Beispiel müssen beim Deployment durch einen geschützten Bereitstellungsweg aufgelöst werden; sie sind nicht als wörtliche Konfigurationswerte gedacht. Nicht in frei lesbare Dateien oder Repositorys gehören Klartextpasswörter, reale Zertifikatspfade oder ungeprüfte Rechtepakete. MaxScale verwaltet für MariaDB-Protokollverbindungen intern relevante Benutzerkonten und Berechtigungen aus den Systemtabellen. Werden Konten oder Rechte geändert, können veraltete Informationen die Anmeldung oder Autorisierung beeinträchtigen.

Vor der Freigabe sind deshalb Listener-Port, Netzwerkpfade, Benutzerabgleich und die tatsächliche Routerzuordnung getrennt zu prüfen. Auch automatische Eingriffe des Monitors gehören nicht implizit in diesen Minimalaufbau: Failover-, Switchover- oder Rejoin-Funktionen verlangen zusätzliche Konfiguration und ein getestetes Betriebskonzept. Eine scheinbar kurze Konfiguration ersetzt weder Secret-Management noch die Prüfung der Backend-Topologie.

Routermodelle nach Anwendung vergleichen

Die Routerwahl folgt dem Verhalten der Anwendung, nicht allein der Zahl vorhandener Replicas. Direkte Verbindungen halten den Aufbau einfach, überlassen aber Zielwechsel und Rollenkenntnis der Anwendung. Zwei getrennte Endpunkte mit readconnroute passen, wenn die Anwendung Lese- und Schreibverbindungen bewusst selbst führt. Statement-Routing mit readwritesplit ist sinnvoll, wenn eine Sitzung SQL-abhängig zum Primary oder zu Replicas geleitet werden soll.

readconnroute bewertet beim Verbindungsaufbau einen Zielserver und analysiert nicht jedes folgende SQL-Statement. Fällt das gewählte Backend aus, endet die Sitzung; der Router verbindet sie nicht automatisch mit einem anderen Server. Das ist für klar getrennte, kurzlebige Leseverbindungen oft nachvollziehbar, kann aber für zustandsreiche Anwendungsabläufe ungeeignet sein.

Besondere Vorsicht gilt einem als Read-Endpunkt gedachten Service mit router_options=slave. Die Option bevorzugt Server mit Replica-Rolle; sind alle Replicas ausgefallen und ist der Primary verfügbar, kann readconnroute jedoch auf den Primary zurückfallen. Zudem erzeugt die Option keinen Schreibschutz. Die Anwendung muss ausschließlich lesendes SQL senden, oder ein zusätzlicher ReadOnly-Filter muss Schreibzugriffe unterbinden. Routingziel und Rollenpräferenz sind damit weder eine Berechtigungsgrenze noch ein Ersatz für restriktive Datenbankrechte.

readwritesplit reduziert dagegen die Zielentscheidungen im Anwendungscode, verlangt aber eine präzise Prüfung der Semantik. Geeignete Reads können auf Replicas verteilt werden, während Schreiboperationen zum Primary gehen. Für Abläufe mit strengen Aktualitätsanforderungen bleibt entscheidend, ob eine Abfrage nach einem Write auf replizierte Daten warten darf oder bewusst den Primary verwenden muss.

Sitzungen, Lag und Umstellung planen

Eine Datenbanksitzung enthält mehr als die einzelne Abfrage. SET, USE, CHANGE USER und Prepared-Statement-Operationen verändern ihren Kontext. readwritesplit repliziert relevante Sitzungsbefehle auf mögliche Zielserver, damit später geroutete Statements mit passendem Sitzungszustand ausgeführt werden können. Das unterscheidet den Router von einfachem TCP-Load-Balancing, beseitigt jedoch nicht jede Spezialfallgrenze.

Bei Prepared Statements für temporäre Tabellen ist diese Grenze besonders wichtig. Wird ein solches Statement auf dem Primary vorbereitet, können Replicas es nicht zwangsläufig ausführen. Die Anwendung sollte temporäre Objekte, Prepared Statements und Transaktionsabläufe deshalb mit dem vorgesehenen Routingmodell erproben. Session-Zustand ist keine Nebenbedingung, sondern bestimmt, ob eine SQL-Verteilung fachlich und technisch passt.

Für eine leselastige Anwendung kann das Team einen fachlich festgelegten Lag-Grenzwert als Ausschlusskriterium für Replicas definieren. Allein max_replication_lag stellt jedoch nicht sicher, dass ein vorheriger Write auf einer Replica bereits sichtbar ist. Für kritische Folge-Reads kommen je nach Ablauf ein bewusster Primary-Pfad, ein gemeinsamer Schreibkontext oder aktivierte Causal Reads in Betracht.

Bei Causal Reads ist der Geltungsbereich bewusst zu wählen. local wahrt die Kausalität innerhalb einer Verbindung. global verwendet einen serviceweit gespeicherten GTID-Stand, garantiert die globale Happens-before-Ordnung der Reads aber nur, wenn sämtliche Transaktionen in einer einzigen GTID-Domäne liegen. universal berücksichtigt den am Primary beobachtbaren Transaktionsstand des Clusters. Nicht schnelle Modi synchronisieren mit GTIDs; holt eine Replica nicht innerhalb des konfigurierten Timeouts auf, wird die Abfrage grundsätzlich auf dem Primary wiederholt, soweit der Transaktionsmodus dies zulässt.

Die Funktion ist versionsabhängig einzuordnen. Ab MaxScale 24.02 ergänzt MaxScale last_gtid für neue Backend-Verbindungen selbst; in älteren Versionen musste session_track_system_variables auf den MariaDB-Backends entsprechend gesetzt sein. Die schnellen Modi vermeiden das Warten, können bei noch nicht aufgeholten Replicas aber Reads zum Primary lenken und eignen sich daher nicht pauschal für schreibintensive Lasten.

Ein geplanter Switchover und ein automatisches Failover sind ebenfalls getrennt zu behandeln. Beim Switchover wird ein Rollenwechsel kontrolliert vorbereitet, bei einem Failover reagiert der Betrieb auf einen Fehlerzustand. mariadbmon kann Rollen und Backend-Zustände überwachen und kann, sofern bewusst eingerichtet, diese Abläufe unterstützen. Replizierter Datenstand, eindeutige Topologie, Alarmierung und ein Incident-Prozess bleiben dabei Voraussetzungen.

In MaxScale 25.10 kann discover-replicas Server erkennen, die direkt am aktuellen Primary replizieren, und sie zu Monitor und MaxScale hinzufügen. Diese Funktion ist nicht mit Konfigurationssynchronisierung kompatibel. Vor ihrem Einsatz muss das Team daher festlegen, ob Topologieänderungen automatisch entdeckt oder über eine synchronisierte Konfiguration gesteuert werden; beides zugleich ist in diesem Rahmen keine zulässige Annahme.

TLS, Rechte und Filter absichern

TLS ist bei MaxScale auf zwei getrennten Strecken zu planen: von der Anwendung zum Listener und vom Proxy zu den MariaDB-Backends. Beide Verbindungen brauchen eigene Vorgaben für Verschlüsselung und Zertifikatsprüfung; eine abgesicherte Client-Strecke verschlüsselt nicht automatisch den nachgelagerten Verkehr. Die Konfiguration muss deshalb den Schutzbedarf und die Vertrauenskette für beide Abschnitte abbilden.

Für TLS aktiviert ssl=true die Verschlüsselung in der jeweiligen Listener- oder Server-Konfiguration. Erwartet ein Client ein Serverzertifikat, benötigt der Listener Zertifikat und privaten Schlüssel. Ein Konto mit REQUIRE SSL kann sich nicht über einen Listener ohne TLS anmelden. Zertifikatsdateien und Schlüssel gehören in eine geschützte Betriebsumgebung, nicht in frei lesbare Beispiel- oder Repository-Konfigurationen.

Auch das Rechtekonzept bleibt auf den Backends maßgeblich: MaxScale vermittelt Verbindungen, ersetzt aber keine präzisen Datenbankkonten. Servicekonten erhalten nur die Berechtigungen, die ihre Aufgabe erfordert. Für die Anmeldung und Autorisierung stützt sich MaxScale auf Benutzerkonten und Rechte aus den MariaDB-Systemtabellen; Änderungen an diesen Konten müssen daher in der internen Benutzerverwaltung zeitnah verfügbar sein.

Der Firewall-Filter kann SQL vor dem Weiterleiten anhand gelernter oder definierter Regeln prüfen. Er kennt Leerlauf-, Lern-, Überwachungs- und Erzwingungsmodi; im Erzwingungsmodus werden nicht erlaubte Statement-Muster je nach Einstellung mit einem Fehler beantwortet oder die Verbindung wird getrennt. Die Lernphase muss repräsentative, erlaubte Anwendungsabläufe abdecken, damit der Filter nicht reguläre Queries blockiert.

Der Filter ist eine zusätzliche Kontrollschicht für erwartete SQL-Muster, keine Ersatzberechtigung. Restriktive Datenbankrechte, geschützte Zugangsdaten und geprüfter Anwendungscode bleiben erforderlich, weil der Filter nur die vor ihm eingehenden Anfragen anhand seiner Regeln bewertet. Aussagen über andere Filter sollten getrennt anhand ihrer jeweiligen Dokumentation geprüft werden.

Konfiguration und Fehler systematisch prüfen

Bei Verbindungs- oder Routingfehlern hilft eine feste Prüfreihenfolge statt Änderungen auf Verdacht. Prüfe zuerst den Monitorstatus: Sind alle Backends erreichbar, und sind Primary- und Replica-Rollen erwartungsgemäß erkannt? Erst dann lassen sich Routerentscheidungen sinnvoll beurteilen. Ein falsch erkannter oder nicht erreichbarer Knoten ist kein reines Listener-Problem.

Danach folgen Listener und TLS: Port, Protokoll, Zertifikat, Schlüssel und die Anforderungen der verwendeten Konten müssen zusammenpassen. Prüfe anschließend, ob die Benutzerkontenverwaltung aktuelle Backend-Konten und Rechte kennt. Besonders nach Änderungen an Nutzern oder Berechtigungen können veraltete Kontendaten Anmeldungen verhindern, obwohl das Konto auf MariaDB selbst korrekt eingerichtet ist.

Als Nächstes ordnest du Service, Router und die vorgesehenen Server zu. Bei Read/Write Splitting gehören außerdem Replica-Lag, causal_reads und die Transaktionsgrenzen der Anwendung auf die Prüfliste. Ohne aktivierte Causal Reads kann ein Read außerhalb des erforderlichen Schreibkontexts auf einer Replica einen älteren Stand liefern; ein Lag-Grenzwert allein garantiert die Sichtbarkeit eines vorherigen Writes nicht.

Lege außerdem eine einzige Konfigurationsquelle fest. MaxScale kann Änderungen zur Laufzeit persistieren; beim Neustart kann die persistierte Konfiguration statische Dateien überlagern. Wenn ein Team teils Dateien bearbeitet und teils maxctrl verwendet, müssen Änderungsweg, Review und Sicherung dieser Laufzeitkonfiguration verbindlich dokumentiert sein.

Wartungsfenster für Schemaänderungen behandelst du als eigenes Betriebsfeld: Abhängigkeiten, Sperrverhalten und Replikation sind vorab zu prüfen, nicht dem Proxy zuzuschreiben. Für die Planung kontrollierter Änderungen an großen MariaDB-Tabellen bietet der Beitrag zu Schemaänderungen ohne Downtime ergänzenden Kontext. MaxScale kann danach Verbindungen und Routing wieder anhand der Backend-Rollen steuern, führt aber keine Datenbank-DDL-Strategie aus.

Warnung: Änderungen an Rollen, Zertifikaten, Benutzerrechten und Routing solltest du zuerst in einer vergleichbaren Umgebung nachvollziehen. Für den produktiven Eingriff gehören Rücksetzweg, Beobachtung der Anwendungsfehler und klare Zuständigkeiten dazu. So bleibt unterscheidbar, ob eine Störung aus der Proxy-Konfiguration, dem Backend oder dem Client-Verhalten stammt.

MaxScale passend einsetzen oder weglassen

Bei einem einzelnen MariaDB-Server ohne Anforderungen an Routing, Umschaltung oder SQL-Filter sind direkte Verbindungen meist die einfachere Betriebsform. Die Anwendung muss dann allerdings einen späteren Zielwechsel selbst handhaben. MaxScale lohnt sich, wenn der zusätzliche Endpunkt eine konkrete Aufgabe erfüllt, etwa Rollenwechsel abzufangen, Zugriffe zu filtern oder Reads kontrolliert auf Replicas zu verteilen.

Kann die Anwendung Lese- und Schreibpfade bewusst selbst wählen, sind getrennte Endpunkte mit readconnroute oft nachvollziehbar. Dieser Router wählt beim Verbindungsaufbau ein Backend, analysiert jedoch nicht jedes SQL-Statement und zieht eine unterbrochene Sitzung nicht auf einen anderen Server um. Bei router_options=slave werden Replicas bevorzugt; sind alle Replicas ausgefallen und ist der Primary noch verfügbar, kann der Router den Primary verwenden. Die Option macht den Endpunkt außerdem nicht schreibgeschützt. Dafür sind ein geeigneter ReadOnly-Filter, restriktive Backend-Rechte oder strikt kontrolliertes Anwendungs-SQL nötig.

Für Primary-Replica-Workloads, deren ORM und Transaktionsmodell dazu passen, nimmt readwritesplit der Anwendung die SQL-Zielwahl pro Statement ab. Bei der Standardvorgabe causal_reads=none bleibt Replikationsverzug jedoch sichtbar. Nach kritischen Writes kann die Anwendung einen Primary-Lesepfad oder einen passenden gemeinsamen Transaktionskontext verwenden; alternativ lassen sich Causal Reads gezielt für den benötigten Sichtbarkeitsbereich konfigurieren.

Causal Reads unterscheiden zwischen Sichtbarkeit innerhalb derselben Sitzung, einem vom Service geführten globalen GTID-Stand und dem am Primary beobachtbaren Zustand des Clusters. local gilt für dieselbe Verbindung. Bei global ist die globale Happens-before-Ordnung der Reads nur garantiert, wenn alle Transaktionen einer einzigen GTID-Domäne angehören; der Modus darf daher nicht pauschal als uneingeschränkte serviceweite Konsistenzgarantie verstanden werden. universal prüft vor Reads den beobachtbaren Stand am Primary. Die synchronisierenden Modi können zusätzliche Wartezeit erzeugen; schnelle Varianten warten nicht, können aber bei Writes die Last stärker zum Primary verschieben.

Grenzfälle verdienen vor der Einführung gezielte Tests mit dem realen Treiber und Datenmodell. Temporäre Tabellen und darauf vorbereitete Statements können auf Replicas nicht verfügbar sein, wenn die Vorbereitung am Primary erfolgt. Auch Stored Procedures, UDF-Aufrufe, Multi-Statements und Sitzungszustand beeinflussen, ob der Router konservativ zum Primary routet.

Transaction Replay ist keine Zusage für verlustfreie Transaktionen. Bricht eine Verbindung während COMMIT ab, kann offenbleiben, ob das Commit bereits erfolgreich war. Riskante Replay-Konfigurationen können Schreiboperationen doppelt ausführen; serverabhängige Ergebnisse wie NOW() oder @@server_id können zudem Prüfsummenabweichungen auslösen. Beurteile den Einsatz daher anhand von Konsistenzbedarf, Fehlerabläufen und Wiederholbarkeit der Writes, nicht anhand pauschaler Leistungsversprechen.