pg_cnpg_dr_readiness — DR-Bereitschaft messen, bevor es zu spät ist — Blog

Was macht dieses Tool?

pg_cnpg_dr_readiness berechnet einen gewichteten DR-Readiness-Score von 0 bis 100, der die tatsächliche Disaster-Recovery-Fähigkeit eines CNPG-Clusters misst. Das Tool fragt über die Kubernetes API den Status des primären und des Replica-Clusters ab — über verschiedene kubecontexts hinweg — und bewertet fünf kritische Dimensionen:

Replica Health (30 Punkte) — Sind alle Replicas im Zielcluster gesund und im Status streaming?
WAL Archive Lag (20 Punkte) — Liegt die letzte WAL-Archivierung weniger als 5 Minuten zurück?
Replication Lag (20 Punkte) — Ist der Replikations-Lag unter 10 MB?
Object Store Accessible (15 Punkte) — Ist der konfigurierte Object Store (MinIO, S3) erreichbar?
Instance Count (15 Punkte) — Läuft mindestens eine Instanz im DR-Cluster?

Das Ergebnis ist ein klarer Status: READY (Score ≥ 80), AT-RISK (Score 50–79) oder NOT-READY (Score < 50).

Wie wird es 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:

● ● ● Claude CLI — DR-Konfiguration

claude> Zeig mir den DR-Status für hubport

▶ 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)

● ● ● Claude CLI — DR-Analyse

claude> Wie ist der DR-Status für hubport?

▶ Calling tools...
→ pg_cnpg_dr_readiness {"system": "hubport", "environment": "production"}

DR-Readiness-Score: 95/100 — Status: READY

Checks:
✓ Replica Health        30/30 — 1/1 Replicas streaming
✓ WAL Archive Lag       20/20 — Letztes Archiv vor 2m 14s
✓ Replication Lag       15/20 — 4.2 MB (Schwelle: 10 MB)
✓ Object Store          15/15 — MinIO erreichbar
✓ Instance Count        15/15 — 1 Instanz aktiv im DR-Cluster

MCP Protocol (programmatisch)

● ● ● MCP Protocol — DR-Analyse

// Programmatic invocation via MCP SDK
const result = await client.callTool("pg_cnpg_dr_readiness", {"system": "hubport"});

// Response:
{
"score": 95,
"status": "READY",
"checks": [
    {
      "name": "replica_health",
      "weight": 30,
      "score": 30,
      "pass": true,
      "detail": "1/1 replicas streaming"
    },
    {
      "name": "wal_archive_lag",
      "weight": 20,
      "score": 20,
      "pass": true,
      "detail": "Last archive 2m 14s ago (< 5m threshold)"
    },
    {
      "name": "replication_lag",
      "weight": 20,
      "score": 15,
      "pass": true,
      "detail": "4.2 MB lag (< 10 MB threshold)"
    },
    {
      "name": "object_store",
      "weight": 15,
      "score": 15,
      "pass": true,
      "detail": "MinIO reachable at object-store:9000"
    },
    {
      "name": "instance_count",
      "weight": 15,
      "score": 15,
      "pass": true,
      "detail": "1 instance running in DR cluster"
    }
]
}

Was passiert unter der Haube?

Dieses Tool führt kein SQL aus. Stattdessen nutzt es die Kubernetes CustomObjectsApi, um den CNPG-Cluster-Status aus zwei verschiedenen kubecontexts abzufragen:

DR-Config laden — Liest die Master-Referenz-Konfiguration (System + Environment), um Primary- und Replica-Cluster-Koordinaten zu ermitteln
Primary-Cluster abfragen — kubectl get cluster/db-primary -n app -o json im Kontext k8s-primary
Replica-Cluster abfragen — kubectl get cluster/db-replica -n app -o json im Kontext k8s-replica
WAL-Archive prüfen — Liest .status.lastSuccessfulArchive aus dem CNPG-Cluster-Objekt
Object Store testen — Prüft die Erreichbarkeit des konfigurierten S3/MinIO-Endpoints

Die gewichtete Formel erlaubt Teilpunkte: Wenn der Replikations-Lag z.B. 4.2 MB beträgt (unter dem 10-MB-Schwellwert, aber nicht null), gibt es 15 von 20 möglichen Punkten statt der vollen 20.

Praxis-Tipp: Ein Score von 80+ bedeutet nicht, dass ein DR-Failover schmerzfrei ist — es bedeutet, dass die technischen Voraussetzungen erfüllt sind. Testen Sie den tatsächlichen Failover regelmäßig mit pg_cnpg_switchover.

Lifecycle Gates

Das Tool respektiert den Tenant-Lifecycle:

provisioning — Nur Lesezugriff (Score wird berechnet, aber keine Aktionen)
active — Voller Zugriff, alle Checks aktiv
maintenance — Blockiert, es sei denn ein Override ist gesetzt
decommissioned — Vollständig blockiert

Ausgabe im Detail

score — Gewichteter Gesamtscore von 0 bis 100
status — READY (≥ 80), AT-RISK (50–79) oder NOT-READY (< 50)
checks — Array mit 5 Einträgen, jeweils:
- name — Check-Bezeichnung (replica_health, wal_archive_lag, etc.)
- weight — Maximale Punktzahl dieses Checks
- score — Tatsächlich erreichter Score
- pass — Boolean, ob der Check bestanden wurde
- detail — Menschenlesbarer Status-Text

Was testet die Testsuite?

Die Testsuite validiert pg_cnpg_dr_readiness gegen eine Lab-Umgebung mit einem Primary-Cluster (2 Instanzen) und einem Replica-Cluster (1 Instanz) auf separaten k3s-Clustern, mit MinIO als WAL-Archiv:

● ● ● vitest run — Testsuite

✓ pg_cnpg_dr_readiness > returns score and status
✓ pg_cnpg_dr_readiness > checks array has 5 items
✓ pg_cnpg_dr_readiness > READY when all checks pass
✓ pg_cnpg_dr_readiness > NOT-READY when replica missing

Test Files 1 passed (1)
Tests 4 passed (4)
Duration 1842ms

Testdaten-Szenario

Die Lab-Umgebung besteht aus:

k8s-primary — k3s-Cluster mit CNPG-Cluster db-primary (2 Instanzen: 1 Primary + 1 Replica)
k8s-replica — Separater k3s-Cluster mit CNPG-Cluster db-replica (1 Instanz, WAL-Replay)
MinIO — Object Store für WAL-Archivierung (S3-kompatibel, Port 9000)
Zwei kubecontexts — Simuliert eine echte Multi-Cluster-DR-Topologie

Die Tests validieren, dass:

Das Ergebnis einen score (Zahl) und status (String) enthält
Das checks-Array exakt 5 Einträge hat (einer pro Dimension)
Bei gesunden Clustern der Status READY zurückgegeben wird
Bei fehlender Replica der Status auf NOT-READY wechselt

Zusammenfassung

K8s API

Datenquelle

Gewichtete Checks

Tests

read-only

Typ

pg_cnpg_dr_readiness ist das zentrale Tool für DR-Monitoring in CNPG-Umgebungen. Es ersetzt manuelles kubectl-Prüfen über mehrere Cluster hinweg durch einen einzigen, gewichteten Score, der sofort zeigt, ob ein DR-Failover technisch möglich wäre.

In Kombination mit pg_cnpg_switchover (→ tatsächliches Failover) und pg_failover_readiness (→ Replikations-Status) bildet es den Kern des /pg-dr Workflow-Skills.

pg_cnpg_dr_readiness — DR-Bereitschaft messen, bevor es zu spät ist