proomt

Search

Search posts, papers, and topics

All posts

PlanetScaleSimeon Griggs5 min readintermediate

Blocking cutovers to save replication slots

Read on planetscale.com

Summary

PlanetScale’s Postgres operator blocks cutovers that would leave logical replication slots out‑of‑sync. By requiring `failover=true` on slots and turning on `hot_standby_feedback` and `sync_replication_slots`, the operator ensures slots survive a primary promotion, preventing downstream CDC consumers from losing data.

  • Logical replication slots must be configured with `failover = true` to be copied to standbys.
  • Enable `hot_standby_feedback` and `sync_replication_slots` on the cluster so slot state is kept valid on replicas.
  • PlanetScale’s Kubernetes operator watches `pg_replication_slots` and blocks planned cutovers (resize, config change) until all named slots report ready.
  • Operators must list the names of required slots in the dashboard (Clusters → Parameters → Logical slot name) so the system knows what to protect.

Promoting a replica that lacks up‑to‑date logical slots silently breaks CDC pipelines, causing data loss or stalls for downstream services. Automating the safety check removes a class of human error during failover or maintenance.

6/10
postgreskuberneteshigh availabilityoperatorlogical replication

Related reading

  1. Postgres on NVMe: performance and the convergence of transactions and analytics

    Local NVMe storage cuts Postgres I/O latency from ms to µs, yielding ~9× higher TPS and 10× lower transaction latency on a 482 GiB pgbench workload. The gain comes from reduced IO wait, not more CPU work. To retain durability, combine NVMe with quorum synchronous replication and continuous WAL archiving (WAL‑G). For analytics, offload scans to ClickHouse via WAL‑based CDC (pg_clickhouse or the ne…

    ClickHouseclickhouse.com8 min

  2. The architecture of Neki

    Neki is PlanetScale’s sharding layer for vanilla PostgreSQL that presents a single Postgres endpoint while routing queries across a fleet of Postgres instances. It does this with a set of tightly‑coupled components—Router, Sidecar, PostgresManager, Admin, Operator, and etcd‑backed Data Topology—each handling a specific piece of the scaling, failover, and query‑planning puzzle.

    PlanetScaleplanetscale.com8 min

  3. Worker Backpressure (Part 1)

    Canva added a lightweight, local backpressure loop to its queue worker library that monitors per‑message success/failure, computes a backoff factor against a configurable failure‑rate set‑point, and throttles the worker’s concurrency. In two real incidents the mechanism kept failure rates under 2 % fleet‑wide, limited DLQ growth to a handful of messages, and maintained throughput without manual i…

    Canvacanva.dev10 min

  4. Introducing TIN: full-text search for Postgres

    PlanetScale’s TIN is a new PostgreSQL extension that implements a full‑text search index supporting Boolean, phrase, span, fuzzy, wildcard, regex, case/accent folding, COUNT(*) and BM25 top‑k queries. In a suite of benchmarks on an i7i.8xlarge EC2 instance (8 vCPU, 32 GB RAM), TIN built in 8 min 10 s (50.7 GB index) and outperformed ParadeDB, pg_textsearch and the built‑in GIN index by large marg…

    PlanetScaleplanetscale.com15 minHN20175

  5. pgAssistant 3.8.0 : continuous improvement loop for Postgres

    pgAssistant 3.8.0 expands from a tuning advisor to a continuous PostgreSQL improvement platform, adding a Collector that records historical workload and environment data. It lets teams run an Observe‑Diagnose‑Prioritize‑Plan‑Implement‑Measure loop, compare consecutive snapshots, and measure the impact of applied recommendations.

    PostgreSQLpostgresql.org1 minrelease