Skip to content

fix: PostgreSQL krijgt dezelfde probes als MariaDB - #32

Open
MWest2020 wants to merge 1 commit into
mainfrom
fix/postgres-probes
Open

fix: PostgreSQL krijgt dezelfde probes als MariaDB#32
MWest2020 wants to merge 1 commit into
mainfrom
fix/postgres-probes

Conversation

@MWest2020

Copy link
Copy Markdown
Member

values/db/postgres.yaml had geen startupProbe. Het opstartbudget was daarmee wat
liveness toestond: initialDelaySeconds 30 + 6x10s = 90 seconden. Krapper dan MariaDB
had, en dat budget van 150s bleek op 2026-08-04 al te kort — twee MariaDB-tenants
kwamen in een oneindige CrashLoopBackOff omdat de kubelet de container afschoot
voordat de start klaar was.

PostgreSQL doet bij een onreine stop WAL-recovery voordat hij connecties opent. Hoe
groter de database, hoe reeler dat dit over 90 seconden gaat. Wordt hij daar middenin
afgeschoten, dan begint recovery elke ronde opnieuw en komt hij nooit klaar.
Crash-safe, maar permanent down — en van buiten niet te onderscheiden van de storing
van gisteren.

Nu 30s + 60x10s = 10 minuten, gelijk aan MariaDB en aan de platform-standaard voor de
Nextcloud-container. Liveness op initialDelaySeconds 30, dus strakker dan het
chart-budget van 90s: een dode database wordt sneller opgemerkt, niet langzamer.

Geverifieerd met helm template per profiel: postgres en mariadb geven beide
startup=630s liveness=30s, external levert terecht geen database.

docs/HAVEN-COMPLIANCE.md stelde dit als openstaand punt; die sectie klopt nu.

Bewust pas nu: dit raakt 48 accept- en 26 productie-tenants, en de canary-poort keurde
tot vandaag niets (probe groen 31s na de merge terwijl Argo's reconcile 180s is). Die
is eerst gerepareerd, zodat dit de eerste wijziging is die langs een poort komt met
een canary die de wijziging daadwerkelijk had.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

values/db/postgres.yaml had geen startupProbe. Het opstartbudget was daarmee wat
liveness toestond: initialDelaySeconds 30 + 6x10s = 90 seconden. Krapper dan MariaDB
had, en dat budget van 150s bleek op 2026-08-04 al te kort — twee MariaDB-tenants
kwamen in een oneindige CrashLoopBackOff omdat de kubelet de container afschoot
voordat de start klaar was.

PostgreSQL doet bij een onreine stop WAL-recovery voordat hij connecties opent. Hoe
groter de database, hoe reeler dat dit over 90 seconden gaat. Wordt hij daar middenin
afgeschoten, dan begint recovery elke ronde opnieuw en komt hij nooit klaar.
Crash-safe, maar permanent down — en van buiten niet te onderscheiden van de storing
van gisteren.

Nu 30s + 60x10s = 10 minuten, gelijk aan MariaDB en aan de platform-standaard voor de
Nextcloud-container. Liveness op initialDelaySeconds 30, dus strakker dan het
chart-budget van 90s: een dode database wordt sneller opgemerkt, niet langzamer.

Geverifieerd met helm template per profiel: postgres en mariadb geven beide
startup=630s liveness=30s, external levert terecht geen database.

docs/HAVEN-COMPLIANCE.md stelde dit als openstaand punt; die sectie klopt nu.

Bewust pas nu: dit raakt 48 accept- en 26 productie-tenants, en de canary-poort keurde
tot vandaag niets (probe groen 31s na de merge terwijl Argo's reconcile 180s is). Die
is eerst gerepareerd, zodat dit de eerste wijziging is die langs een poort komt met
een canary die de wijziging daadwerkelijk had.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@MWest2020 MWest2020 added change/platform Platform- of gemengde wijziging: raakt shared values, Argo-wiring, scripts of policy merge-wave/1 Geplande merge na 17:00: wave 1 (lager gaat eerst) labels Aug 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

change/platform Platform- of gemengde wijziging: raakt shared values, Argo-wiring, scripts of policy merge-wave/1 Geplande merge na 17:00: wave 1 (lager gaat eerst)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant