I updated my docker file to version 3 but now the inicial schemas are not being created. i already tried with a different volume I run it with : docker-compose -f docker-compose.yml up
version: '3'
services:
db-service:
image: postgres:11.2
volumes:
- ./dbscripts/:/docker-entrypoint-initdb.d/
restart: always
environment:
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=postgres
- POSTGRES_DB=sample
ports:
- 5432:5432
Check these 2 things:
The init scripts are triggered only on the first deploy. On the subsequent docker-compose ups you probably see as well on the logs the following message:
db_1 | PostgreSQL Database directory appears to contain a database; Skipping initialization
To force the re-initialization, you can wipe the data volume(This will delete the entries, not only the schema).
To find the path, simply docker inspect <postgres-container-id> and look for the HostConfig.Binds
The script executes till the first type "longvarbinary" does not exist error. You will need to fix this.
db-service_1 | CREATE TABLE
db-service_1 | 2020-07-26 19:29:34.121 UTC [68] ERROR: type "longvarbinary" does not exist at character 68
I opened a console in the postgres container and your sample database is there, as well as a table that is created before the .sql error occurs in the script:
docker exec -ti 22b0bb87561f sh
# psql -U postgres
psql (11.2 (Debian 11.2-1.pgdg90+1))
Type "help" for help.
postgres=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+----------+------------+------------+-----------------------
postgres | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
sample | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
template0 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =c/postgres +
| | | | | postgres=CTc/postgres
(4 rows)
postgres=# \c sample
You are now connected to database "sample" as user "postgres".
sample=# \dt
List of relations
Schema | Name | Type | Owner
--------+----------------------+-------+----------
public | oauth_client_details | table | postgres
(1 row)
I was having this exact same issue and what solved it was manually deleting the volume folder, in this case rm -rf dbscripts. Since you're not creating a volume through docker and just referencing a folder in your local drive, when starting the container it will check the folder is there, and skip the script, because it sees the folder is there and assumes the container is already initialized. You will have to delete the folder manually everytime you want to run the container and have it initialize with your custom script.
Alternatively, don't store the data locally and create a volume for it, so instead of what you have change it as so:
version: '3'
services:
db-service:
image: postgres:11.2
volumes:
- dbscripts:/docker-entrypoint-initdb.d/
restart: always
environment:
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=postgres
- POSTGRES_DB=sample
ports:
- 5432:5432
volumes:
dbscripts:
That way you can just docker-compose down --volumes and go docker-compose up --build right after
I ran into the same issue, and I figured it was because I forgot to clear the volume when I take down docker compose with command docker-compose down.
The solution that helps is when you take down docker compose, you specify that all volumes must be removed docker-compose down --volumes. Also, make sure to check and delete any related volumes using docker volume ls.
WARNING: Any subsequent command docker-compose down should not have the flag --volume or else your persistent data will be wiped out. This may or may not be desirable depending on your use case. The idea is to ONLY run the init script on the very first time you run docker-compose up. Any subsequent command up after that will skip initialization because data is already populated, and you don't want to override it.
Hope it helps!
