DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
	:content-type:content-transfer-encoding;
	b=P8YuXLc3n6lBL19I4BZUogR2pHLe1gDZKIOQ5JgL5Z+p7v7IDJONC4/pXOILWZccWs
	4afPG1lK+xTETGyfBI8SsmLU/v/+Yj5QauhdGHW7KOi5tFOHogFBzRfWQ8YctNGNpFKX
	NWdmyOl539/XZpv/RlN1J3RgtgkufvqDLlD8w=
MIME-Version: 1.0
In-Reply-To: <1269962795.15416.26.camel@deimos>
References: <7965A9DCF12CC14984420BCC37B1608F25AB1AED49@Elzar.grant.co.uk>
	<1269959369.15416.5.camel@deimos>
	<7965A9DCF12CC14984420BCC37B1608F25AB1AEE48@Elzar.grant.co.uk>
	<1269962795.15416.26.camel@deimos>
Date: Tue, 30 Mar 2010 17:44:43 +0200
Message-ID: <99f1636c1003300844n72ded3adg3fe034a6084bd2e4@mail.gmail.com>
Subject: Re: Migrate postgres to newer hardware
From: jose javier parra sanchez <jojapasa@gmail.com>
Cc: pgsql-admin <pgsql-admin@postgresql.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

> -----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 B=
IT
> 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 i=
s
> both machines need to be similar.
>
> This similarity needs to be even in architecture? I think I read somethin=
g
> which says =93Yes=94.
>
>
>
> If we cannot use PITR what would be the best approach, we can=92t have do=
wn
> time I am afraid.
>
>
>
> Any ideas or suggestions would be very welcome.
>
>
>
> Thank you very much
>
>
>
> Best regards
>
>
>
> Renato
>
>
>
>
>
>
> =A0 Renato Oliveira
> Systems Administrator
> e-mail: renato.oliveira@grant.co.uk =A0 Tel: +44 (0)1763 260811
> Fax: +44 (0)1763 262410
> www.grant.co.uk =A0 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 ri=
sk,
> we cannot accept liability for any damage which you sustain as a result o=
f
> 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 Gran=
t
> Instruments please visit our website
>
>
>
>
>
> 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 ri=
sk,
> we cannot accept liability for any damage which you sustain as a result o=
f
> 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 Gran=
t
> Instruments please visit our website
>

You can use the pg_dump method and use pgpool to replicate the new
data, then when sinchronized, switch off the old node.