PostgreSQL · MySQL · MongoDB
Managed Datenbanken und Datenbankbetrieb
Ihre Anwendungen hängen an Datenbanken, die niemand gern anfasst: Upgrades werden verschoben, der letzte Restore liegt Jahre zurück, Wissen steckt in einzelnen Köpfen. SKAFFON übernimmt den Betrieb auf Kubernetes, auf VMs oder in Ihrer Cloud, rund um die Uhr.
- Betrieb und Support 24/7
- Backup mit Point-in-Time-Recovery
- Restore-Test als Nachweis
01Make or buy
Anbieterdienst oder eigener Betrieb: woran Sie das entscheiden
STACKIT, die großen Hyperscaler und europäische Cloud-Anbieter bieten verwaltete Datenbankdienste als Produkt an. Für viele Anwendungen ist das die einfachste Lösung. Ein von uns betriebener Service lohnt sich dort, wo ein Fertigdienst an Grenzen stößt.
Die Seite beschreibt den engine-übergreifenden Betriebsrahmen. Für PostgreSQL gibt es die tiefer gehende Seite Managed PostgreSQL. Alle Betriebsservices im Überblick: Managed Services.
- Die Datenbank läuft auf eigener Infrastruktur, in einer souveränen Cloud oder in mehreren Umgebungen und soll einheitlich betrieben werden.
- Sie brauchen Einfluss auf Version, Konfiguration, Erweiterungen und Wartungsfenster, den ein Fertigdienst nicht bietet.
- Sie wollen ein Betriebsmodell, das beim Plattformwechsel mitgeht. Besonderheiten bei STACKIT: STACKIT-Datenbanken.
- Ihr Team hat die Betriebsfähigkeit (Bereitschaft, Upgrades, Restore-Nachweis) nicht und will sie nicht aufbauen.
02Engine-Matrix
Drei Engines, drei Betriebsmodelle: was sich im Alltag unterscheidet
Die Tabelle beschreibt Mechanismen laut Hersteller- und Projektdokumentation. Die endgültige Architektur legen wir nach der Bestandsaufnahme fest.
| Aspekt | PostgreSQL | MySQL | MongoDB |
|---|---|---|---|
| Hochverfügbarkeit | Primary mit Replikas; auf VMs mit Patroni, auf Kubernetes mit CloudNativePG, siehe Managed PostgreSQL | InnoDB Cluster: mindestens drei Instanzen, Group Replication mit eingebautem Failover, MySQL Router leitet Clients zum neuen Primary; für Standortausfall ClusterSet (MySQL: InnoDB Cluster) | Replica Set: mehrere Mitglieder halten denselben Datenbestand; Grundlage jedes Produktivbetriebs (MongoDB: Replication) |
| Backup und PITR | Physische Basis-Backups plus WAL-Archiv; bei CloudNativePG über Barman-Cloud-Plugin oder Volume-Snapshots; auf VMs pgBackRest | Dumps und physische Sicherung je Edition; Point-in-Time über Binärlog (MySQL: Backup und Recovery) | Dateisystem-Snapshots, Dumps und weitere Verfahren je Edition (MongoDB: Backup Methods) |
| Versionspolitik | Hauptversion laut Projekt fünf Jahre unterstützt (postgresql.org) | LTS-Serien folgen der Oracle Lifetime Support Policy mit fünf Jahren Premier und drei Jahren Extended Support; Innovation-Releases werden nur bis zum nächsten Innovation-Release unterstützt (MySQL: Releases) | Je Version laut Hersteller; Lebenszyklus gegen die MongoDB-Dokumentation prüfen |
| Lizenz | PostgreSQL License, eine liberale Open-Source-Lizenz (postgresql.org: Licence) | Community Edition und kommerzielle Editionen von Oracle; Funktionsumfang je Edition | Server Side Public License (SSPL) für Versionen nach dem 16.10.2018, kommerzielle Lizenzen verfügbar (MongoDB: Licensing) |
| Typische Fallen | Replikation mit Backup verwechseln; Major-Upgrades ohne Test | Dumps als einziges Backup bei großen Beständen | Rollbacks bei Failover (siehe Dokumentation zu Lese-Konsistenz); Lizenzfrage nicht geklärt |
MongoDB und die SSPL: die Lizenzfrage kommt vor dem Betrieb
Die SSPL enthält in Abschnitt 13 eine Bedingung für das Anbieten der Software „als Dienst“ an Dritte: Wer die Funktionalität Dritten als Service zur Verfügung stellt, muss den Quellcode des Dienstes bereitstellen (MongoDB: SSPL). Ob das auf Ihren Betrieb zutrifft, hängt von Ihrem Szenario ab und gehört in die Prüfung durch Ihre Rechtsabteilung; wir klären die Lizenzfrage zu Beginn mit Ihnen. Rechtsberatung leistet SKAFFON nicht.
03Betriebsumfang
Acht Aufgaben, die wir an Ihrer Datenbankplattform übernehmen
Betreibbar auf STACKIT, AWS, Azure, GCP sowie auf eigener Infrastruktur, etwa Proxmox. Die Plattform darunter ist ein eigener Service: Cloud-Betrieb und Managed Kubernetes.
-
Cluster-Betrieb
Aufbau und Betrieb je Engine nach der Matrix, auf VM oder Kubernetes.
-
Failover
Automatische Umschaltung, regelmäßige Failover-Tests.
-
Patching und Upgrades
Minor-Updates im Wartungsfenster, Major-Upgrades als eigenes geplantes Vorhaben mit Test auf einer Kopie.
-
Backup, PITR, Restore
Zeitpläne, Aufbewahrung, Wiederherstellung inklusive Klon zur Prüfung; Konzeption im Verbund mit Backup und Disaster Recovery.
-
Monitoring
Prometheus-basiert: Verfügbarkeit, Replikationsverzug, Verbindungen, Speicher, langsame Abfragen, Backup-Status. Alarmiert wird auf Datenbankebene.
-
Performance
Analyse langsamer Abfragen, Hinweise zu Indizes und Parametern, Kapazitätstrends.
-
Security
Rollen- und Rechtekonzept, verschlüsselte Verbindungen, Härtung, Zugriffsprotokolle. Vertiefung: Cloud Security.
-
Monatsbericht
Incidents, Changes, Patches, Backup- und Restore-Ergebnisse, Kapazitätstrends und Empfehlungen.
04Wiederherstellung
Replikation ersetzt kein Backup: wie wir Wiederherstellung belegen
Ein Fehler in den Daten wird mitrepliziert. Deshalb liegen Backups und Log-Archiv getrennt vom Datenbankknoten. Wiederherstellungsziele (RPO/RTO) hängen von Backup-Rhythmus, Archivierung, Replikationsmodus und Datenvolumen ab. Sie werden vertraglich je Datenbank vereinbart und per Restore-Test nachgewiesen.
Ob ein vereinbartes Ziel erreichbar ist, belegt erst der Restore-Test.
- Replikas schützen vor Knotenausfall, nicht vor Datenfehlern
- Backup und Log-Archiv liegen getrennt vom Datenbankknoten
- Ein Restore-Test belegt, dass die Wiederherstellung funktioniert
05
Woran sich RPO und RTO entscheiden: Stellgrößen statt Pauschalwerte
RPO ist der maximal tolerierte Datenverlust, RTO die Zeit bis zur Wiederherstellung. Die Werte ergeben sich aus diesen Stellgrößen und werden je Datenbank vereinbart.
| Stellgröße | Wirkung auf den Datenverlust (RPO) | Wirkung auf die Wiederherstellungszeit (RTO) |
|---|---|---|
| Log-Archivierung | Fortlaufend archivierte Logs verkürzen das Zeitfenster, das verloren gehen kann | Gering; entscheidend ist, wie viele Logs beim Restore eingespielt werden müssen |
| Replikationsmodus | Synchrone Replikation kann Verlust bei Knotenausfall verhindern, asynchrone nicht | Ein Replikat mit Failover ersetzt langes Einspielen, schützt aber nicht vor Datenfehlern |
| Datenvolumen | Kaum Einfluss | Größere Bestände brauchen länger für Restore und Aufbau |
| Backup-Rhythmus | Basis-Backups allein begrenzen den Verlust nur auf Backup-Abstand | Häufigere Basis-Backups verkürzen die Wiederherstellung |
| Ablageort des Backups | Getrennter Standort erhält Daten bei Ausfall des Rechenzentrums | Anbindung und Entfernung bestimmen die Übertragungszeit |
06Verantwortung
Wer am Datenbankbetrieb welchen Teil verantwortet
R = führt aus, A = trägt die Ergebnisverantwortung, C = wird konsultiert, I = wird informiert. Standardaufteilung, vertraglich anpassbar. Inhalt der Daten und Anwendung bleiben in Ihrer Verantwortung; wir verantworten den Betrieb der Datenbankplattform.
| Tätigkeit | SKAFFON | Kunde |
|---|---|---|
| Cluster-Topologie und Konfiguration betreiben | R/A | C |
| Minor-Updates und Sicherheitspatches | R | A (Freigabe Wartungsfenster) |
| Major-Upgrade planen und durchführen | R | A |
| Monitoring und Alarmierung betreiben | R/A | I |
| Störung auf Datenbank-/Cluster-Ebene (Failover, Replikation, Speicher) | R/A | I |
| Backup einrichten und Archivierung betreiben | R/A | C |
| Restore-Tests durchführen | R/A | C |
| Wiederherstellung im Ernstfall durchführen | R | A (Entscheidung über Zeitpunkt und Datenstand) |
| Schema, Migrationen, Datenmodell | C | R/A |
| Langsame Abfragen der Anwendung ändern | C | R/A |
| Index- und Parameterempfehlungen | R | A (Freigabe) |
| Datenbankrollen technisch umsetzen | R | A |
| Fachliche Zugriffsentscheidung | C | R/A |
| Datenklassifizierung, Löschfristen, Datenschutz | C | R/A |
| Lizenzbeschaffung und -prüfung der Engine | C | R/A |
| Kapazitätsplanung, Berichte | R | A |
07Betriebsprozesse
Störung, Änderung, Update: der Weg vom Alarm bis zur Freigabe
Betrieb und Support laufen 24/7. Störungen stufen wir nach Priorität ein, zum Beispiel Datenbank nicht erreichbar, Replikation gestört oder Leistungsabfall.
- 01
Alarm bis Abschluss
IncidentAlarm oder Meldung, Priorisierung, Eingrenzung, Behebung oder Workaround (zum Beispiel manueller Failover), Statusinformation, Abschluss mit Ihrer Bestätigung, bei schwerwiegenden Störungen Ursachenanalyse.
- 02
Konfiguration als Code
ChangeReview, Einstufung, Freigabe durch Sie, Umsetzung durch SKAFFON, Verifikation; vorher ein Rückfallplan.
- 03
Rolling-Update
Minor-UpdateZuerst auf den Replikas, dann Umschaltung, dann der frühere Primary. Dringende Sicherheitsupdates stimmen wir außerhalb des Regelzyklus ab.
- 04
Eigenes Vorhaben
Major-UpgradeTest auf Kopie, Rückfallplan und Abnahme. Welche Versionen ihr Supportende erreichen, planen wir mit Ihnen voraus (siehe Versionspolitik in der Matrix).
08Betriebsübernahme
Zehn Punkte, die wir an Ihrer bestehenden Datenbank klären
Bevor wir eine Datenbank übernehmen, gehen wir diese Liste durch. Jede Lücke wird zur Aufgabe im Onboarding.
- Engine, genaue Version, Edition und Lizenzlage; Supportstatus der Version
- Topologie: Knoten, Replikation, Failover-Mechanismus, wer hat ihn zuletzt getestet
- Größe, Wachstum, Last, Spitzenzeiten, Wartungsfenster
- Vorhandene Backups: Verfahren, Ort, Aufbewahrung, letzter erfolgreicher Restore
- Erweiterungen, Plugins, Trigger, Jobs, externe Abhängigkeiten
- Rollen und Zugriffe: wer hat Administratorrechte, Dienstkonten, Verschlüsselung
- Monitoring: was wird bereits überwacht, welche Alarme existieren
- Bekannte Probleme: langsame Abfragen, Lock-Konflikte, Speicherdruck
- Compliance-Vorgaben: Standort, Aufbewahrung, Löschung, Protokollierung
- Ansprechpartner Anwendung und Fachbereich, Eskalationskette
09
Von der Bestandsaufnahme bis zum ersten bestandenen Restore
Das Onboarding folgt sechs Schritten.
- 01
Bestandsaufnahme
Nach der Checkliste oben.
- 02
Zielarchitektur und Verantwortung
Zielarchitektur und Verantwortungsmatrix festlegen.
- 03
Aufbau oder Übernahme
Cluster aufbauen oder bestehende Datenbank übernehmen.
- 04
Monitoring und Backup
Überwachung und Sicherung aufschalten.
- 05
Erster Restore-Test
Wiederherstellung nachweisen.
- 06
Regelbetrieb
Übergang in den laufenden Betrieb.
10Servicezeiten und Kennzahlen
Reaktionszeiten und Verfügbarkeit: was vertraglich festgelegt wird
Definition der Prioritätsstufen P1 bis P4 und die Bedeutung der Reaktionszeit stehen im Servicelevel-Rahmen. Reaktionszeiten und Eskalationskette legt der Vertrag fest; die Kontaktwege testen wir im Onboarding mit Ihnen.
Verfügbarkeitsziele vereinbaren wir je Plattform; sie hängen von Engine, Topologie (Knotenzahl, Verteilung über Zonen), Replikationsmodus und Wartungsfenstern ab. Kennzahlen, Messmethode und Folgen bei Abweichung werden vertraglich vereinbart; die Systematik beschreibt der Servicelevel-Rahmen.
11
Für welche Datenbanken sich der Betrieb durch SKAFFON eignet
Wir starten mit einer Bestandsaufnahme und legen daraus Umfang, Verantwortungsmatrix und Berichtsrhythmus fest.
Das passt
- PostgreSQL, MySQL oder MongoDB, die Sie einheitlich und nachweisbar betreiben lassen wollen.
- Sie lassen Restore-Tests und den Zugriff auf die Umgebung zu.
Das passt eher nicht
- Sie suchen einen Datenbank-Hosting-Dienst von der Stange mit Selbstbedienung: dann ist ein Anbieterdienst oft passender.
- Wir sollen Schema und Anwendungsabfragen verantworten, ohne die Anwendung zu kennen.
- Ihre Engine ist eine andere; für andere Engines klären wir im Einzelfall, ob ein Betrieb möglich ist, ohne es zuzusagen.
- Sie wollen keinen Zugriff auf die Umgebung und keine Restore-Tests zulassen.
12
Häufige Fragen
Betreiben Sie auch die Datenbanken unserer Cloud-Anbieter?
Verwaltete Dienste eines Anbieters betreibt der Anbieter selbst. Wo SKAFFON darum herum Leistungen erbringt, etwa Migration oder Architektur, beschreiben die Seiten STACKIT-Datenbanken und Cloud-Betrieb; den Umfang legen wir je Fall fest.
Können wir die Engine später wechseln?
Ja, über ein Migrationsprojekt; siehe Datenbankmigration.
Brauchen wir Hochverfügbarkeit?
Das hängt davon ab, welche Ausfallzeit Ihre Anwendung verkraftet. Hochverfügbarkeit erhöht Aufwand und Kosten und schützt nicht vor Datenfehlern; wir legen es mit Ihnen pro Datenbank fest.
Welche Datenbanken sollen wir in den Betrieb nehmen?
Beschreiben Sie Engines, Größen und Anforderungen in einer Projektanfrage. Wenn Daten zuerst auf eine andere Engine ziehen müssen, beginnt der Weg bei der Datenbankmigration; weitere Themen: Daten.