Обсуждение: Postgresql 7.4 migration to (partially) new disks
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
Στις Παρασκευή 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
Achilleas Mantzios <achill@matrix.gatewaynet.com> writes:
> 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
If you copy the *entire* data tree (data, xlog, clog, any outside
tablespaces), and use exactly the same Postgres executables at both
ends, then it should pretty much Just Work.
> chown -R postgres:postgres ./data
> (new postgres user on the new SUSE might have a different uid/gid than the
> original Debian),
This is OK.
> I'd suppose this might work on a test system, but should someone
> rely on it for a critical production system?
As long as the DBA has practiced beforehand ;-), sure.
regards, tom lane
Στις Παρασκευή 15 Σεπτέμβριος 2006 17:47, ο/η Tom Lane έγραψε: > Achilleas Mantzios <achill@matrix.gatewaynet.com> writes: > > 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 > > If you copy the *entire* data tree (data, xlog, clog, any outside > tablespaces), and use exactly the same Postgres executables at both > ends, then it should pretty much Just Work. > Thats what i feared from the begining. (some connection between the data dir and the executable, really, why does the executable need to be exactly the same, if we are talking about minor postgresql upgrade 7.4.12->7.4.13?) The old system is kind of old, and there would be libraries incompatibilities if a was to retain the old executable. So i'll do it the formal way, and pray lotus notes will behave :) Thanx. > > chown -R postgres:postgres ./data > > (new postgres user on the new SUSE might have a different uid/gid than > > the original Debian), > > This is OK. > > > I'd suppose this might work on a test system, but should someone > > rely on it for a critical production system? > > As long as the DBA has practiced beforehand ;-), sure. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster -- Achilleas Mantzios
Achilleas Mantzios <achill@matrix.gatewaynet.com> writes:
>> If you copy the *entire* data tree (data, xlog, clog, any outside
>> tablespaces), and use exactly the same Postgres executables at both
>> ends, then it should pretty much Just Work.
> Thats what i feared from the begining. (some connection between the data dir
> and the executable, really, why does the executable need to be exactly the
> same,
> if we are talking about minor postgresql upgrade 7.4.12->7.4.13?)
Well, a minor version update won't in itself break anything; what would
break things is changing certain build options (such as
integer-datetimes) or switching to a different architecture (such as
x86 -> x86_64).
regards, tom lane