From 38114dfeca78710e46dd70d1d72833ff9f3056a5 Mon Sep 17 00:00:00 2001 From: "mwesterweel@hotmail.com" Date: Wed, 5 Aug 2026 21:10:25 +0200 Subject: [PATCH] fix: PostgreSQL krijgt dezelfde probes als MariaDB MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- changelog.d/0032-postgres-probes.md | 26 ++++++++++++++++ docs/HAVEN-COMPLIANCE.md | 19 +++++++----- nextcloud-platform/values/db/postgres.yaml | 35 ++++++++++++++++++++++ 3 files changed, 72 insertions(+), 8 deletions(-) create mode 100644 changelog.d/0032-postgres-probes.md diff --git a/changelog.d/0032-postgres-probes.md b/changelog.d/0032-postgres-probes.md new file mode 100644 index 0000000..aa26137 --- /dev/null +++ b/changelog.d/0032-postgres-probes.md @@ -0,0 +1,26 @@ +### Gewijzigd — 2026-08-05 (PostgreSQL krijgt dezelfde probes als MariaDB) + +`values/db/postgres.yaml` had geen `startupProbe`. Het opstartbudget was daarmee wat +liveness toestond: `initialDelaySeconds: 30` + 6×10s = **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 reëler dat dit over 90 seconden gaat. Wordt hij daar middenin +afgeschoten, dan begint recovery elke ronde opnieuw en komt hij nooit klaar. Data +raakt niet corrupt — PostgreSQL is crash-safe — maar de tenant blijft down, en dat +ziet er van buiten precies zo uit als de storing van gisteren. + +Nu 30s + 60×10s = 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`, en `external` levert terecht geen database. + +Dit is bewust pas nu gedaan. Het raakt 48 accept- en 26 productie-tenants, en op +2026-08-05 bleek de canary-poort niets te keuren (probe groen 31s na de merge terwijl +Argo's reconcile 180s is). Die poort is eerst gerepareerd — timing, een streak, en +aankomst-verificatie via `/status.php` — zodat deze wijziging de eerste is die er +langs komt met een canary die de wijziging daadwerkelijk had. diff --git a/docs/HAVEN-COMPLIANCE.md b/docs/HAVEN-COMPLIANCE.md index b05aa58..83e31b1 100644 --- a/docs/HAVEN-COMPLIANCE.md +++ b/docs/HAVEN-COMPLIANCE.md @@ -64,20 +64,23 @@ Het opstartbudget is dan wat liveness toestaat, en dat is kort: MariaDB kreeg `initialDelaySeconds: 120` + 3×10s ≈ 150s, PostgreSQL `initialDelaySeconds: 30` + 6×10s = 90s (gemeten via `helm template` op chart 8.9.0). Daarna schiet de kubelet de container af; bij een trage of hangende start levert dat een -CrashLoopBackOff op in plaats van één zichtbare fout. Voor MariaDB is dat -expliciet rechtgezet: +CrashLoopBackOff op in plaats van één zichtbare fout. Voor **beide** in-cluster +engines is dat expliciet rechtgezet: ```yaml -# values/db/mariadb.yaml +# values/db/mariadb.yaml én values/db/postgres.yaml primary.startupProbe: { enabled: true, initialDelaySeconds: 30, periodSeconds: 10, failureThreshold: 60 } primary.livenessProbe: { enabled: true, initialDelaySeconds: 30, periodSeconds: 10, failureThreshold: 3 } ``` -**Openstaand:** `values/db/postgres.yaml` heeft deze correctie nog niet en draait -dus op die 90 seconden. PostgreSQL doet bij een onreine stop ook WAL-recovery, -dus hetzelfde risico geldt daar — met een krapper budget dan MariaDB had. Dit is -bewust buiten deze wijziging gehouden omdat het 55 van de 77 tenants raakt en een -eigen sync-window verdient. Zie CHANGELOG 2026-08-05. +Gemeten met `helm template` per profiel: beide geven een opstartbudget van 630s en +liveness op 30s. Het `external`-profiel levert geen in-cluster database en heeft dus +geen database-probes. + +PostgreSQL liep tot 2026-08-05 op 30s + 6×10s = 90 seconden, krapper dan MariaDB's +150s. Bij een onreine stop doet PostgreSQL WAL-recovery voordat hij connecties +opent; wordt hij daar middenin afgeschoten, dan begint recovery elke ronde opnieuw. +Crash-safe, maar permanent down. ## 4. Resource governance diff --git a/nextcloud-platform/values/db/postgres.yaml b/nextcloud-platform/values/db/postgres.yaml index d34694f..cd52c2b 100644 --- a/nextcloud-platform/values/db/postgres.yaml +++ b/nextcloud-platform/values/db/postgres.yaml @@ -26,6 +26,41 @@ postgresql: adminPasswordKey: postgres-password userPasswordKey: db-password primary: + # ------------------------------------------------------------------------- + # Probes — zelfde reden als bij values/db/mariadb.yaml + # ------------------------------------------------------------------------- + # Zonder startupProbe is het opstartbudget wat liveness toestaat, en dat was + # hier `initialDelaySeconds: 30` + 6×10s = 90 seconden. Krapper dan MariaDB had + # (150s), en dat budget 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 reëler dat dit over 90 seconden gaat; wordt + # hij daar middenin afgeschoten, dan begint recovery elke ronde opnieuw en komt + # hij nooit klaar. Data raakt niet corrupt — PostgreSQL is crash-safe — maar de + # tenant blijft down. + # + # Budget hieronder: 30s + (60 × 10s) = 10 minuten, gelijk aan MariaDB en aan de + # platform-standaard voor de Nextcloud-container. + startupProbe: + enabled: true + initialDelaySeconds: 30 + periodSeconds: 10 + timeoutSeconds: 5 + failureThreshold: 60 + successThreshold: 1 + + # Pas scherp zodra de startupProbe geslaagd is. Dat is strakker dan het + # chart-budget van 90s en merkt een dode database dus sneller op. + livenessProbe: + enabled: true + initialDelaySeconds: 30 + periodSeconds: 10 + timeoutSeconds: 5 + failureThreshold: 3 + successThreshold: 1 + initdb: scripts: 01-enable-extensions.sql: |