Frequently, when one redeploys an already running cluster after changing something, the Postgres WAL (write ahead log) will get corrupted, preventing the start of the new container. Which in turn prevents the whole monitoring task from starting.
A workaround is to redeploy (again) running pg_resetwal /var/lib/postgresql in the Postgres container as the postgres user, and then trying again. That is very time consuming.
We would need to find a way to safely redeploy the cluster without corrupting Postgres data.
Frequently, when one redeploys an already running cluster after changing something, the Postgres WAL (write ahead log) will get corrupted, preventing the start of the new container. Which in turn prevents the whole monitoring task from starting.
A workaround is to redeploy (again) running
pg_resetwal /var/lib/postgresqlin the Postgres container as thepostgresuser, and then trying again. That is very time consuming.We would need to find a way to safely redeploy the cluster without corrupting Postgres data.