On docker volume restore: could not access file “$libdir/timescaledb-1.6.0”: No such file or directory

dba.stackexchange https://dba.stackexchange.com/questions/286559

Question

I am trying to restore TimescaleDB data from one ubuntu machine to another ubuntu machine. On the both machines we have deployed TimescaleDB through docker and using the same tag.

Docker image used: timescale/timescaledb:latest-pg11

I am creating a tar file for backup for the docker volume on the old machine, using below command:

docker run --rm -v $VOLUME_NAME:/volume -v /tmp:/backup busybox tar cvf /backup/$VOLUME_NAME.tar -C /volume ./

Also I am restoring using below command on the new machine:

docker run --rm -v $VOLUME_NAME:/volume -v $(pwd):/backup busybox sh -c "rm -rf /volume/* ; tar -C /volume/ -xvf /backup/$VOLUME_BACKUP_FILE"

Database restore was successful but when I see the docker logs I am getting below error:

2021-03-06 06:28:55.064 UTC [239] ERROR:  could not access file "$libdir/timescaledb-1.6.0": No such file or directory
2021-03-06 06:28:55.064 UTC [239] STATEMENT:  CREATE TABLE "__migration_lock" ("id" int NOT NULL, CONSTRAINT "PK_1312144c987e032cce38cfa00a2" PRIMARY KEY ("id"))

Do you know why this error is coming and how to resolve it?

Thanks

Was it helpful?

Solution

Docker images tagged with latest contain the latest release at the time you retrieve it (this is Docker's convention), thus the image in the source contains different TimescaleDB's version (1.6.0) than in the current latest image (2.1.0 is latest now). This leads into the error of missing binary, since the images are not the same and the current latest image doesn't contain 1.6.0, which was latest some time ago.

The easiest solution is to download the image with the same TimescaleDB version as in the source. I believe timescale/timescaledb:1.6.0-pg11 should work in your case.

You can double check, which TimescaleDB's version is in use, by calling \dx in each database.

Note that a TimescaleDB's image usually contains 5 older versions before the tagged one. So if you use image tagged 1.7.3-pg11 it is likely to work too, since it expected to contain binaries for 1.6.0-pg11. This is important to know if you are going to update TimescaleDB version from 1.6.0 to later, since you will need to use several images to get to the current latest version.

In general to avoid confusion it is better to use an image with specific version tag.

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top