Re: Postgresql 7.4 migration to (partially) new disks

Στις Παρασκευή 15 Σεπτέμβριος 2006 13:44, ο/η Achilleas Mantzios έγραψε:
> 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.

I guess (from the zero responses) that maybe i was not clear enuf, so
i will try to set the question like this:

What considerations should someone take if he is about to just
cp -r <path_to_some_other_pgsql_data_path>/data .
.i.e. creating the PGDATA dir *not* following the standard initdb procedure

Is there any implication having to do with timestamps? modification dates?
ownerships? other?

if i just do
cp -a <path_to_some_other_pgsql_data_path>/data .
(-a implies -R)
and then
chown -R postgres:postgres ./data
(new postgres user on the new SUSE might have a different uid/gid than the
original Debian),

then will i have a healthy data dir
for postgresql to reliably work?

I'd suppose this might work on a test system, but should someone
rely on it for a critical production system?

Thanx
> 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