PostgreSQL · Architektur, Performance, Hochverfügbarkeit
PostgreSQL-Beratung und Datenbankarchitektur
Ihre Anwendungen hängen an einer Datenbank, deren Zustand niemand sicher kennt. Wir prüfen PostgreSQL nach einem festen Katalog, legen mit Ihnen das tragbare Datenverlust- und Ausfallziel fest und setzen die passende Architektur um.
- Befundliste statt Pauschalbewertung
- Patroni, CloudNativePG, PgBouncer, pgBackRest
- Änderungen an der Produktion nur nach Ihrer Freigabe
01Beratung und Betrieb
Erst wissen, dann ändern: PostgreSQL-Beratung bei SKAFFON
SKAFFON berät zu PostgreSQL und setzt um: Architektur, Performance, Hochverfügbarkeit, Sicherheit und Betriebskonzepte für Datenbanken, von denen Ihre Anwendungen abhängen. Die Seite richtet sich an IT-Leitung und Plattformverantwortliche, die eine bestehende Umgebung prüfen lassen, eine neue Datenbankarchitektur festlegen oder Hochverfügbarkeit einführen wollen.
Beratung und laufender Betrieb sind getrennte Leistungen. Hier geht es um Analyse, Entwurf und Umsetzung. Den dauerhaften Betrieb mit Failover, Backup und Wartung beschreibt Managed PostgreSQL; den Weg auf PostgreSQL oder auf eine neue Version beschreiben PostgreSQL-Migration und Datenbankmigration.
02Anlässe
Woran Sie merken, dass die Datenbank geprüft werden sollte
- Die Datenbank ist langsam geworden und niemand weiß, welche Abfragen oder welche Konfiguration die Ursache sind.
- Ein Ausfall hat gezeigt, dass Failover oder Wiederherstellung nie wirklich getestet wurden.
- Eine Anwendung soll hochverfügbar werden, und es ist offen, ob Patroni auf VMs, ein Kubernetes-Operator oder ein Anbieterdienst passt.
- Die eingesetzte Hauptversion läuft bald aus dem Support.
- Das Wissen über die Datenbank liegt bei einer einzelnen Person.
03Einstieg: Health-Check
Zwölf Prüfpunkte, an denen wir eine PostgreSQL-Umgebung messen
Der Health-Check ist der Einstieg der meisten Projekte. Er ist ein Katalog konkreter Prüfpunkte mit Prüfmethode; das Ergebnis ist eine priorisierte Befundliste, keine Pauschalbewertung.
| Prüfpunkt | Womit prüfen | Auffälligkeit |
|---|---|---|
| Version und Support | Servereinstellung server_version, Abgleich mit der Supportübersicht | Hauptversion nahe am Supportende oder bereits ohne Support; veralteter Minor-Stand |
| Teure Abfragen | Erweiterung pg_stat_statements: Aufrufe, Gesamtlaufzeit, Zeilenzahl je Abfrage | Wenige Abfragen verursachen den Großteil der Laufzeit; Abfragen ohne passenden Index |
| Verbindungen | Anzahl aktiver und wartender Verbindungen, Verbindungsmodell der Anwendung | Viele kurzlebige Verbindungen ohne Pooler; Verbindungsgrenze nahe erreicht |
| Backup und Wiederherstellung | Letzter erfolgreicher Restore-Test, WAL-Archivierung aktiv | Backup nie wiederhergestellt; Archivierung fehlerhaft; keine Point-in-Time-Recovery |
| Replikation | Replikationsverzug, Zustand der Standbys | Standby fehlt oder liegt zurück; Failover nie getestet |
| Replikationsslots | Von Slots zurückgehaltene WAL-Menge | Verwaister Slot lässt WAL anwachsen, bis der Datenträger voll ist (laut Dokumentation begrenzbar mit max_slot_wal_keep_size) |
| Speicher und Wachstum | Datenträgerfüllstand, Wachstum der größten Tabellen und des WAL | Füllstand steigt ohne Prognose |
| Wartung | Vacuum-Aktivität und Aufblähung großer Tabellen | Tabellen mit stark wachsendem toten Anteil |
| Rechte und Zugriff | Rollen, Rechte, Authentifizierungsregeln, Verbindungsverschlüsselung | Gemeinsame Superuser-Konten; Anwendungen mit Administratorrechten; unverschlüsselte Verbindungen |
| Konfiguration | Abweichungen von Standardwerten und Begründung | Parameter ungeprüft aus einer Anleitung übernommen |
| Monitoring | Welche Metriken erfasst werden, wer alarmiert wird | Ausfall würde zuerst von Anwendern bemerkt |
| Wissen und Betrieb | Runbooks, Zuständigkeiten, Zugriff im Notfall | Kenntnisse bei einer Person; keine dokumentierte Wiederherstellung |
Für die Abfrageanalyse muss pg_stat_statements laut Dokumentation in shared_preload_libraries geladen sein, was einen Neustart erfordert.
04Abfrageanalyse
Erst die Abfragestatistik, dann der Hebel
Fehlt pg_stat_statements, planen wir es als erste Änderung ein. Mit gemessenen Laufzeiten entscheiden wir danach, ob Index, Parameter, Verbindungsmodell oder die Anwendungsabfrage selbst der richtige Hebel ist. Dazu gehören drei Arbeitsfelder:
- Architektur: Topologie, Versionsstrategie, Trennung von Datenbanken und Schemata, Verbindungsmodell, Erweiterungen, Kapazität.
- Performance: Analyse der Abfragen und Konfiguration, Index- und Parameterempfehlungen, Maßnahmen gegen Sperren und Verbindungsprobleme.
- Sicherheit: Rollen- und Rechtekonzept, verschlüsselte Verbindungen, Absicherung der Konfiguration, Zugriffsprotokolle.
05Replikation
Asynchron oder synchron: was Sie gegen was tauschen
Hochverfügbarkeit ist keine einzelne Einstellung, sondern eine Abwägung zwischen möglichem Datenverlust und Verfügbarkeit. Die PostgreSQL-Dokumentation beschreibt sie für Streaming-Replikation so: Asynchron kann bei Ausfall des Primary ein Teil bereits bestätigter Transaktionen auf dem Standby fehlen, der Verlust entspricht dem Replikationsverzug zum Zeitpunkt des Ausfalls. Synchron geht Daten nur verloren, wenn Primary und Standby gleichzeitig ausfallen; dafür warten Commits auf die Bestätigung des Standbys und können blockieren, wenn ein synchroner Standby ausfällt.
| Kriterium | Asynchrone Replikation | Synchrone Replikation |
|---|---|---|
| Datenverlust bei Primary-Ausfall | möglich, abhängig vom Verzug | nur bei gleichzeitigem Ausfall mehrerer Knoten |
| Einfluss auf Commit-Latenz | gering | höher, Netzwerkabstand zählt |
| Verhalten bei Ausfall des Standbys | Primary arbeitet weiter | Commits können warten, abhängig von der Konfiguration |
| Geeignet für | Anwendungen, die einen kleinen Datenverlust verkraften; große Entfernungen | Daten, deren Verlust nicht akzeptabel ist; Knoten mit geringer Latenz |
06Entscheidungsreihenfolge
Vom Wiederherstellungsziel zum Werkzeug
Daraus folgt die Reihenfolge unseres Vorgehens bei der Hochverfügbarkeit: Ohne Ziel keine begründbare Architektur.
- 01
Wiederherstellungsziel festlegen
FachbereichWie viel Datenverlust ist für Ihren Fachbereich tragbar, wie lange darf der Ausfall dauern?
- 02
Replikationsmodus wählen
AbwägungAsynchron oder synchron, nach der Matrix oben.
- 03
Knotenzahl und Verteilung bestimmen
TopologieWie viele Knoten, wo, mit welcher Latenz zueinander.
- 04
Werkzeug wählen
Patroni oder CloudNativePGEin verteilter Konsensspeicher wie etcd entscheidet bei Patroni, welcher Knoten Primary ist; Patroni unterstützt laut Dokumentation neben etcd auch Consul, ZooKeeper und Kubernetes und bietet synchrone sowie Quorum-Modi. Auf Kubernetes übernimmt CloudNativePG die deklarative Verwaltung des Clusters.
Grenze der Replikation
Replikation ersetzt kein Backup
Ein Datenfehler wird mitrepliziert. Backup mit pgBackRest und Point-in-Time-Recovery sind ein eigener Baustein, den wir getrennt entwerfen und per Restore-Test nachweisen.
07Verbindungsschicht
PgBouncer: wann der Transaction-Modus Ihre Anwendung trifft
PgBouncer bündelt Verbindungen. Im Transaction-Modus wird eine Serververbindung nur für die Dauer einer Transaktion zugewiesen; laut Dokumentation funktionieren dann einige sitzungsbezogene Funktionen nicht, darunter SET/RESET, LISTEN und Session-Level-Advisory-Locks. Ob Ihre Anwendung diese nutzt, prüfen wir vor der Einführung.
08Projektablauf
Von der Befundliste bis zur Übergabe
- 01
Bestandsaufnahme und Health-Check
Ergebnis: BefundlisteNach dem Katalog, mit Befundliste und Priorisierung.
- 02
Zielarchitektur
Ergebnis: ZielbildMit Wiederherstellungszielen, Topologie und Begründung der Werkzeugwahl.
- 03
Umsetzung in kleinen Schritten
Abnehmbar, jeweils mit Rückfallplan.
- 04
Nachweis
Ergebnis: TestprotokolleFailover-Test, Restore-Test, Lasttest für die kritischen Abfragen.
- 05
Übergabe
Mit Runbooks an Ihr Team oder Übernahme in den Managed-Betrieb.
09Lieferumfang
Fünf Unterlagen, die nach dem PostgreSQL-Projekt bei Ihnen liegen
-
Health-Check-Bericht
Priorisierte Befunde nach dem Katalog.
-
Zielarchitektur
Mit Wiederherstellungszielen.
-
Konfiguration als Code
Umgesetzt und versioniert.
-
Testprotokolle
Failover- und Restore-Tests.
-
Runbooks
Für Ihr Team oder den Betrieb.
10Plattform und Zugriff
Zugriff und Plattform: auf Ihrer Umgebung, nicht daneben
Zugriff erfolgt über personalisierte, befristete Zugänge, Änderungen als Code mit Review, Datenübertragung verschlüsselt. Wir arbeiten auf Ihrer Plattform: STACKIT, AWS, Azure, GCP oder eigene Infrastruktur wie Proxmox. Weitere Absicherung: Cloud Security.
11Passung
Für welche PostgreSQL-Vorhaben wir die richtige Adresse sind
Das passt
- PostgreSQL ist Ihre Datenbank und Sie wollen Zustand, Risiken und Zielarchitektur belegt bekommen.
- Sie sind bereit, Wiederherstellungsziele mit dem Fachbereich zu definieren.
Das passt nicht
- Ihre Datenbank ist nicht PostgreSQL.
- Sie suchen Anwendungsentwicklung oder die Neugestaltung Ihres Datenmodells ohne Beteiligung des Anwendungsteams: Schema und Anwendungsabfragen verantwortet Ihr Team, wir beraten dazu.
- Sie wollen eine Hochverfügbarkeitszusage, ohne Wiederherstellungsziele zu definieren: Ohne dieses Ziel ist keine Architektur begründbar.
12
Häufige Fragen
Wie läuft der Einstieg ab?
Wir starten mit einem Health-Check nach dem Katalog. Sie erhalten eine priorisierte Befundliste, bevor irgendetwas geändert wird.
Brauchen Sie Zugriff auf die Produktion?
Nein, nicht für die Analyse: Dafür genügt Lesezugriff auf Statistik- und Konfigurationsdaten. Schreibende Eingriffe sprechen wir mit Ihnen ab und führen sie erst nach Ihrer Freigabe aus.
Ersetzt Replikation das Backup?
Nein. Ein Datenfehler wird mitrepliziert. Backup und Point-in-Time-Recovery sind ein eigener Baustein.
Betreiben Sie die Datenbank auch dauerhaft?
Beratung und Betrieb sind getrennte Leistungen. Den Betrieb beschreibt Managed PostgreSQL.
Health-Check starten
Beschreiben Sie Version, Umgebung und Ihr Problem
Mit diesen drei Angaben können wir einschätzen, ob ein Health-Check der richtige Einstieg ist. Weitere Themen: Data Engineering, Übersicht Daten.