Was macht dieser Skill?
/pg-dr ist der beeindruckendste Skill im mcp-postgres Arsenal. Er orchestriert einen vollständigen Disaster-Recovery-Drill über zwei Kubernetes-Cluster hinweg: Pre-Flight-Check, Replica-Promotion, Verifizierung des neuen Primärs, Demote zurück zum Original und erneuter Health-Check. Der gesamte Promote/Demote-Zyklus dauert unter 3,5 Sekunden.
Das ist kein Spielzeug — es ist ein validierter DR-Drill, der beweist, dass Ihr Failover funktioniert, bevor Sie ihn brauchen.
Workflow-Phasen
- Phase 1 — Pre-Flight:
pg_cnpg_dr_readinessberechnet einen Readiness-Score (0–100). Der Drill startet nur bei Score ≥ 80. - Phase 2 — Replica Status:
pg_cnpg_replica_statusprüft Replication Lag und WAL-Position - Phase 3 — WAL Archive:
pg_cnpg_wal_archive_statusverifiziert die WAL-Archivierung - Phase 4 — Promote:
pg_cnpg_promotebefördert die Replica zum neuen Primär - Phase 5 — Verify Promoted:
pg_cnpg_cluster_statusbestätigt den neuen Primär - Phase 6 — Demote:
pg_cnpg_demotesetzt den ursprünglichen Zustand wieder her - Phase 7 — Verify Restored:
pg_cnpg_cluster_statusbestätigt die Wiederherstellung - Phase 8 — Abschlussbericht: Timing-Daten, Ergebnis und Gesamtdauer
Wie wird er aufgerufen?
Konfiguration
DR-Tools arbeiten konfigurationsbasiert. Statt einer direkten Datenbankverbindung werden System und Umgebung aus der DR-Konfiguration gelesen — so können mehrere Cluster-Paare verwaltet werden:
▶ Calling tools...
→ pg_cnpg_dr_readiness { "system": "hubport", "environment": "lab" }
// Liest primary + replica aus ~/.config/mcp-postgres-enterprise/dr/cnpg-dr.json
// Primary: k8s-primary/mcp-test/mcp-test-cnpg (2 Instanzen)
// Replica: k8s-replica/mcp-test/mcp-test-cnpg-replica (1 Instanz)
Claude CLI (natürliche Sprache)
▶ Calling tools...
→ Phase 1/8: pg_cnpg_dr_readiness { cluster: "hubport-lab" }
Readiness Score: 92 / 100
Primary: db-primary (2 Instanzen), Replica: db-replica (1 Instanz)
Replication Lag: 0 Bytes, WAL Archiving: ✓
→ Score ≥ 80, Drill wird gestartet
→ Phase 2/8: pg_cnpg_replica_status {}
Replica db-replica-1: streaming, lag 0 bytes
Last received LSN: 0/4A000060, last replayed LSN: 0/4A000060
→ Phase 3/8: pg_cnpg_wal_archive_status {}
Last archived WAL: 00000001000000000000004A
Archive command: OK, Last failure: none
→ Phase 4/8: pg_cnpg_promote { cluster: "db-replica", method: "spec_patch" }
Promoting db-replica...
Promotion complete in 1.2s
db-replica-1 ist jetzt Primär
→ Phase 5/8: pg_cnpg_cluster_status { cluster: "db-replica" }
Cluster: HEALTHY, Primär: db-replica-1, Instanzen: 1/1 ready
→ Phase 6/8: pg_cnpg_demote { cluster: "db-replica", method: "spec_patch" }
Demoting db-replica zurück zu Replica...
Demote complete in 0.8s
db-replica-1 ist wieder Replica
→ Phase 7/8: pg_cnpg_cluster_status { cluster: "db-primary" }
Cluster: HEALTHY, Primär: db-primary-1, Replicas: 2 (inkl. db-replica)
→ Phase 8/8: DR-Drill Abschlussbericht
╔══════════════════════════════════════════════╗
║ DR-Drill: ERFOLGREICH ║
╠══════════════════════════════════════════════╣
║ Readiness Score : 92 / 100 ║
║ Promote-Dauer : 1.2s ║
║ Demote-Dauer : 0.8s ║
║ Gesamtdauer : 3.4s ║
║ Cluster-Status : Wiederhergestellt ║
║ Datenverlust : 0 Bytes ║
╚══════════════════════════════════════════════╝
MCP Protocol (Skill-Definition)
const result = await client.callTool("/pg-dr", { "cluster": "hubport-lab" });
// Response:
{
"skill": "/pg-dr",
"tools": [
"pg_cnpg_dr_readiness",
"pg_cnpg_replica_status",
"pg_cnpg_wal_archive_status",
"pg_cnpg_promote",
"pg_cnpg_cluster_status",
"pg_cnpg_demote",
"pg_cnpg_cluster_status"
],
"phases": 8,
"gate": { "min_readiness_score": 80 },
"output": {
"result": "SUCCESS",
"readiness_score": 92,
"promote_duration_ms": 1200,
"demote_duration_ms": 800,
"total_duration_ms": 3400,
"data_loss_bytes": 0,
"cluster_restored": true
}
}
Was passiert unter der Haube?
Der Skill orchestriert sieben MCP-Tools über zwei Kubernetes-Cluster hinweg. Das Besondere: er verwendet die spec_patch-Methode für Promote und Demote, die den CNPG-Operator nutzt statt direkte PostgreSQL-Befehle.
Phase 1: Pre-Flight (Readiness)
Prüft Replication Lag, WAL-Archivierung, Cluster-Gesundheit und Instanz-Verfügbarkeit. Berechnet einen gewichteten Score. Bei Score < 80 wird der Drill abgebrochen — kein Risiko bei instabiler Replikation.
Phase 2–3: Replica- und WAL-Status
Detailprüfung von Streaming-Replikation und WAL-Archivierung. Stellt sicher, dass die Replica auf dem neuesten Stand ist und alle WAL-Segmente archiviert wurden.
Phase 4: Promote
Befördert die Replica zum Primär über einen spec_patch auf dem CNPG-Cluster-Objekt. Dies ist die sicherste Methode, da der CNPG-Operator den gesamten Failover-Prozess orchestriert:
- Streaming-Verbindung wird getrennt
- Recovery abgeschlossen
- Timeline inkrementiert
- Neue Timeline veröffentlicht
Phase 5: Verify Promoted
Bestätigt, dass die ehemalige Replica als neuer Primär läuft und Schreibzugriff möglich ist.
Phase 6: Demote
Setzt den Cluster wieder in den Originalzustand zurück — die ehemalige Replica wird wieder zur Replica, der ursprüngliche Primär übernimmt wieder die Führung.
Phase 7–8: Verify + Report
Bestätigt die vollständige Wiederherstellung und erzeugt einen Timing-Bericht mit Promote-Dauer, Demote-Dauer und Gesamtzeit.
Warum ist das beeindruckend? Ein manueller DR-Drill dauert typischerweise 30–60 Minuten und erfordert koordinierte Aktionen über Terminals, kubectl, und PostgreSQL-Clients. /pg-dr erledigt dasselbe in 3,5 Sekunden — vollautomatisch, validiert, und reproduzierbar.
Was testet die Testsuite?
Die Testsuite führt den vollständigen Promote/Demote-Zyklus gegen eine CNPG-Lab-Umgebung durch:
→ expects spec_patch method for promote and demote
→ readiness gate: score ≥ 80
→ total cycle: 3.4s
Test Files 1 passed (1)
Tests 1 passed (1)
Duration 4.2s
Testdaten-Szenario
Die Lab-Umgebung besteht aus:
- k8s-primary — Kubernetes-Cluster mit CNPG-Cluster "db-primary" (2 Instanzen)
- k8s-replica — Kubernetes-Cluster mit CNPG-Cluster "db-replica" (1 Instanz, Replica)
- Streaming Replication — Synchrone Replikation zwischen den Clustern
- WAL Archive — S3-kompatibles Archiv für Point-in-Time-Recovery
- Test-Gate — Der Test wird übersprungen, wenn keine DR-Konfiguration vorhanden ist
Zusammenfassung
/pg-dr ist der Beweis, dass Disaster Recovery nicht nur ein Konzept in einem Runbook sein muss. Ein validierter, automatisierter DR-Drill in unter 4 Sekunden — cross-cluster, mit Promote, Demote und Verifizierung. Führen Sie ihn wöchentlich aus und schlafen Sie ruhiger.