Postgresql 7.4 migration to (partially) new disks - Mailing list pgsql-admin

From Achilleas Mantzios
Subject Postgresql 7.4 migration to (partially) new disks
Date
Msg-id 200609151344.34058.achill@matrix.gatewaynet.com
Whole thread Raw
Responses Re: Postgresql 7.4 migration to (partially) new disks  (Achilleas Mantzios <achill@matrix.gatewaynet.com>)
List pgsql-admin
Hi,

Our main postgresql/jboss/lotus notes server is configured as follows.

OS : Debian GNU linux 3.0
PgSQL: 7.4.13

The FS structure of the system has as follows:


Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda1              9614116   6528132   2597612  72% /
/dev/sdf              10321208   5801628   3995292  60% /raid2
/dev/sdg               6956424   4720060   1882988  72% /raidlog

where /dev/sda1 is the boot SCSI disk, while
/dev/sdf and /dev/sdg reside on two external EMC logical disks connected
with qlogic interfaces.

PgSQL is installed at the default location /usr/local/pgsql,
data is on the ~ of postgres user : /var/lib/pgsql/data

My main DB's (dynacom) data are held in
$PGDATA2 location at
/raid2/var/lib/postgres-data

also the commit log and transaction log directories are linked to:
pg_clog -> /raidlog/sma/var/lib/pgsql/data/pg_clog
and
pg_xlog -> /raidlog/sma/var/lib/pgsql/data/pg_xlog

We have planned to do the following task on this Sunday:
Migrate from Debian GNU linux 3.0 to SUSE SLES 9 (thats just a wierd lotus
notes "requirement"), and the sysadms have decided to do that on the same
HW, EMC disk arrays, by only replacing the root (/) disk.

The normal (safe) way to do that would be by following the normal
backup/install/configure/restore path.

However (just with any upgrade, and with lotus notes things get really scary
at times), there is always the possibility that the whole upgrade procedure
holds untill monday morning, when there would be an order from our boss
to rollback to the old system, or maybe repeat the same procedure
every night of the next days of the week until we succeed in Lotus Notes
upgrade!

In this scenario,If my new suse pgsql installation was some hours alive at the
meantime,
i would have to do the whole reverse backup/restore procedure again,
and this normally takes several minutes to comlete.
The DB is something about 2.5 Gbytes on .sql dump and 6 Gbytes on disk.

So one thought passing thru was to keep the alive postgresql dirs without
dumps/restores. That is to just retain the whole pgsql
directory /var/lib/pgsql/data on both systems, by copying back and fourth,
while leaving data $PGDATA2 (/raid2/var/lib/postgres-data) on the same EMC
disks. That is no backup restore at all.
(Providing ofcourse that the /var/lib/pgsql/data owner/group are also to be
setup correctly).

Does any one have done anything similar with (long term success),
or does anyone sees any potential problems with the later approach?

Thanx a lot for any thoughts.
--
Achilleas Mantzios

pgsql-admin by date:

Previous
From: "Dilipkumar"
Date:
Subject: Re: install postgres8.1 on debian
Next
From: "Donald Fraser"
Date:
Subject: Odd behaviour with WAL and pg_stop_backup