Nur-Lese-Wartungsmodus: Lesezugriffe bedienen, während Schreibzugriffe pausiert sind

Worum es geht

Ein Nur-Lese-Wartungsmodus ist ein bewusst herbeigeführter Dienstzustand, in dem Lesezugriffe gelingen und jeder Schreibpfad eine temporäre, klar gekennzeichnete Ablehnung liefert. Er wird auf zwei Ebenen durchgesetzt: Die Anwendung prüft vor jedem Schreibzugriff ein Flag und zeigt ein Banner, und die Datenbank lehnt Schreibzugriffe als Rückfallebene ab. Die PostgreSQL-Dokumentation beschreibt default_transaction_read_only, welches den standardmässigen Nur-Lese-Status jeder neuen Transaktion steuert, und hält fest, dass eine schreibgeschützte SQL-Transaktion keine nicht-temporären Tabellen ändern kann. Für HTTP definiert RFC 9110 den Status 503 (Service Unavailable) für einen Server, der Anfragen vorübergehend nicht bearbeiten kann, einschliesslich geplanter Wartung, und hält fest, dass ein mit 503 gesendetes Retry-After angibt, wie lange der Dienst für den Client voraussichtlich nicht verfügbar sein wird.

Warum es wichtig ist

Die meisten Wartungsarbeiten betreffen Schreibzugriffe: Speicher umziehen, eine Replika befördern, eine lange Migration durchführen. Lesezugriffe funktionieren dabei oft durchgehend. Eine vollständige Ausfallseite für einen zweistündigen Speicherumzug verschenkt Verfügbarkeit, die vorhanden gewesen wäre, während ein unbeschrifteter Fehler ("etwas ist schiefgelaufen") während desselben Umzugs Support-Last und blinde Wiederholungsversuche erzeugt.

So wird es angewendet

• Einen Schalter ergänzen (Konfigurations-Flag, Feature-Toggle oder Umgebungsvariable), den die Anwendung am Anfang jedes Schreibpfads liest. Der Schalter ist massgeblich; die Datenbankeinstellung ist das Sicherheitsnetz.
• Eine einheitliche Ablehnung liefern: HTTP 503 mit Retry-After und einem maschinenlesbaren Rumpf, der die Wartung benennt, dazu ein sichtbares Banner in der Oberfläche. Wohlverhaltene Clients warten dann; wartende Jobs in Warteschlangen sollten pausieren statt fehlzuschlagen.
• default_transaction_read_only = on setzen, oder die Anwendung für das Zeitfenster auf eine Lese-Replika richten, damit ein vergessener Schreibpfad an der Datenbank scheitert, statt die Migration zu beschädigen.
• Hintergrund-Schreiber explizit pausieren: Scheduler, Queue-Consumer, Webhook-Empfänger, die persistieren.
• In Staging proben: Schalter umlegen, die Schreibtests ausführen und 503 erwarten, zurückschalten und Erfolg erwarten. Beide Umschaltungen zeitlich messen.
• Das Zeitfenster mit der erwarteten Auswirkung auf der Statusseite ankündigen ("Sie können stöbern, aber nicht speichern").

Stolpersteine

In Lesezugriffen versteckte Schreibzugriffe (Zeitstempel des letzten Zugriffs, Ansichtszähler, Session-Auffrischungen), die fehlschlagen und das Rendern der Seite kaputt machen. Caches, die die Fehlerantworten des Modus gespeichert haben. Vergessen, die Datenbankeinstellung nach dem Zeitfenster zurückzusetzen – weshalb der Schalter an einer Stelle lebt und die Checkliste mit "Schreibzugriffe prüfen" endet.

Das Zeitfenster aus Health-Checks und Fehlerbudgets heraushalten

Ein 503 auf Schreibpfaden ist für Clients korrekt und für alles, was den Dienst beobachtet, irreführend. Vor der ersten Generalprobe drei Änderungen mit dem Schalter vornehmen: Health-Endpunkte, die von Load-Balancern und Orchestratoren genutzt werden, dürfen keinen Schreibpfad ausüben oder müssen den Nur-Lese-Zustand als gesund behandeln, damit Instanzen in Rotation bleiben; Wartungsablehnungen tragen eine Kennzeichnung (einen Antwort-Header oder einen eigenen Problem-Type-Rumpf), die das Fehlerraten-SLO und die Alarmierungsregeln ausschliessen und die Dashboards als eigene Serie anzeigen; und Retry-After wird auf das erwartete verbleibende Zeitfenster gesetzt statt auf wenige Sekunden, damit erneut anfragende Clients warten statt zu pollen. Alle drei Punkte in Staging verifizieren, indem während der Generalprobe der Zielzustand des Load-Balancers und das Fehlerraten-Panel beobachtet werden, nicht nur die HTTP-Antworten.