I am desperately trying to get a Docker project I have inherited up and running, and Docker is giving me no end of problems. When trying to start up my containers I get the following error on my Postgresql container:
FATAL: "/var/lib/postgresql/data" is not a valid data directory
DETAIL: File "/var/lib/postgresql/data/PG_VERSION" does not contain valid data.
HINT: You might need to initdb.
The project is a Rails project using Redis, ElasticSearch, and Sidekiq containers as well - those all load fine.
docker-compose.yml:
postgres:
image: postgres:9.6.2
environment:
POSTGRES_USER: $PG_USER
POSTGRES_PASSWORD: $PG_PASS
ports:
- '5432:5432'
volumes:
- postgres:/var/lib/postgresql/data
/var/lib/postgresql/data is owned by the postgres user (as it should be I believe) and the postgresql service starts up and runs fine on its own.
I have tried running initdb from the /usr/lib/postgresql/9.6/bin directory, as well as from docker (from docker it doesn't seem to persist or even create anything... if anyone knows why I would be interested in knowing)
The contents of the /var/lib/postgresql/data directory:
drwxrwxrwx 19 postgres postgres 4096 Jun 28 20:41 .
drwxr-xr-x 5 postgres postgres 4096 Jun 28 20:41 ..
drwx------ 5 postgres postgres 4096 Jun 28 20:41 base
drwx------ 2 postgres postgres 4096 Jun 28 20:41 global
drwx------ 2 postgres postgres 4096 Jun 28 20:41 pg_clog
drwx------ 2 postgres postgres 4096 Jun 28 20:41 pg_commit_ts
drwx------ 2 postgres postgres 4096 Jun 28 20:41 pg_dynshmem
-rw------- 1 postgres postgres 4468 Jun 28 20:41 pg_hba.conf
-rw------- 1 postgres postgres 1636 Jun 28 20:41 pg_ident.conf
drwx------ 4 postgres postgres 4096 Jun 28 20:41 pg_logical
drwx------ 4 postgres postgres 4096 Jun 28 20:41 pg_multixact
drwx------ 2 postgres postgres 4096 Jun 28 20:41 pg_notify
drwx------ 2 postgres postgres 4096 Jun 28 20:41 pg_replslot
drwx------ 2 postgres postgres 4096 Jun 28 20:41 pg_serial
drwx------ 2 postgres postgres 4096 Jun 28 20:41 pg_snapshots
drwx------ 2 postgres postgres 4096 Jun 28 20:41 pg_stat
drwx------ 2 postgres postgres 4096 Jun 28 20:41 pg_stat_tmp
drwx------ 2 postgres postgres 4096 Jun 28 20:41 pg_subtrans
drwx------ 2 postgres postgres 4096 Jun 28 20:41 pg_tblspc
drwx------ 2 postgres postgres 4096 Jun 28 20:41 pg_twophase
-rw------- 1 postgres postgres 4 Jun 28 20:41 PG_VERSION
drwx------ 3 postgres postgres 4096 Jun 28 20:41 pg_xlog
-rw------- 1 postgres postgres 88 Jun 28 20:41 postgresql.auto.conf
-rw------- 1 postgres postgres 22267 Jun 28 20:41 postgresql.conf
PG_VERSION contains 9.6
Any help is much appreciated.
you're changing default postgresql data path hence you need to initialize the database. try this
volumes:
- ./init.sql:/docker-entrypoint-initdb.d/init.sql
here is the init.sql file
CREATE USER docker;
CREATE DATABASE docker;
GRANT ALL PRIVILEGES ON DATABASE docker TO docker;
I had the same issue, I restarted Docker daemon and even restarted the machine, but didn't fix the issue.
The path /var/lib/postgresql/data was not even on the FS.
Note: Performing a docker ps was not showing the postgresql container as running.
Solution (docker-compose):
Close postgres container:
docker-compose -f <path_to_my_docker_compose_file.yaml> down postgres
Start postgres container:
docker-compose -f <path_to_my_docker_compose_file.yaml> -d up postgres
-- That did the trick! --
Solution (docker):
docker stop <postgres_container>
docker start <postgres_container>
Another solution that you can try:
initdb <temporary_volum_folder>
Example:
initdb /tmp/postgres
docker-compose -f <path_to_my_docker_compose_file.yaml> -d up postgres
or
initdb /tmp/postgres
docker start <postgres_container>
Note:
In my case the postgres image is defined in docker-compose.yaml file, and it can be observed I don't define PG_DAT nor PG_VERSION and the container runs ok.
postgres:
image: postgres:9.6.14
container_name: postgres
environment:
POSTGRES_USER: 'pg12345678'
POSTGRES_PASSWORD: 'pg12345678'
ports:
- "5432:5432"
So when have postgres:/var/lib/postgresql/data, it's going to mount /var/lib/postgresql/data to a docker data volume called postgres. Docker data volumes are all stored together in a location that varies depending on the OS.
Try changing it to ./postgres to have it create a directory called postgres relative to your working directory.
Since the source is changing it will recreate the database, and I'd be willing to be fix the error your seeing. If not, it could be a permission issue on the host os.
Related
I have specified docker-compose.yml file with some volumes to mount. Here is example:
backend-move:
container_name: backend-move
environment:
APP_ENV: prod
image: backend-move:latest
logging:
options:
max-size: 250m
ports:
- 8080:8080
tty: true
volumes:
- php_static_logos:/app/public/images/logos
- ./volumes/nginx-php/robots.txt:/var/www/html/public/robots.txt
- ./volumes/backend/mysql:/app/mysql
- ./volumes/backend/httpd/welcome.conf:/etc/httpd/conf.d/welcome.conf
After I run podman-compose up -d and go to container through docker exec -it backend-move bash
I have this crazy permissions (??????????) on mounted files:
bash-4.4$ ls -la
ls: cannot access 'welcome.conf': Permission denied
total 28
drwxrwxrwx. 2 root root 114 Apr 21 12:29 .
drwxrwxrwx. 5 root root 105 Apr 21 12:29 ..
-rwxrwxrwx. 1 root root 400 Mar 21 17:33 README
-rwxrwxrwx. 1 root root 2926 Mar 21 17:33 autoindex.conf
-rwxrwxrwx. 1 root root 1517 Apr 21 12:29 php.conf
-rwxrwxrwx. 1 root root 8712 Apr 21 12:29 ssl.conf
-rwxrwxrwx. 1 root root 1252 Mar 21 17:27 userdir.conf
-?????????? ? ? ? ? ? welcome.conf
Any suggestions?
[root#45 /]# podman-compose --version
['podman', '--version', '']
using podman version: 3.4.2
podman-composer version 1.0.3
podman --version
podman version 3.4.2
facing the exact same issue, although on macos with the podman machine, since the parent dir has been mounted on the podman-machine, I do get the write permissions.
Although, on linux, it just fails as in your example.
To fix my issue, I had to add:
privileged: true
I want to know why my mongo docker not writing data to local foler. I run my mongo docker with this command:
(/data/db seems to be the mongdo docker's data storage position, and /data/docker/mongo_volume is the folder in the "host" machine)
sudo docker run -it -v /data/db:/data/docker/mongo_volume -d mongo
When the mongo docker successfully started in my host , $docker ps looks like good:
u#VM-0-9-ubuntu:/data/docker/mongo_volume$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5848da7562a3 mongo "docker-entrypoint.s…" 10 minutes ago Up 10 minutes 0.0.0.0:27017->27017/tcp, :::27017->27017/tcp sleepy_clarke
and $ docker inspect <container_id> shows the mounted volume:
"Mounts": [
{
"Type": "bind",
"Source": "/data/db",
"Destination": "/data/docker/mongo_volume",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
},
and I check the dockers (in docker shell) /data/db folder, everything looks good:
ls -al
total 716
drwxr-xr-x 4 mongodb mongodb 4096 Mar 25 00:38 .
drwxr-xr-x 1 root root 4096 Mar 25 00:28 ..
-rw------- 1 mongodb mongodb 50 Mar 25 00:28 WiredTiger
-rw------- 1 mongodb mongodb 21 Mar 25 00:28 WiredTiger.lock
-rw------- 1 mongodb mongodb 1472 Mar 25 00:38 WiredTiger.turtle
-rw------- 1 mongodb mongodb 94208 Mar 25 00:38 WiredTiger.wt
-rw------- 1 mongodb mongodb 4096 Mar 25 00:28 WiredTigerHS.wt
-rw------- 1 mongodb mongodb 36864 Mar 25 00:34 _mdb_catalog.wt
-rw------- 1 mongodb mongodb 20480 Mar 25 00:29 collection-0--6476415430291015248.wt
-rw------- 1 mongodb mongodb 65536 Mar 25 00:34 collection-11--6476415430291015248.wt
-rw------- 1 mongodb mongodb 20480 Mar 25 00:29 collection-2--6476415430291015248.wt
-rw------- 1 mongodb mongodb 4096 Mar 25 00:28 collection-4--6476415430291015248.wt
-rw------- 1 mongodb mongodb 20480 Mar 25 00:33 collection-7--6476415430291015248.wt
-rw------- 1 mongodb mongodb 225280 Mar 25 00:33 collection-9--6476415430291015248.wt
drwx------ 2 mongodb mongodb 4096 Mar 25 00:39 diagnostic.data
-rw------- 1 mongodb mongodb 20480 Mar 25 00:29 index-1--6476415430291015248.wt
-rw------- 1 mongodb mongodb 73728 Mar 25 00:33 index-10--6476415430291015248.wt
-rw------- 1 mongodb mongodb 20480 Mar 25 00:34 index-12--6476415430291015248.wt
-rw------- 1 mongodb mongodb 20480 Mar 25 00:29 index-3--6476415430291015248.wt
-rw------- 1 mongodb mongodb 4096 Mar 25 00:28 index-5--6476415430291015248.wt
-rw------- 1 mongodb mongodb 4096 Mar 25 00:28 index-6--6476415430291015248.wt
-rw------- 1 mongodb mongodb 20480 Mar 25 00:33 index-8--6476415430291015248.wt
drwx------ 2 mongodb mongodb 4096 Mar 25 00:28 journal
-rw-r--r-- 1 root root 0 Mar 25 00:29 lueluelue
-rw------- 1 mongodb mongodb 2 Mar 25 00:28 mongod.lock
-rw------- 1 mongodb mongodb 36864 Mar 25 00:35 sizeStorer.wt
-rw------- 1 mongodb mongodb 114 Mar 25 00:28 storage.bson
However, here comes the problem: I found there's nothing in my "host machine"'s /data/docker/mongo_volume:
ubuntu#VM-0-9-ubuntu:/data/docker/mongo_volume$ ll
total 8
drwxr-xr-x 2 root root 4096 Mar 20 13:46 ./
drwxr-xr-x 3 root root 4096 Mar 20 13:46 ../
So anyone could give me a clue? thanks a lot!
your docker command is incorrect, you should place -v <host_folder>:<container_folder>, e.g.
sudo docker run -it -v /data/docker/mongo_volume:/data/db -d mongo
I'm having trouble restoring a postgres database volume with docker-compose.
Here are the steps:
1. Backuping the volume:
$ docker run --rm --volumes-from rootdir_myapp-db_1 \
-v /mnt/data/dbbackups:/backup ubuntu tar cvf /backup/backup.tar /var/lib/postgresql/data
2. Creating a volume (which already has the correct name to be used with docker-compose after):
$ docker volume create folder_test-db
3. Restoring the database in that volume:
$ docker run --rm -v folder_test-db:/recover \
-v /mnt/data/dbbackups/:/backup ubuntu bash \
-c "cd /recover && tar xvf /backup/backup.tar"
Then,
$ cd /path/to/restore/test/folder
$ docker-compose up
is giving:
Creating network "folder_default" with the default driver
Creating folder_test-db_1 ... done
Attaching to folder_test-db_1
test-db_1 | initdb: error: directory "/var/lib/postgresql/data" exists but is not empty
test-db_1 | If you want to create a new database system, either remove or empty
test-db_1 | the directory "/var/lib/postgresql/data" or run initdb
test-db_1 | with an argument other than "/var/lib/postgresql/data".
test-db_1 | The files belonging to this database system will be owned by user "postgres".
test-db_1 | This user must also own the server process.
test-db_1 |
test-db_1 | The database cluster will be initialized with locale "en_US.utf8".
test-db_1 | The default database encoding has accordingly been set to "UTF8".
test-db_1 | The default text search configuration will be set to "english".
test-db_1 |
test-db_1 | Data page checksums are disabled.
test-db_1 |
folder_test-db_1 exited with code 1
Here's the compose file content:
version: '3.8'
volumes:
test-db: {}
services:
test-db:
image: postgres:12.3
environment:
POSTGRES_DB: myapp-db
POSTGRES_USER: user
POSTGRES_PASSWORD: password
volumes:
- test-db:/var/lib/postgresql/data
ports:
- 5432:5432
The postgres image version is the exact same than the one of the original container I have dumped the volume from.
Edit
I found a trick, but it didn't work either:
Instead of trying to spin up the new compose file after having restoring the database to a new volume, I just did the opposite;
spin up the compose file; this will init a new postgres database with the user given in the compose file,
stop the container,
do the restore, now on a volume which already exists because it was initialized by the first step,
restart the container.
The database got created, the role is correct;
user=# \conninfo
You are connected to database "myapp-db" as user "user" via socket in "/var/run/postgresql" at port "5432".
But heck, where are the data ?! :
user=# \dt
Did not find any relations.
Question
How could I get my database back with docker-compose?
Because in my original app, when the db already exists, docker-compose skips the init step and goes on with the existing content. I wish I could have the same behaviour after a restore, especially when it was done with the help of the docker daemon itself!
Edit
This is the part of the compose file (located in rootdir) that build the original volume of my app's databse, no fancy stuff in there I guess:
version: "3.5"
services:
myapp-db:
image: postgres:12.3
environment:
POSTGRES_DB: myapp-db
POSTGRES_USER: user
POSTGRES_PASSWORD: password
volumes:
- myapp-db-data:/var/lib/postgresql/data
networks:
- myapp
ports:
- 5433:5432
volumes:
myapp-db-data:
Here is the content of /var/lib/postgresql/data of that original container:
# ls -larth /var/lib/postgresql/data
total 132K
-rw------- 1 postgres postgres 3 Feb 6 15:13 PG_VERSION
drwx------ 2 postgres postgres 4.0K Feb 6 15:13 pg_twophase
drwx------ 2 postgres postgres 4.0K Feb 6 15:13 pg_tblspc
drwx------ 2 postgres postgres 4.0K Feb 6 15:13 pg_snapshots
drwx------ 2 postgres postgres 4.0K Feb 6 15:13 pg_serial
drwx------ 2 postgres postgres 4.0K Feb 6 15:13 pg_replslot
drwx------ 4 postgres postgres 4.0K Feb 6 15:13 pg_multixact
drwx------ 2 postgres postgres 4.0K Feb 6 15:13 pg_dynshmem
drwx------ 2 postgres postgres 4.0K Feb 6 15:13 pg_commit_ts
-rw------- 1 postgres postgres 26K Feb 6 15:13 postgresql.conf
-rw------- 1 postgres postgres 88 Feb 6 15:13 postgresql.auto.conf
-rw------- 1 postgres postgres 1.6K Feb 6 15:13 pg_ident.conf
drwx------ 2 postgres postgres 4.0K Feb 6 15:13 pg_xact
drwx------ 2 postgres postgres 4.0K Feb 6 15:13 pg_subtrans
-rw------- 1 postgres postgres 4.5K Feb 6 15:13 pg_hba.conf
drwx------ 6 postgres postgres 4.0K Feb 6 15:13 base
drwx------ 3 postgres postgres 4.0K Feb 6 17:32 pg_wal
drwx------ 4 postgres postgres 4.0K Feb 6 22:44 pg_logical
drwx------ 2 postgres postgres 4.0K Feb 7 08:32 pg_notify
-rw------- 1 postgres postgres 36 Feb 7 08:32 postmaster.opts
-rw------- 1 postgres postgres 94 Feb 7 08:32 postmaster.pid
drwx------ 2 postgres postgres 4.0K Feb 7 08:32 pg_stat
drwx------ 2 postgres postgres 4.0K Feb 7 08:32 global
drwx------ 2 postgres postgres 4.0K Feb 7 08:33 pg_stat_tmp
and of the restored volume:
# ls -larth /var/lib/postgresql/data
total 136K
-rw------- 1 postgres postgres 3 Feb 7 00:10 PG_VERSION
drwx------ 2 postgres postgres 4.0K Feb 7 00:10 pg_twophase
drwx------ 2 postgres postgres 4.0K Feb 7 00:10 pg_tblspc
drwx------ 2 postgres postgres 4.0K Feb 7 00:10 pg_snapshots
drwx------ 2 postgres postgres 4.0K Feb 7 00:10 pg_serial
drwx------ 2 postgres postgres 4.0K Feb 7 00:10 pg_replslot
drwx------ 4 postgres postgres 4.0K Feb 7 00:10 pg_multixact
drwx------ 2 postgres postgres 4.0K Feb 7 00:10 pg_dynshmem
drwx------ 2 postgres postgres 4.0K Feb 7 00:10 pg_commit_ts
-rw------- 1 postgres postgres 26K Feb 7 00:10 postgresql.conf
-rw------- 1 postgres postgres 88 Feb 7 00:10 postgresql.auto.conf
-rw------- 1 postgres postgres 1.6K Feb 7 00:10 pg_ident.conf
drwx------ 2 postgres postgres 4.0K Feb 7 00:10 pg_xact
drwx------ 3 postgres postgres 4.0K Feb 7 00:10 pg_wal
drwx------ 2 postgres postgres 4.0K Feb 7 00:10 pg_subtrans
-rw------- 1 postgres postgres 4.5K Feb 7 00:10 pg_hba.conf
drwx------ 6 postgres postgres 4.0K Feb 7 00:10 base
drwxr-xr-x 3 postgres root 4.0K Feb 7 00:10 var
-rw------- 1 postgres postgres 36 Feb 7 00:14 postmaster.opts
drwx------ 2 postgres postgres 4.0K Feb 7 00:14 pg_notify
-rw------- 1 postgres postgres 94 Feb 7 00:14 postmaster.pid
drwx------ 2 postgres postgres 4.0K Feb 7 00:14 pg_stat
drwx------ 2 postgres postgres 4.0K Feb 7 00:15 global
drwx------ 4 postgres postgres 4.0K Feb 7 00:19 pg_logical
drwx------ 2 postgres postgres 4.0K Feb 7 08:34 pg_stat_tmp
Everything is hosted on a Ubuntu 18.04 server.
Did you use a docker volume plugin to create the volume? If there are any files or folders in there like lost+found it will probably fail to initialize. If there are files that you want to keep in the volume (or have no control over) you could adjust the PGDATA environment variable to point to a sub-directory in there like
-e PGDATA=/var/lib/postgresql/data/db-files/
...
volumeMounts:
- mountPath: /var/lib/postgresql/data
name: test-db-volume
subPath: postgres
...
Can also refer to this more understanding
TL;DR;
RTFM
I have to change the way I compress the initial volume because doing it the way I did, actually stores the full absolute path of each single file that get compressed. see man tar and check for the -C (capital C) option.
So before (bad):
$ docker run --rm --volumes-from rootdir_myapp-db_1 \
-v /mnt/data/dbbackups:/backup ubuntu tar cvf /backup/backup.tar /var/lib/postgresql/data
After (good):
$ docker run --rm --volumes-from rootdir_myapp-db_1 \
-v /mnt/data/dbbackups:/backup ubuntu tar cvf /backup/backup.tar -C /var/lib/postgresql/data .
Details
Okay, by exploring more the newly created volume that hosts the restored database, I can see that I have, inside the /var/lib/postgres/data/ folder, this line that tickled my eyes:
drwxr-xr-x 3 postgres root 4.0K Feb 7 00:10 var
When I get in there, there was a whole copy of /var/lib/postgres/data/ from the original database! E.g. /var/lib/postgres/data/var/lib/postgres/data/<pgstuff>. There is was! So, something went wrong. I checked the extraction part from the host machine; no problem. I checked the compression part... and the error was there actually:
$ docker run --rm --volumes-from rootdir_myapp-db_1 \
-v /mnt/data/dbbackups:/backup ubuntu tar cvf /backup/backup.tar /var/lib/postgresql/data
indeed, tar cvf /backup/backup.tar /var/lib/postgresql/ do take into account the absolute paths of the files it has been asked to compress!
Hence, back to the basics #rtfm:
$ man tar
...
-C, --directory=DIR
Change to DIR before performing any operations.
This option is order-sensitive, i.e. it affects all options that follow.
Clear enough for me, I changed the previous backuping command to:
$ docker run --rm --volumes-from rootdir_myapp-db_1 \
-v /mnt/data/dbbackups:/backup ubuntu tar cvf /backup/backup.tar -C /var/lib/postgresql/data .
Please, don't forget that tiny little dot at the end as it actually says to compress the directory tar just 'cd-ed' into!
From now, the restore is unchanged, and I can no more see that var folder in /var/lib/postgres/data/ inside the new volume!
And when I re-up my compose file, now I end up with was I waiting for:
$ cd /path/to/restore/test/folder
$ docker-compose up
Starting folder_test-db_1 ... done
Attaching to folder_test-db_1
test-db_1 |
test-db_1 | PostgreSQL Database directory appears to contain a database; Skipping initialization
test-db_1 |
test-db_1 | 2021-02-07 08:55:30.849 UTC [1] LOG: starting PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
test-db_1 | 2021-02-07 08:55:30.849 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
test-db_1 | 2021-02-07 08:55:30.850 UTC [1] LOG: listening on IPv6 address "::", port 5432
test-db_1 | 2021-02-07 08:55:30.858 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
test-db_1 | 2021-02-07 08:55:30.888 UTC [26] LOG: database system was interrupted; last known up at 2021-02-07 08:37:37 UTC
test-db_1 | 2021-02-07 08:55:33.044 UTC [26] LOG: database system was not properly shut down; automatic recovery in progress
test-db_1 | 2021-02-07 08:55:33.051 UTC [26] LOG: redo starts at 0/1EA5948
test-db_1 | 2021-02-07 08:55:33.051 UTC [26] LOG: invalid record length at 0/1EA5A30: wanted 24, got 0
test-db_1 | 2021-02-07 08:55:33.051 UTC [26] LOG: redo done at 0/1EA59F8
test-db_1 | 2021-02-07 08:55:33.096 UTC [1] LOG: database system is ready to accept connections
And inside that container, within psql -U user -d myapp-db:
# \conninfo
You are connected to database "myapp-db" as user "user" via socket in "/var/run/postgresql" at port "5432".
# \dt
List of relations
Schema | Name | Type | Owner
--------+---------------------------------------------------------+-------+-------
public | attachments_attachment | table | user
public | auth_group | table | user
public | auth_group_permissions | table | user
public | auth_permission | table | user
....
And both previous ways of restoring are working very well.
You may prefer one or the other.
I'm using the below manifest to deploy postgresql on kubernetes within NFS persistent volume:
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs2
spec:
capacity:
storage: 6Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
nfs:
server: 10.139.82.123
path: /nfsfileshare/postgres
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: nfs2
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 6Gi
---
apiVersion: v1
kind: Service
metadata:
name: db
labels:
app: aiflow-db
spec:
selector:
app: aiflow-db
clusterIP: None
ports:
- port: 5432
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: db
namespace: test-aiflow
labels:
app: aiflow-db
spec:
selector:
matchLabels:
app: aiflow-db
template:
metadata:
labels:
app: aiflow-db
spec:
containers:
- name: db
image: postgresql:10
ports:
- containerPort: 5432
env:
- name: PGDATA
value: /var/lib/postgresql/data/pgdata
volumeMounts:
- mountPath: /var/lib/postgresql/data/pgdata
name: nfs2
volumes:
- name: nfs2
persistentVolumeClaim:
claimName: nfs2
restartPolicy: Always
The pg data can be mounted to nfs server (/nfsfileshare/postgres *(rw,async,no_subtree_check,no_root_squash)):
total 124
drwx------ 19 999 root 4096 Aug 7 11:10 ./
drwxrwxrwx 5 root root 4096 Aug 7 10:28 ../
drwx------ 3 999 docker 4096 Aug 7 11:02 base/
drwx------ 2 999 docker 4096 Aug 7 11:10 global/
drwx------ 2 999 docker 4096 Aug 7 11:01 pg_commit_ts/
drwx------ 2 999 docker 4096 Aug 7 11:01 pg_dynshmem/
-rw------- 1 999 docker 4513 Aug 7 11:02 pg_hba.conf
-rw------- 1 999 docker 1636 Aug 7 11:02 pg_ident.conf
drwx------ 4 999 docker 4096 Aug 7 11:09 pg_logical/
drwx------ 4 999 docker 4096 Aug 7 11:01 pg_multixact/
drwx------ 2 999 docker 4096 Aug 7 11:10 pg_notify/
drwx------ 2 999 docker 4096 Aug 7 11:02 pg_replslot/
drwx------ 2 999 docker 4096 Aug 7 11:01 pg_serial/
drwx------ 2 999 docker 4096 Aug 7 11:01 pg_snapshots/
drwx------ 2 999 docker 4096 Aug 7 11:02 pg_stat/
drwx------ 2 999 docker 4096 Aug 7 11:02 pg_stat_tmp/
drwx------ 2 999 docker 4096 Aug 7 11:02 pg_subtrans/
drwx------ 2 999 docker 4096 Aug 7 11:02 pg_tblspc/
drwx------ 2 999 docker 4096 Aug 7 11:01 pg_twophase/
-rw------- 1 999 docker 3 Aug 7 11:02 PG_VERSION
drwx------ 3 999 docker 4096 Aug 7 11:02 pg_wal/
drwx------ 2 999 docker 4096 Aug 7 11:02 pg_xact/
-rw------- 1 999 docker 88 Aug 7 11:02 postgresql.auto.conf
-rw------- 1 999 docker 22729 Aug 7 11:02 postgresql.conf
-rw------- 1 999 docker 74 Aug 7 11:10 postmaster.pid
However the container is stuck with below log:
The files belonging to this database system will be owned by user
"postgres". This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8". The
default database encoding has accordingly been set to "UTF8". The
default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory
/var/lib/postgresql/data/pgdata ... ok creating subdirectories ... ok
selecting default max_connections ... 100 selecting default
shared_buffers ... 128MB selecting dynamic shared memory
implementation ... posix creating configuration files ... ok running
bootstrap script ... ok
Seems it stuck on post-bootstrap initialization.
It works only if I do not use nfs volume (works by using hostPath volume), why is that?
NFS does not support fsync kernel vfs call which is required transaction logs for ensuring the writing out the redo logs on the disk. So you should use block storage when you need to use RDBMS, such as PostgreSQL and MySQL. You might lose the data consistency althogh you can run the one on the NFS.
I meet the same question, When I use helm deploy the gitlab, the postgresql can't run, and errors below:
FATAL: data directory "/var/lib/postgresql/data/pgdata" has wrong ownership.
HINT: The server must be started by the user that owns the data directory.
I think it's because the postgresql run property need it's data should be own by user postgres and group postgres, but the nfs change the own user and group, makes the postgresql can't run.
Maybe change another tools like glusterfs can solve this problem, or try mysql's data mount by nfs.
I have created simple image based on mongo:latest. My Dockerfile is just
FROM mongo:3.3
MAINTAINER developer#encode.cz
Now when I run it by cmd docker run my-mongo mongod I get no /data/db error. But there is clearly RUN mkdir /data/db in mongo base image. Also pure mongo base image works as expected.
Why is this folder not present in my custom image if it is in the base image?
I think you have problems in the way you are testing or I don't understand well your question. I tested the official image:
docker run -d --name mongo mongo:3.3 mongod
docker exec -it mongo bash -c 'ls -la /data/db'
total 192
drwxr-xr-x 4 mongodb mongodb 4096 Oct 28 18:11 .
drwxr-xr-x 4 root root 4096 Oct 21 20:47 ..
-rw-r--r-- 1 mongodb mongodb 46 Oct 28 17:56 WiredTiger
-rw-r--r-- 1 mongodb mongodb 21 Oct 28 17:56 WiredTiger.lock
-rw-r--r-- 1 mongodb mongodb 935 Oct 28 18:11 WiredTiger.turtle
-rw-r--r-- 1 mongodb mongodb 40960 Oct 28 18:11 WiredTiger.wt
-rw-r--r-- 1 mongodb mongodb 4096 Oct 28 17:56 WiredTigerLAS.wt
-rw-r--r-- 1 mongodb mongodb 16384 Oct 28 17:57 _mdb_catalog.wt
-rw-r--r-- 1 mongodb mongodb 16384 Oct 28 17:57 collection-0--3585910680230311914.wt
-rw-r--r-- 1 mongodb mongodb 16384 Oct 28 17:57 collection-2--3585910680230311914.wt
drwxr-xr-x 2 mongodb mongodb 4096 Oct 28 18:11 diagnostic.data
-rw-r--r-- 1 mongodb mongodb 16384 Oct 28 17:57 index-1--3585910680230311914.wt
-rw-r--r-- 1 mongodb mongodb 16384 Oct 28 17:57 index-3--3585910680230311914.wt
-rw-r--r-- 1 mongodb mongodb 16384 Oct 28 17:57 index-4--3585910680230311914.wt
drwxr-xr-x 2 mongodb mongodb 4096 Oct 28 17:56 journal
-rw-r--r-- 1 mongodb mongodb 2 Oct 28 17:56 mongod.lock
-rw-r--r-- 1 mongodb mongodb 16384 Oct 28 17:57 sizeStorer.wt
-rw-r--r-- 1 mongodb mongodb 95 Oct 28 17:56 storage.bson
Then I created a Dockerfile with your two lines and:
docker build -t my-mongo .
docker run -d --name my-mongo my-mongo mongod
docker exec -it my-mongo bash -c 'ls -la /data/db'
total 192
drwxr-xr-x 4 mongodb mongodb 4096 Oct 28 18:12 .
drwxr-xr-x 4 root root 4096 Oct 21 20:47 ..
-rw-r--r-- 1 mongodb mongodb 46 Oct 28 18:06 WiredTiger
-rw-r--r-- 1 mongodb mongodb 21 Oct 28 18:06 WiredTiger.lock
-rw-r--r-- 1 mongodb mongodb 932 Oct 28 18:12 WiredTiger.turtle
-rw-r--r-- 1 mongodb mongodb 40960 Oct 28 18:12 WiredTiger.wt
-rw-r--r-- 1 mongodb mongodb 4096 Oct 28 18:06 WiredTigerLAS.wt
-rw-r--r-- 1 mongodb mongodb 16384 Oct 28 18:07 _mdb_catalog.wt
-rw-r--r-- 1 mongodb mongodb 16384 Oct 28 18:07 collection-0-683121925029568227.wt
-rw-r--r-- 1 mongodb mongodb 16384 Oct 28 18:07 collection-2-683121925029568227.wt
drwxr-xr-x 2 mongodb mongodb 4096 Oct 28 18:13 diagnostic.data
-rw-r--r-- 1 mongodb mongodb 16384 Oct 28 18:07 index-1-683121925029568227.wt
-rw-r--r-- 1 mongodb mongodb 16384 Oct 28 18:07 index-3-683121925029568227.wt
-rw-r--r-- 1 mongodb mongodb 16384 Oct 28 18:07 index-4-683121925029568227.wt
drwxr-xr-x 2 mongodb mongodb 4096 Oct 28 18:06 journal
-rw-r--r-- 1 mongodb mongodb 2 Oct 28 18:06 mongod.lock
-rw-r--r-- 1 mongodb mongodb 16384 Oct 28 18:07 sizeStorer.wt
-rw-r--r-- 1 mongodb mongodb 95 Oct 28 18:06 storage.bson
Be aware, the /data/db directory is declared as a volume. If you are having problems withn that, restart the docker daemon and check your available disk space df -h
Regards