cloudnative-pg / cloudnative-pg/cloudnative-pg

feat: emit ReplicaCaughtUp event when streaming replica lag drops to zero

Aperta
#11,292 0 commenti 1 reazione 0 assegnatari Vedi su GitHub
Lingua principale
Go
Stelle
9.3k
Fork
759
Merge medio
3g 5h
PR unite (30g)
51

Descrizione

## Problem

When a streaming replica recovers from replication lag — after a network partition, pod restart, or heavy write burst — there is currently no Kubernetes event or signal emitted. Operators must continuously poll `pg_stat_replication` or watch metrics dashboards to know when a replica has fully caught up to the primary. In environments with many clusters and replicas, this creates an observability gap that makes incident response slower and harder to automate.

## Proposed Solution

Emit a `Normal/ReplicaCaughtUp` Kubernetes event on the `Cluster` object the moment a streaming replica's `replay_lag` transitions from non-zero to zero. The event fires exactly once per transition per replica, giving operators a precise, single-fire signal for replication recovery.

This integrates naturally with:
- `kubectl get events` / `kubectl describe cluster`
- Alertmanager and any event-driven alerting pipeline
- Kubernetes event exporters

## Example event output

```
Normal ReplicaCaughtUp cluster/pg-cluster Replica pg-cluster-2 has caught up to the primary
```

## Implementation approach

- Track per-replica lag state in an in-memory map on `ClusterReconciler` (never written to the public CRD status, so the API schema stays clean)
- Call `detectAndEmitReplicaCaughtUpEvents` from `updateClusterStatusThatRequiresInstancesState` on every reconcile loop
- Protect the tracker with a `sync.Mutex` for safe concurrent reconciliation of multiple clusters
- Zero API changes — `InstanceReportedState` and all public types are untouched

A PR with implementation and unit tests is ready: #11291

Guida per i contributori

Apri la guida per i contributori

Direzione di ricerca

Inizia esaminando PR #11291 e l’entry point updateClusterStatusThatRequiresInstancesState, quindi segui il modo in cui detectAndEmitReplicaCaughtUpEvents tiene traccia del ritardo delle repliche ed emette eventi Kubernetes. Usa gli unit test inclusi nell’implementazione per verificare che venga emesso un singolo evento quando replay_lag passa da un valore diverso da zero a zero per ogni replica.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
go, kubernetes, postgresql
Ambito
databases, devops
Tipo di issue
Funzionalità
Difficoltà
4/5
Tempo stimato
3-5 giorni
Stato di attività
Ferma
Chiarezza
Specificata chiaramente
Idoneità per principianti
25/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.