Re: Migrate postgres to newer hardware - Mailing list pgsql-admin
From | Iñigo Martinez Lasala |
---|---|
Subject | Re: Migrate postgres to newer hardware |
Date | |
Msg-id | 1269959369.15416.5.camel@deimos Whole thread Raw |
In response to | Migrate postgres to newer hardware (Renato Oliveira <renato.oliveira@grant.co.uk>) |
Responses |
Re: Migrate postgres to newer hardware
Re: Migrate postgres to newer hardware |
List | pgsql-admin |
Hi Renato.
I would follow the ancient method: perform a pg_dump / pg_restore
Yes, you will have to take offline database for a long period.
And yes, it would be a great moment to perform a 8.4 upgrade. Performance is far superior, restore is far faster...
... and yes, it could give you many problems if you don't perform many test in order to address all queries without explicit type conversions before real migration, but I think it's the best moment to deal with a very convenient upgrade.
We have performed this upgrade last week with a gforge (with only 25GB database) and having also to upgrade to new tsearch2 and everything is running smooth.
-----Original Message-----
From: Renato Oliveira <renato.oliveira@grant.co.uk>
To: pgsql-admin@postgresql.org <pgsql-admin@postgresql.org>
Subject: [ADMIN] Migrate postgres to newer hardware
Date: Tue, 30 Mar 2010 12:18:36 +0100
Dear All,
What would be the easiest and fastest way to migrate Postgres 8.2.24 32 BIT to a new server 64 Bit.
The existing server runs on 32 bit architecture and has a database as big as 160GB.
We initially thought of using PITR, but as one of the PITR requirements is both machines need to be similar.
This similarity needs to be even in architecture? I think I read something which says “Yes”.
If we cannot use PITR what would be the best approach, we can’t have down time I am afraid.
Any ideas or suggestions would be very welcome.
Thank you very much
Best regards
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our website
I would follow the ancient method: perform a pg_dump / pg_restore
Yes, you will have to take offline database for a long period.
And yes, it would be a great moment to perform a 8.4 upgrade. Performance is far superior, restore is far faster...
... and yes, it could give you many problems if you don't perform many test in order to address all queries without explicit type conversions before real migration, but I think it's the best moment to deal with a very convenient upgrade.
We have performed this upgrade last week with a gforge (with only 25GB database) and having also to upgrade to new tsearch2 and everything is running smooth.
-----Original Message-----
From: Renato Oliveira <renato.oliveira@grant.co.uk>
To: pgsql-admin@postgresql.org <pgsql-admin@postgresql.org>
Subject: [ADMIN] Migrate postgres to newer hardware
Date: Tue, 30 Mar 2010 12:18:36 +0100
Dear All,
What would be the easiest and fastest way to migrate Postgres 8.2.24 32 BIT to a new server 64 Bit.
The existing server runs on 32 bit architecture and has a database as big as 160GB.
We initially thought of using PITR, but as one of the PITR requirements is both machines need to be similar.
This similarity needs to be even in architecture? I think I read something which says “Yes”.
If we cannot use PITR what would be the best approach, we can’t have down time I am afraid.
Any ideas or suggestions would be very welcome.
Thank you very much
Best regards
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our website
pgsql-admin by date: