If icon
Fail icon
Query icon
Return icon
Stop icon
Queries icon
LoopUntil icon
OutputValues icon
Schedule icon

Rehearse PostgreSQL failover and verify logical subscriber continuity

Rehearse PostgreSQL logical failover with identity checks, a synchronized-slot gate, native promotion and verified subscriber data.

Categories
Data

Exercise a deliberately disposable PostgreSQL 17 topology before trusting a switchover procedure. The existing subscriber must retain its identity and receive exact fixture changes after the candidate is promoted.

How it works

  1. Require explicit consent and the two expected database system identifiers.
  2. Check roles, baseline data, one ready subscription and a synchronized slot.
  3. Disable the subscriber, stop the old Docker publisher, then promote the standby.
  4. Reconnect the same subscription, mutate three records and poll for exact results.

What you get

  • A Kestra execution showing the real shutdown, promotion and consumer checks.
  • Refusal before shutdown for unexpected identities, data or slot readiness.
  • A verified fixture result with unchanged subscription and replication-origin IDs.
  • Explicit failure on timeout; no zero-data-loss or automatic rollback claim.

Who it's for

Data and platform engineers testing a PostgreSQL logical-replication switchover in an isolated, quiescent lab. This is not a production HA controller.

Why orchestrate this with Kestra

Native JDBC, Docker, conditions and bounded polling expose each phase and its evidence. PostgreSQL owns replication and promotion; Kestra sequences the drill.

Prerequisites

Kestra OSS 2.0.6, JDBC PostgreSQL and Docker plugins, and the companion disposable Docker fixture. It provides publisher, standby and subscriber DNS names, the rehearsal database/table, one failover subscription and a subscriber passfile. The Kestra worker needs access to the lab Docker socket. The fixture must have no concurrent application writers. Keep it separate from production resources.

Secrets

  • LAB_DB_PASSWORD: generated fixture password, supplied through OSS SECRET_ encoding.

Quick start

  1. Start and bootstrap the companion fixture; record both database system identifiers.
  2. Import this flow and supply those identifiers with disposable-switchover consent.
  3. Inspect the execution and independently query the subscriber's three final records.
  4. Reset the fixture before another drill. The schedule remains disabled and nonconsenting.

How to extend

Adapt a separately validated fixture to test another PostgreSQL version or HA interface. Do not reuse this shutdown mechanism for live traffic. Multiple subscribers, incomplete copies and recovery after partial promotion need new tests.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.