Reputation: 35
I am fairly new to docker and I was changing some settings in postgres.conf inside my timescaledb container running on WSL2. I promptly restarted the container to apply my changes and it appears that I have added an unnecessary comma and the container will not start. Below is the log that reflects this.
2021-07-20 17:02:59.933 GMT [1] LOG: syntax error in file "/var/lib/postgresql/data/postgresql.conf" line 59, near token ","
2021-07-20 17:02:59.933 GMT [1] FATAL: configuration file "/var/lib/postgresql/data/postgresql.conf" contains errors
PostgreSQL Database directory appears to contain a database; Skipping initialization
2021-07-20 17:49:58.494 GMT [1] LOG: syntax error in file "/var/lib/postgresql/data/postgresql.conf" line 59, near token ","
2021-07-20 17:49:58.494 GMT [1] FATAL: configuration file "/var/lib/postgresql/data/postgresql.conf" contains errors
Now, the container always fails to start upon restart. I have no backups of this container and it contains about 100gb of data. The way I see it right now, there are three options:
Any help would be greatly appreciated. Below are some details about my environment:
Client:
Cloud integration: 1.0.14
Version: 20.10.6
API version: 1.41
Go version: go1.16.3
OS/Arch: windows/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.6
API version: 1.41 (minimum version 1.12)
Go version: go1.13.15
OS/Arch: linux/amd64
Experimental: false
REPOSITORY TAG
timescale/timescaledb 2.3.1-pg13
Upvotes: 1
Views: 1560
Reputation: 312138
Like most database images, the timescaledb
image does not place your data in the container root filesystem -- it creates a volume for the data instead. By default this is an "anonymous" volume -- it has no name, and will be deleted when your delete your container.
To access the data from your timescaledb
container, you first need to determine the volume id. You can get that from the output of docker container inspect
:
$ docker inspect timescale --format="{{ range .Mounts }}{{.Name}}{{end}}"
bee238efb681cd88c20ddedc46ca4a55a0b6b598f5c137945e8d6714fce99d4b
Here, I can see that my container named timescale
was attached to the volume bee238efb681cd88c20ddedc46ca4a55a0b6b598f5c137945e8d6714fce99d4b
(you would replace timescale
in the above command with the name or id of your failed container). I can start up a new container using the same volume so that I can edit the configuration file(s):
$ docker run -v bee238efb681cd88c20ddedc46ca4a55a0b6b598f5c137945e8d6714fce99d4b:data --rm -it alpine sh
/ # cd /data
/data # ls
PG_VERSION pg_commit_ts pg_ident.conf pg_notify pg_snapshots pg_subtrans pg_wal postgresql.conf
base pg_dynshmem pg_logical pg_replslot pg_stat pg_tblspc pg_xact postmaster.opts
global pg_hba.conf pg_multixact pg_serial pg_stat_tmp pg_twophase postgresql.auto.conf
The volume is mounted on /data
, and I'm free to edit files there.
Once you've made the necessary changes, you can exit this temporary
container and then restart your failed container.
When running any sort of service for which you want your data to persist longer than the lifetime of the container, you should arrange to store your data in a named volume, which are never removed automatically.
You create a named volume by passing a name as the first argument to -v
, for example:
docker run -v myimportantdata:/var/lib/postgresql/data ...
This creates a named volume named myimportantdata
if it doesn't already exists, and mounts it in the container at the given path.
You should also, of course, arrange to automatically back up any data that you care about.
Upvotes: 1