You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 5, 2022. It is now read-only.
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT
Version of Helm and Kubernetes: 1.10
Which chart: stable/influxdb
What happened: When a WAL recovery lasts too much the liveness probe fails, causing a CrashLoopbackOff error.
What you expected to happen: The liveness probe shouldn't fail while the db is recovering (only readiness probe). Otherwise the DB will never be able to recover.
How to reproduce it (as minimally and precisely as possible):
Install stable/influxdb
Feed the DB with a large amount of data, and terminate the DB pod abruptly while feeding the DB
Back-off restarting keeps happening because liveness probe returns connection refused. This leads the container to restart and from scratch the WAL recovery.
Exited Containers that are restarted by the kubelet are restarted with an exponential back-off delay (10s, 20s, 40s …) capped at five minutes, and is reset after ten minutes of successful execution
If it's not too much data (<5 min) the WAL will be completed, but then the container restarts after the wait period.
At least increasing the default initialDelaySeconds seems to be necessary for even basic use cases...
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT
Version of Helm and Kubernetes: 1.10
Which chart: stable/influxdb
What happened: When a WAL recovery lasts too much the liveness probe fails, causing a CrashLoopbackOff error.
What you expected to happen: The liveness probe shouldn't fail while the db is recovering (only readiness probe). Otherwise the DB will never be able to recover.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know: duplicate of helm/charts#10405
The text was updated successfully, but these errors were encountered: