docker-library / postgres

Docker Official Image packaging for Postgres
http://www.postgresql.org
MIT License
2.2k stars 1.14k forks source link

Question: Why is the /var/lib/postgresql/data directory cleared when mounting /var/lib/postgresql as volume? #1163

Closed larsderidder closed 11 months ago

larsderidder commented 11 months ago

We had an issue in our Azure K8S deployment using this image, where restarting the pod caused the database to be recreated. Upon further inspection it turned out that the /var/lib/postgresql/data directory was recreated every time the pod was restarted.

Normally when using this image, I mount a volume directly on /var/lib/postgresql/data, but in this case the pod mounted /var/lib/postgresql. The reason for this was that mounting /var/lib/postgresql/data on Azure gives an error, as Azure volumes have a lost+found file on the root of the mount point, and then Postgres complains that the data directory isn't empty and it cannot initialize the database.

Anyway, I just don't understand why this wouldn't work. Any files created directly in /var/lib/postgresql are persisted on restart. I solved it now by setting the PGDATA env variable to /var/lib/postgresql/pgdata, and that directory is properly persisted. I looked at the init_db.sh script but didn't see any reason for it to wipe the /var/lib/postgresql/data directory.

What is the reason that specific directory is cleared?

tianon commented 11 months ago

It's probably getting cleared because it's marked as a "volume" in the image metadata, so the container runtime is likely creating a new mount underneath it on every container startup if you didn't specify one explicitly.

To solve the lost+found problem, you should be able to specify that Kubernetes should create/mount a subdirectory of the volume it creates into the container (instead of mounting the root of the volume raw). Alternatively, you should be able to set PGDATA to an alternate directory to control where PostgreSQL looks for it / puts it (https://github.com/docker-library/postgres/issues/952).