Le 04/09 à 02:42Z, sur pi3, /sys/fs/ext4/sdk enregistre deux erreurs (errors_count=2) : d'abord ext4_check_bdev_write_error, puis ext4_journal_check_start. ext4 a abandonné son journal sur le volume pvc-1251909b-3cef-40c6-881c-3bb6e929a596 (16 Gi).
Depuis, clickhouse-0 journalise environ 1 500 errno: 5, Input/output error par 10 min : fusions MergeTree, create_directories.
Les lectures échouent aussi. Le pod neuf de Plausible (plausible-5854f59b7b-…) est en Init:CrashLoopBackOff depuis 8 h, avec 99 redémarrages : son init-database plante sur Cannot open file …/version.bin: errno: 5 pendant la migration.
C'est pour cela qu'ArgoCD affiche plausible en Degraded.
Un redémarrage de conteneur ne démonte pas le volume : c'est le même mécanisme que #50 (MinIO) et #51 (Prometheus).
Ce que fait la PR
clickhouse/clickhouseValues.yaml → affinity :
l'exclusion requise de pi2 est conservée ;
ajout d'une préférence de poids 100 pour pi1.
Pourquoi pi1 :
pas pi3, qui porte le montage mort : recréé sur le même nœud, le pod pourrait reprendre ce montage de staging ;
pas pi2 non plus, tant que sa mémoire n'est pas soulagée (tools#52) ;
à 10:00Z, pi1 disposait de 2,6 Gi, et ClickHouse en consomme 529 Mi.
Rendu kubectl kustomize --enable-helm clickhouse/ comparé avant/après : seul le bloc preferredDuringSchedulingIgnoredDuringExecution du StatefulSet change.
Le StatefulSet est en RollingUpdate avec un seul réplica : le pod est supprimé, puis recréé.
Ce qu'elle ne fait pas
Aucune suppression de pod, PVC, volume, réplique ou donnée. Aucun fsck manuel. Si le remontage échoue sur des erreurs ext4, on s'arrête.
Les insertions refusées depuis le 04/09 ne reviendront pas. Le relevé du trou suivra dans tools#53, une fois le volume remonté.
Accord du fondateur : « Oui, même remède, sans perte » (2026-09-15).
## Cause (tools#53)
- Le **04/09 à 02:42Z**, sur pi3, `/sys/fs/ext4/sdk` enregistre deux erreurs (`errors_count=2`) : d'abord `ext4_check_bdev_write_error`, puis `ext4_journal_check_start`. ext4 a abandonné son journal sur le volume `pvc-1251909b-3cef-40c6-881c-3bb6e929a596` (16 Gi).
- Depuis, `clickhouse-0` journalise environ 1 500 `errno: 5, Input/output error` par 10 min : fusions MergeTree, `create_directories`.
- **Les lectures échouent aussi.** Le pod neuf de Plausible (`plausible-5854f59b7b-…`) est en `Init:CrashLoopBackOff` depuis 8 h, avec 99 redémarrages : son `init-database` plante sur `Cannot open file …/version.bin: errno: 5` pendant la migration.
- C'est pour cela qu'ArgoCD affiche `plausible` en **Degraded**.
- Un redémarrage de conteneur ne démonte pas le volume : c'est le même mécanisme que #50 (MinIO) et #51 (Prometheus).
## Ce que fait la PR
- `clickhouse/clickhouseValues.yaml` → `affinity` :
- l'exclusion **requise** de pi2 est conservée ;
- ajout d'une **préférence de poids 100 pour pi1**.
- **Pourquoi pi1** :
- pas pi3, qui porte le montage mort : recréé sur le même nœud, le pod pourrait reprendre ce montage de staging ;
- pas pi2 non plus, tant que sa mémoire n'est pas soulagée (tools#52) ;
- à 10:00Z, pi1 disposait de 2,6 Gi, et ClickHouse en consomme 529 Mi.
- Rendu `kubectl kustomize --enable-helm clickhouse/` comparé avant/après : **seul le bloc `preferredDuringSchedulingIgnoredDuringExecution` du StatefulSet change**.
- Le StatefulSet est en `RollingUpdate` avec un seul réplica : le pod est supprimé, puis recréé.
## Ce qu'elle ne fait pas
- Aucune suppression de pod, PVC, volume, réplique ou donnée. Aucun `fsck` manuel. Si le remontage échoue sur des erreurs ext4, on s'arrête.
- Les insertions refusées depuis le 04/09 ne reviendront pas. Le relevé du trou suivra dans tools#53, une fois le volume remonté.
Accord du fondateur : « Oui, même remède, sans perte » (2026-09-15).
Refs arcodange-org/tools#53
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Le 04/09 à 02:42Z, ext4 a abandonné son journal sur le volume de
ClickHouse, attaché sur pi3. Depuis, onze jours d'`Input/output error`
sur les fusions et les lectures, et le migrateur de Plausible plante en
init (CrashLoopBackOff, application ArgoCD `plausible` Degraded). Un
redémarrage de conteneur ne démonte pas le volume.
Préférence de poids 100 pour pi1, pi2 toujours exclu : recréé sur un
autre nœud, le volume est détaché puis rattaché, et ext4 rejoue son
journal.
Refs arcodange-org/tools#53
Co-Authored-By: Claude Opus 5 <[email protected]>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Cause (tools#53)
/sys/fs/ext4/sdkenregistre deux erreurs (errors_count=2) : d'abordext4_check_bdev_write_error, puisext4_journal_check_start. ext4 a abandonné son journal sur le volumepvc-1251909b-3cef-40c6-881c-3bb6e929a596(16 Gi).clickhouse-0journalise environ 1 500errno: 5, Input/output errorpar 10 min : fusions MergeTree,create_directories.plausible-5854f59b7b-…) est enInit:CrashLoopBackOffdepuis 8 h, avec 99 redémarrages : soninit-databaseplante surCannot open file …/version.bin: errno: 5pendant la migration.plausibleen Degraded.Ce que fait la PR
clickhouse/clickhouseValues.yaml→affinity:kubectl kustomize --enable-helm clickhouse/comparé avant/après : seul le blocpreferredDuringSchedulingIgnoredDuringExecutiondu StatefulSet change.RollingUpdateavec un seul réplica : le pod est supprimé, puis recréé.Ce qu'elle ne fait pas
fsckmanuel. Si le remontage échoue sur des erreurs ext4, on s'arrête.Accord du fondateur : « Oui, même remède, sans perte » (2026-09-15).
Refs arcodange-org/tools#53
🤖 Generated with Claude Code