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.  (Roger Wolff <rew-googlegroups@BitWizard.nl>)
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:

Previous
From: Paul Förster
Date:
Subject: Re: Determine if postgresql cluster running is primary or not
Next
From: Roger Wolff
Date:
Subject: Re: Recovering old installation.