Datenbankübersicht

Opfield arbeitet auf zwei Arten mit Datenbanken: mit einer verwalteten Instanz, die Opfield auf einem Storage Node bereitstellt und betreibt, und mit einer externen Verbindung zu einer Datenbank, die anderswo läuft. Beide erscheinen in derselben Liste mit denselben Health Checks, Metriken, Explorer, Konsole und Backups.

Wählen Sie das Modell, bevor Sie eine Anwendung einbinden. Verwenden Sie eine externe Verbindung für eine Datenbank, deren Engine bereits eine andere Plattform oder ein anderes Team betreibt. Verwenden Sie eine verwaltete Instanz, wenn Opfield die Engine betreiben soll: Es stellt sie auf einer begrenzten lokalen Festplatte bereit, zeigt ihren Zustand und ihre Lebenszyklusaktionen und erstellt private Anwendungs-Bindings. Die Umwandlung eines Modells in das andere ist eine Migration, keine Einstellung.

Verwaltete und externe Datenbanken im Überblick

Beide Modelle unterstützen PostgreSQL, Key-Value-Stores und ClickHouse und erscheinen in derselben Liste Databases. Ein Key-Value-Store funktioniert mit Redis-Clients; neue verwaltete Stores laufen mit Valkey (siehe Key-Value-Stores). Die Tabelle zeigt, was Opfield bereitstellt und betreibt und womit es sich nur verbindet.

Fähigkeit	Verwaltete Datenbank	Externe Verbindung
Wer die Engine bereitstellt und betreibt	Opfield, als Container mit Speicher fester Größe auf einem Storage Node	Der aktuelle Eigentümer der Datenbank, außerhalb von Opfield
Engine-Versionen	Ein kuratierter Katalog per Digest festgelegter Images für PostgreSQL, Valkey und ClickHouse; vor 2.12 erstellte Stores behalten Redis bis zu Move to Valkey	Was der Eigentümer betreibt
Verbindungstest, Zustand und Metriken	Ja, einschließlich CPU, Arbeitsspeicher, Swap und Prozessen des Containers	Ja, Zustand und Metriken der Engine
Explorer für Schemas und Daten	PostgreSQL und ClickHouse	PostgreSQL und ClickHouse
SQL-Konsole oder Befehlskonsole für Key-Value	Ja	Ja
PostgreSQL-Erweiterungen	Im Image enthaltene Erweiterungen aktivieren oder deaktivieren	Nein
Engine-Logs	Ja	Nein
Pausieren, Fortsetzen, Neustarten und Wiederholen einer fehlgeschlagenen Bereitstellung	Ja	Nein
Größe von CPU, Arbeitsspeicher, Swap und Speicher ändern	Ja; Speicher kann nur wachsen	Nein
Engine-Einstellungen	Maximale Verbindungen bei PostgreSQL, Persistenz- und Speichereinstellungen bei Key-Value, XML-Konfiguration bei ClickHouse	Nein
Direkte TCP-Veröffentlichung mit nativem TLS	Optional, kann später geändert werden	Nicht zutreffend
Wie Opfield TLS prüft	Opfield erreicht die Instanz über den gegenseitig authentifizierten Relay-Tunnel; PostgreSQL-TLS wird zusätzlich gegen die Opfield Database CA geprüft	Zertifikatskette und Hostname werden standardmäßig geprüft; optional eigene CA; ausdrückliches Abschalten möglich. Siehe TLS-Zertifikatsprüfung
Zugangsdaten	Opfield hält die Zugangsdaten des Besitzers intern; Anzeigen und Rotation gelten für einen separaten Benutzer für den direkten Zugriff einer veröffentlichten Instanz	Gespeicherte Verbindungsdaten, verschlüsselt gespeichert und mit `databases:credentials:reveal` anzeigbar; eine angezeigte PostgreSQL-URI verwendet `sslmode=verify-full`, wenn die Prüfung aktiv ist, und `sslmode=require`, wenn sie aus ist
Private Bindings an Container, Deployments und Compose-Dienste	Ja, mit einer eigenen Engine-Identität pro Binding	Nein; liefern Sie Verbindungswerte als Workload-Secrets
Upgrade der Engine-Version	Über die API und MCP auf eine neuere Katalogversion derselben Engine: PostgreSQL innerhalb der Hauptversion, Valkey und ClickHouse auf die nächste Katalogversion. Eine andere PostgreSQL-Hauptversion bedeutet, ein Backup in eine neue Datenbank wiederherzustellen	Verantwortung des Eigentümers
Backup und Wiederherstellung	Geplante native Backups in eine Speicherverbindung; Wiederherstellung in eine neue verwaltete Datenbank oder über die API in eine leere bestehende Datenbank	Wie bei verwalteten Datenbanken
Mehrere Server mit Failover	In Business und Enterprise 2 bis 5 Storage Nodes mit einem Primary und Kopien; siehe Datenbanken und Speicher auf mehreren Servern	Verantwortung des Eigentümers
Löschen	Entfernt die Engine, ihren Speicher und ihre Daten; blockiert, solange Bindings existieren	Entfernt nur den in Opfield gespeicherten Eintrag
Tarif	Personal oder höher	Personal oder höher

Explorer- und Konsolenzugriff erfordern zusätzlich zu databases:view die separaten Scopes databases:query:read, databases:query:write oder databases:query:admin. Opfield stuft jede Konsolenanweisung als Lese-, Schreib- oder administrative Operation ein und verlangt den passenden Scope.

TLS-Zertifikatsprüfung für externe Verbindungen

Verwendet eine externe Verbindung TLS, prüft Opfield die Zertifikatskette des Servers und dass das Zertifikat für den konfigurierten Host ausgestellt wurde. Das ist die Voreinstellung für neue Verbindungen. In den Verbindungseinstellungen:

Verify server certificate schaltet die Prüfung für diese Verbindung ein oder aus. Das Ausschalten hält den Datenverkehr verschlüsselt, erlaubt aber jedem auf dem Netzwerkpfad, sich als die Datenbank auszugeben und ihre Zugangsdaten abzufangen; verwenden Sie es nur als bewusste Ausnahme.
CA certificate akzeptiert ein PEM-Bundle einer privaten CA, der statt des öffentlichen CA-Bundles vertraut wird. Es werden nur Zertifikate akzeptiert; ein eingefügter privater Schlüssel wird abgelehnt.

Opfield testet die Verbindung mit den neuen Einstellungen, bevor es eine neue oder geänderte Verbindung speichert. Kann das Zertifikat nicht geprüft werden, wird die Änderung mit DATABASE_TLS_VERIFICATION_FAILED (HTTP 422) abgelehnt, und die gespeicherte Verbindung bleibt unverändert. Das Ausschalten der Prüfung oder der Wechsel einer geprüften Verbindung zu einer anderen CA erfordert die erneute Eingabe des Datenbankpassworts, weil das gespeicherte Passwort sonst einen nicht geprüften Server erreichen könnte.

Eine Verbindung, die TLS ohne Prüfung verwendet, zeigt auf ihrer Detailseite TLS certificate is not verified. Test and enable verification schaltet die Prüfung nach einem erfolgreichen Test ein, und Add CA certificate öffnet die Einstellungen, um eine private CA hinzuzufügen. PostgreSQL- und Redis-Verbindungen, die vor 2.11 TLS verwendet haben, beginnen in diesem ungeprüften Zustand, damit sie beim Upgrade verbunden bleiben; ClickHouse-HTTPS-Verbindungen wurden bereits geprüft. Datenbank-Backups verwenden dieselbe Einstellung.

Ressourcenmodell

Verwaltete PostgreSQL-, Key-Value- und ClickHouse-Instanzen sind standardmäßig privat. Opfield koordiniert Engine-Konfiguration, Speicher, Zugangsdaten, Zustand, Logs, Operationen und Anwendungs-Bindings. Der ausgewählte Storage Node betreibt die Engine, während Opfield den Sollzustand der Ressource und ihre Beziehungen zu Workloads behält.

Eine externe Verbindung überträgt die Zuständigkeit für die Datenbank nicht an Opfield. Opfield speichert ihre Verbindungskonfiguration und Zugangsdaten verschlüsselt hinter ausdrücklichen Berechtigungen und kann die Datenbank sichern; Verfügbarkeit, Zugriffsrichtlinie und Engine-Lebenszyklus der externen Datenbank bleiben bei ihrem Betreiber.

Behandeln Sie gespeicherte Zugangsdaten als privilegierte Infrastruktur-Secrets. Vergeben Sie Ansehen, Bearbeiten, Anzeigen von Zugangsdaten und Abfrageberechtigungen getrennt, wo das Rollenmodell es erlaubt, und vermeiden Sie es, ein Besitzer- oder Superuser-Konto zu teilen, wenn ein engeres Dienstkonto verfügbar ist. Das Löschen einer externen Verbindung entfernt die in Opfield gespeicherte Beziehung; es löscht weder die entfernte Datenbank noch ihren Speicher oder ihre Benutzer.

Standardmäßig privater Zugriff

Verwenden Sie ein Anwendungs-Binding, wenn ein verwalteter Workload Zugriff auf eine verwaltete Datenbank benötigt. Ein Binding vergibt eine separate Engine-Identität mit Rechten auf Anwendungsebene – niemals die Zugangsdaten des Besitzers oder Superusers – und einen privaten Endpunkt, den Opfield über normale Neuerstellungen des Workloads hinweg erhält. Es gibt keinen zusätzlichen Dienst pro Binding, den das Anwendungsteam betreiben müsste. Bindings sind für externe Verbindungen nicht verfügbar.

Dieser Transport unterscheidet sich vom Secure-Link-Connector für nginx und Workloads. Secure Link bleibt eine separate Komponente für seine eigene Ingress- und Relay-Funktion. Behandeln Sie einen Binding-Fehler nicht als Beleg dafür, dass die Secure-Link-Komponente entfernt, neu erstellt oder als Datenbanktransport konfiguriert werden sollte.

Die direkte TCP-Veröffentlichung ist eine ausdrückliche Option für externe Clients. Sie öffnet Host-Firewalls nicht automatisch und sollte nur für einen identifizierten Client-Pfad mit geeigneten Zugangsdaten und Zertifikatsvertrauen aktiviert werden. Die Veröffentlichung einer Instanz ändert nicht das private Binding-Modell, das Workloads verwenden.

Lebenszyklus und betriebliche Grenzen

Die Detailansicht einer Datenbank vereint Zustand, Metriken, Engine-Einstellungen, Zugangsdaten, Zertifikate, Größenänderung, Pausieren und Fortsetzen, Neustart, Logs und berechtigten Zugriff auf Explorer oder Konsole. Die verfügbaren Aktionen hängen von Engine, Node-Konnektivität, Zustand der Instanz und Ihren Berechtigungen ab.

Pausieren bewahrt die Daten und deaktiviert bewusst die Rechenleistung der Engine. Eine pausierte Instanz bietet weder normalen Zustand noch Metriken, Explorer oder Konsole, bis sie fortgesetzt wird. Ein Neustart ist für eine kontrollierte betriebliche Aktion nützlich; er repariert keine ungelösten Speicher-, Authentifizierungs- oder Node-Fehler.

Grundanforderungen an die Bereitschaft

Prüfen Sie die vollständige Zuständigkeitsgrenze, bevor Sie eine Datenbank an ein Anwendungsteam übergeben:

Der ausgewählte Storage Node ist online und meldet unterstützte Speicherfähigkeiten.
Die verwaltete Instanz ist Ready, oder der externe Endpunkt ist mit aktivierter TLS-Zertifikatsprüfung erreichbar.
Zuständigkeit für Backups, Aufbewahrung und Wiederherstellungsnachweise sind außerhalb der Instanz selbst dokumentiert.
Die Anwendung verwendet eine Binding-spezifische Identität oder ein anderes Konto mit minimalen Rechten statt der Zugangsdaten des Besitzers.
Das Monitoring erfasst Daten, ohne dass ein Operator die Detailseite geöffnet halten muss.
Ein kontrollierter Neustart oder erneuter Verbindungsaufbau weist nach, dass sich der Client wie erwartet erholt.

Ein grünes Engine-Abzeichen allein ist kein durchgängiger Nachweis. Bestätigen Sie mindestens eine echte Anwendungsabfrage, die erwartete Berechtigungsgrenze und dass keine Zugangsdaten in der Quellcodeverwaltung, in Logs, in Task-Ausgaben oder in öffentlicher Laufzeitkonfiguration stehen.

Verfügbarkeit und Grenzen

Eine verwaltete Instanz läuft auf einem Storage Node, sofern Sie sie nicht auf mehreren Servern betreiben, was Business und Enterprise anbieten: Dann übernimmt eine Kopie auf einem anderen Host, wenn der Primary verloren geht, und die Seite gibt an, was ein Failover verlieren kann. Auf einem Server bewahrt Opfield den Sollzustand und koordiniert die Wiederherstellung, aber ein verlorener Node bedeutet eine verlorene Datenbank, bis er zurückkehrt oder aus einem Backup wiederhergestellt wird. Planen Sie in beiden Fällen Backups außerhalb des Nodes und die Wiederherstellungszeit entsprechend der geschäftlichen Bedeutung der Datenbank.

Konfigurationsbackups von Opfield enthalten keine Datenbankdaten. Das Löschen einer verwalteten Datenbank entfernt ihren verwalteten Speicher; halten Sie ein geprüftes Backup oder ein Migrationsziel bereit, bevor Sie sie löschen.

Details für Betreiber: privater Transport

Der Workload erreicht die Datenbank über den gemeinsamen Secure-Link-Connector seines Docker Nodes, in einem kleinen eigenen privaten Netzwerk für das Binding; es gibt keinen Connector-Container pro Binding und keinen Listener auf dem Host. Opfield gleicht die Verbindung und die Binding-Identität als dauerhaften Sollzustand ab. Zum Transport und zum Upgrade auf 2.11.1 siehe Datenbank-Bindings.

Nächste Schritte

Eine verwaltete Datenbank bereitstellen und außer Betrieb nehmen
Key-Value-Stores und Move to Valkey
Eine Datenbank oder einen Speicher auf mehreren Servern betreiben
Private Anwendungs-Bindings erstellen
Datenbankoperationen überwachen und wiederherstellen
Eine Anwendung mit einer privaten Datenbank verbinden von Anfang bis Ende
Eine Datenbank an einen Container, ein Deployment oder einen Compose-Dienst binden
Datenschutz planen mit Updates, Backups und Wiederherstellung