Datenbankbetrieb

Der Datenbankbetrieb verbindet den Zustand der Engine mit der Infrastruktur, die die Engine nutzbar macht: Verfügbarkeit des Storage Nodes, Speicher, Binding-Verbindungen, Konnektivität der Workloads und Zugriffsidentität. Überwachen Sie alle diese Ebenen, bevor Sie eine fehlgeschlagene Anwendungsabfrage als Vorfall der Engine behandeln.

Schützen Sie zuerst die Daten und stellen Sie dann den Client-Pfad mit der kleinsten funktionierenden Änderung wieder her. Eine Wiederherstellung ist abgeschlossen, wenn der ursprüngliche Client-Pfad funktioniert, die Ursache bekannt ist, die Belege aufbewahrt werden und jeder vorübergehende Zugriff und jede vorübergehende Offenlegung entfernt ist.

Einigen Sie sich auf Recovery Point Objective (RPO), Recovery Time Objective (RTO), Zuständigkeit für Eskalationen und Wiederherstellungsnachweise, bevor die Datenbank kritisch wird. Monitoring und Neustartfunktionen verkürzen die Diagnosezeit, ersetzen aber keinen getesteten Plan zur Datenwiederherstellung.

Was zu überwachen ist

Überwachen Sie bei einer laufenden verwalteten Datenbank den Zustand der Engine, die Verfügbarkeit des Storage Nodes, das Speicherwachstum, Latenz, Verbindungsdruck, Ergebnisse aktueller Operationen und den Zustand jedes Bindings. Die Detailansicht der Datenbank stellt außerdem die Engine-spezifischen Metriken, Logs und berechtigten Funktionen von Explorer oder Konsole bereit.

Externe Verbindungen erhalten dieselben Health Checks, Engine-Metriken, Explorer und Konsole, aber keine Engine-Logs, Lebenszyklusaktionen oder Bindings, weil Opfield die Engine nicht betreibt. Zeigt eine externe Verbindung TLS certificate is not verified, fügen Sie ihr CA-Zertifikat hinzu oder verwenden Sie Test and enable verification; siehe TLS-Zertifikatsprüfung. Siehe Verwaltete und externe Datenbanken im Überblick.

Eine pausierte Instanz deaktiviert bewusst normalen Zustand, Metriken, Explorer und Konsole, bis sie fortgesetzt wird. Alarmieren Sie bei diesem erwarteten Fehlen nicht als Engine-Ausfall; halten Sie das Pausenfenster fest und prüfen Sie, dass der Dienst zu Ready zurückkehrt, bevor Sie abhängige Workloads wieder aktivieren.

Logs, Explorer und Konsole

Verwenden Sie Logs, um Start-, Speicher-, Authentifizierungs-, Berechtigungs- und Wiederherstellungsfehler einzuordnen. Lesen Sie die Phase einer Operation, bevor Sie eine Korrektur vornehmen, insbesondere nach Bereitstellung, Größenänderung oder Löschung. Verwenden Sie Explorer oder Konsole nur mit der erforderlichen Lese-, Schreib- oder Administrationsberechtigung und vermeiden Sie unbegrenzte Produktionsabfragen über eine Operator-Oberfläche.

Der Explorer durchsucht Schemas und Zeilen für PostgreSQL und ClickHouse; Schemaänderungen wie das Hinzufügen oder Ändern von Spalten sind für PostgreSQL verfügbar. Key-Value-Stores verwenden die Befehlskonsole. Jede Konsolenanweisung wird als Lese-, Schreib- oder administrative Operation eingestuft und erfordert entsprechend databases:query:read, databases:query:write oder databases:query:admin.

Konfigurationsbackups von Opfield enthalten keine Datenbankdaten. Sichern Sie Daten mit einer Backup-Richtlinie, bewahren Sie die Wiederherstellungsergebnisse auf und testen Sie Wiederherstellungen gegen ein separates Ziel. Planen Sie ein Backup vor destruktiver Lebenszyklusarbeit, einer wesentlichen Größenänderung oder einer Migration mit persistenten Daten. Das Wiederherstellungsset der Control Plane ist unter Updates, Backups und Wiederherstellung beschrieben.

Bei einer verwalteten PostgreSQL-Instanz gehören die Datenbank und jedes Anwendungsobjekt darin der Anwendungsrolle der Instanz, und jedes Binding arbeitet als diese Rolle. Die SQL-Konsole führt Schreib- und administrative Anweisungen ebenfalls als Anwendungsrolle aus, sodass eine über die Konsole erstellte oder befüllte Tabelle sofort von jedem Binding nutzbar ist; reine Leseanweisungen behalten einen schreibgeschützten Prinzipal. Für eine Anweisung, die den eigenen Steuerungsprinzipal von Opfield benötigt, etwa das Erstellen einer Rolle oder einer Erweiterung, die einen Superuser erfordert, beginnen Sie die Anfrage mit RESET ROLE; Objekte, die sie erstellt, werden direkt danach an die Anwendungsrolle übergeben. Opfield repariert diese Zuständigkeit außerdem jedes Mal, wenn es ein Binding erstellt oder abgleicht, was über die Konsole von früheren Releases erstellte Tabellen korrigiert. Die Reparatur ändert nur Objekte innerhalb der Anwendungsdatenbank und überspringt Systemschemas und Mitglieder von Erweiterungen. Bindings bleiben bereit, während sich der Datenbank-Node neu verbindet.

Die interaktive Konsole ist bewusst durch ein über Anweisungen hinweg geteiltes Ausführungsbudget begrenzt. Sie ist ein Operator-Werkzeug, kein Werkzeug für Batch-Migrationen. Bevorzugen Sie für Schemaänderungen und lang laufende Wartung versionierte Migrationswerkzeuge und verwenden Sie nach Möglichkeit eine schreibgeschützte oder eng berechtigte Identität. Eine Verbindungsunterbrechung des Browsers darf nicht als Beweis gewertet werden, dass eine Abfrage abgebrochen wurde; prüfen Sie den resultierenden Engine-Zustand, bevor Sie es erneut versuchen.

Die Erfassung für das Monitoring läuft im Hintergrund. Opfield startet die Erfassung nach dem Bootstrap und wenn eine verwaltete Datenbank bereit wird; das Öffnen der Detailseite der Datenbank ist nicht der Auslöser. Beim ersten Besuch kann ein Diagramm auf die erste echte Messung oder eine historische Abfrage warten, die Oberfläche muss aber fehlende Daten von einer fehlerfreien Messung unterscheiden.

Ein fehlgeschlagenes Workload-Binding wiederherstellen

Prüfen Sie ein fehlgeschlagenes Binding in dieser Reihenfolge:

1. Bestätigen Sie, dass die verwaltete Datenbank Ready ist und ihr Storage Node online ist.
2. Bestätigen Sie, dass der Ziel-Docker-Node und der Workload online sind und ihren aktuellen Zustand melden.
3. Prüfen Sie den dauerhaften Sollzustand des Bindings und seine letzte Operation.
4. Prüfen Sie, dass die Verbindung des Bindings auf dem gemeinsamen Secure-Link-Connector des Nodes abgeglichen ist und der Workload an das Verbindungsnetzwerk angebunden ist.
5. Prüfen Sie den eigenen Engine-Prinzipal des Bindings und die vorgesehenen Berechtigungen.
6. Prüfen Sie die erhaltene Konfiguration des Workloads und die Anwendungslogs.

Bevorzugen Sie nach Behebung der Ursache einen Abgleich oder eine gezielte Wiederholung. Entfernen Sie Netzwerkobjekte oder Engine-Identitäten, die Opfield gehören, nicht manuell; das kann aus einem behebbaren Verbindungsproblem eine Zustandsabweichung oder ein verwaistes Bereinigungsproblem machen.

Betriebliche Änderungen und Löschung

Auf Pausieren und Fortsetzen, Neustart, Größenänderung, Rotation von Zugangsdaten, Rotation von Zertifikaten, direkte Veröffentlichung, Löschen eines Bindings und Löschen einer Datenbank sollte jeweils die passende Prüfung folgen: Zustand der Engine, Client-Verbindung, Zustand von Route oder Listener, Logs, Metriken und erfasstes Task-Ergebnis. Die direkte Veröffentlichung ist optional; überwachen Sie sie als Pfad für externe Clients getrennt von privaten Bindings.

Entfernen oder migrieren Sie beim Löschen einer Datenbank zuerst die Bindings und warten Sie auf die Bereinigung ihrer Verbindungen und Identitäten. Ein fehlgeschlagenes Löschen sollte für die Wiederherstellung im Operationsverlauf von Opfield bleiben. Entfernen Sie Speicher oder Benutzer nicht gewaltsam auf Daemon- oder Engine-Ebene, sofern kein ausdrückliches Wiederherstellungsverfahren das verlangt.

Runbook für Backup und Wiederherstellung

Legen Sie vor dem Produktionseinsatz ein Engine-spezifisches Recovery Point Objective und Recovery Time Objective fest. Konfigurieren Sie eine Backup-Richtlinie mit einem Speicherziel außerhalb des Nodes und einer Aufbewahrungsanzahl. Bewahren Sie Backups außerhalb des Storage Nodes auf, verschlüsseln Sie sie, halten Sie die Engine-Version und den Wiederherstellungsbefehl fest und testen Sie sie auf einem isolierten Ziel. Ein erfolgreiches Backup ohne erfolgreichen Wiederherstellungstest ist kein Wiederherstellungsnachweis.

Für eine Wiederherstellungsübung:

1. Erstellen Sie ein separates Ziel mit kompatibler Engine und Speicherkapazität.
2. Stellen Sie das Backup wieder her, ohne die aktive Instanz zu überschreiben; die Wiederherstellung in Opfield erstellt standardmäßig eine neue verwaltete Datenbank und erfordert ein leeres Ziel.
3. Führen Sie Integritätsprüfungen und repräsentative Anwendungsabfragen aus.
4. Stellen Sie den Zugriff mit neuen Bindings oder eng begrenzten Client-Identitäten wieder her.
5. Vergleichen Sie die Anzahl der Zeilen, Schlüssel und Tabellen sowie Invarianten auf Anwendungsebene.
6. Halten Sie Dauer, manuelle Schritte und jede entdeckte Versionseinschränkung fest.

Opfield-Backups sind geplante native Backups, keine Point-in-Time-Recovery: Der Zeitplan legt fest, wie viele Daten eine Wiederherstellung verlieren kann. Bewahren Sie mindestens ein Backup-Ziel an einem anderen Standort auf. Replikation auf andere Storage Nodes ist in Business und Enterprise über Availability verfügbar.

Einordnung von Vorfällen

Ordnen Sie ein, bevor Sie den Zustand ändern: Fehler der Control Plane betreffen Tasks oder Abgleich; Node-Fehler betreffen die Aktualität des Daemons und die lokale Laufzeit; Engine-Fehler erscheinen in Datenbanklogs und Zustand; Speicher-Fehler betreffen Mount oder Kapazität; Binding-Fehler betreffen den Zustand von Listener oder Prinzipal; Anwendungs-Fehler erscheinen, nachdem die Konnektivität gelingt. Diese Reihenfolge verhindert, dass eine fehlerfreie Engine neu gestartet wird, um einen Berechtigungsfehler der Anwendung zu beheben.

Prüfen Sie nach der Wiederherstellung den ursprünglichen Kundenpfad, nicht nur den Administrationsbildschirm. Bestätigen Sie eine echte Abfrage, die erwarteten Berechtigungen und eine stabile Zustandserfassung sowie dass keine vorübergehende direkte Veröffentlichung, erhöhte Rolle, kein Debug-Token und keine manuelle Netzwerkänderung zurückbleibt.