Recovering old installation. - Mailing list pgsql-general
From | Roger Wolff |
---|---|
Subject | Recovering old installation. |
Date | |
Msg-id | 20201120102042.fhhljrtiiyh5qsqo@BitWizard.nl Whole thread Raw |
Responses |
Re: Recovering old installation.
|
List | pgsql-general |
Hi, I have a little problem here... I had a hardware failure. Replaced the power supply and then the system wouldn't boot. I eventually bought a new computer, new SSD for a root/boot disk. Did a fresh install then moved over the storage drives and went on my merry way.... Now... it seems after an earlier migration I had fogotten to move the postgresql backup to the new postgresql installation. So now I have my database in version 9.5 in /oldroot/.... somewhere and a new instance of psql (Version 12) is running in the freshly installed instance. My plan-of-attack is to simply chroot to /oldroot, start the old 9.5 server run a psqldump and un-dump into the new server (have to figure out how, but should be documented) But the problem is: how do I start the server in the old root? All searches for "chroot postgresql" turn up people who, for security reasons, want to run postgresql inside a chroot environment. All searches for "start postgresql" tell me to simply type "service postgresql start". Great on a normal system, but not here: abra2:/etc# service postgresql start * Starting PostgreSQL 9.5 database server * The PostgreSQL server failed to start. Please check the log output: 2020-11-20 10:54:59 CET [2080825-1] FATAL: could not open shared memory segment "/PostgreSQL.1552904327": Function not implemented [fail] abra2:/etc# journalctl No journal files were found. -- No entries -- OK. One step further. Monted (bind) /dev onto /oldroot/dev and now the message chages to "permission denied" as opposed to "function not implemented". One of the things I'd like to do is to start the server manually. In /lib/systemd/system I find postgresql@.service that says: # systemd service template for PostgreSQL clusters. The actual instances will # be called "postgresql@version-cluster", e.g. "postgresql@9.3-main". The # variable %i expands to "version-cluster", %I expands to "version/cluster". # (%I breaks for cluster names containing dashes.) and: ExecStart=@/usr/bin/pg_ctlcluster postgresql@%i --skip-systemctl-redirect %i start So, I figured out that my cluster is called "main" and my version is 9.5. So now I expect that commandline to expand to: /usr/bin/pg_ctlcluster postgresql@9.5-main --skip-systemctl-redirect 9.5-main start And when I try that I get: Error: specified cluster does not exist Now that error message is less useful than it could be. I don't know if the postgresql@9.5-main or the 9.5-main is what it considers the "specified cluster". Anyway, I tried a few variations but can't get it to recognize the "specified cluster". abra2:/lib/systemd/system# pg_lsclusters Ver Cluster Port Status Owner Data directory Log file 9.5 main 5432 down postgres /var/lib/postgresql/9.5/main /var/log/postgresql/postgresql-9.5-main.log abra2:/lib/systemd/system# Simplifying the commandline to: /usr/bin/pg_ctlcluster 9.5-main start it seems to do something... but then again: FATAL: could not open shared memory segment "/PostgreSQL.964036999": Permission denied So then running strace -f to see what failed... No EPERM returns from any system call. Sigh. So... Any ideas for helping me get my server up-and-running for five minutes to run a pgdump ? Roger. -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
pgsql-general by date: