Received: from maia.hub.org (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id C6DEA634807
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Tue, 30 Mar 2010 08:28:43 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia,
	port 10024) with ESMTP id 80883-03 for
	<pgsql-admin-postgresql.org@mail.postgresql.org>;
	Tue, 30 Mar 2010 11:28:26 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wy0-f174.google.com (mail-wy0-f174.google.com
	[74.125.82.174])
	by mail.postgresql.org (Postfix) with ESMTP id C02EE634792
	for <pgsql-admin@postgresql.org>; Tue, 30 Mar 2010 08:28:32 -0300 (ADT)
Received: by wyb39 with SMTP id 39so1613421wyb.19
	for <pgsql-admin@postgresql.org>; Tue, 30 Mar 2010 04:28:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:mime-version:received:in-reply-to:references
	:date:received:message-id:subject:from:to:cc:content-type;
	bh=vJYfBR1JZUn0eD59IRf4hiDQXjXjMwLSvigeYDo5+HE=;
	b=TY5PBCbhTC1swWNUYla5PAW8J8GKyli0RhlrEbptqnnEMGu6L1Tq3i8aS5Bqq6i1cD
	HRh5wjG4b96B9jQlJAvdAiKCtWqzXnozzR3UdqVmL0rhUG0rxXMWIfXirC9Yye2vNu+h
	TJU7aApYBoIfyfl64GYWWeK8cmo0e96B5gUEI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	b=m1D2PJKgkL2tetzAX9vbhqr4n9Qsq0A4cd+lh/5Ix0XUFzKIYEiITnF/aIp4faZqKH
	DXY69oeLMnkDsqyITplnTAbvbgrryDBxV3vM3fqnE9F+WeEzo5eYAzCb79vbidA3XEqK
	i8EEXJJeBMw/0YE+juK9Xk9PgHy8hayVsJ4Yg=
MIME-Version: 1.0
Received: by 10.216.0.5 with HTTP; Tue, 30 Mar 2010 04:28:31 -0700 (PDT)
In-Reply-To: <7965A9DCF12CC14984420BCC37B1608F25AB1AED49@Elzar.grant.co.uk>
References: <7965A9DCF12CC14984420BCC37B1608F25AB1AED49@Elzar.grant.co.uk>
Date: Tue, 30 Mar 2010 13:28:31 +0200
Received: by 10.216.86.66 with SMTP id v44mr500867wee.163.1269948511110; Tue,
	30 Mar 2010 04:28:31 -0700 (PDT)
Message-ID: <e4edc9361003300428s690df286q7f817cb9d936043f@mail.gmail.com>
Subject: Re: Migrate postgres to newer hardware
From: Szymon Guz <mabewlun@gmail.com>
To: Renato Oliveira <renato.oliveira@grant.co.uk>
Cc: "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Content-Type: multipart/alternative; boundary=0016e6d99fa1e346ea048302ed87
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-2.347 tagged_above=-10 required=5 tests=AWL=0.251,
	BAYES_00=-2.599, HTML_MESSAGE=0.001
X-Spam-Level: 
X-Archive-Number: 201003/239
X-Sequence-Number: 34038

--0016e6d99fa1e346ea048302ed87
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2010/3/30 Renato Oliveira <renato.oliveira@grant.co.uk>

>    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 =E2=80=9CYes=E2=80=9D.
>
> If we cannot use PITR what would be the best approach, we can=E2=80=99t h=
ave down
> time I am afraid.
>
> Any ideas or suggestions would be very welcome.
>
>
>
I'd use Slony as a replication tool so the data would be copied to the new
serwer while the old still works. After initial copy Slony will copy change=
s
made during making the copy. Later (when the replication lag is small) it
should be enough to stop application, reconfigure it for the new database,
get rid of replication so the new slave database will restore all triggers
and then start the application for using the new database.
Slony uses pure SQL for copying the data so there is no problem with the
differences in the hardware.

regards
Szymon Guz

--0016e6d99fa1e346ea048302ed87
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">2010/3/30 Renato Oliveira <span dir=3D"ltr">=
&lt;<a href=3D"mailto:renato.oliveira@grant.co.uk">renato.oliveira@grant.co=
.uk</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">







<div>
<div style=3D"font-size:9pt;font-family:Courier New">
<div>
<div><font face=3D"Arial" size=3D"2">

<div>

<p class=3D"MsoNormal">Dear All,</p>

<p class=3D"MsoNormal">What would be the easiest and fastest way to migrate
Postgres 8.2.24 32 BIT to a new server 64 Bit.</p>

<p class=3D"MsoNormal">The existing server runs on 32 bit architecture and =
has a
database as big as 160GB.</p>

<p class=3D"MsoNormal">We initially thought of using PITR, but as one of th=
e PITR
requirements is both machines need to be similar.</p>

<p class=3D"MsoNormal">This similarity needs to be even in architecture? I =
think I
read something which says =E2=80=9CYes=E2=80=9D.</p>

<p class=3D"MsoNormal">If we cannot use PITR what would be the best approac=
h, we
can=E2=80=99t have down time I am afraid.</p>

<p class=3D"MsoNormal">Any ideas or suggestions would be very welcome.</p>

<p class=3D"MsoNormal"><font class=3D"Apple-style-span" face=3D"arial"><fon=
t class=3D"Apple-style-span" face=3D"Arial"><br></font></font></p></div></f=
ont></div></div></div></div></blockquote><div>=C2=A0</div><div>I&#39;d use =
Slony as a replication tool so the data would be copied to the new serwer w=
hile the old still works. After initial copy Slony will copy changes made d=
uring making the copy. Later (when the replication lag is small) it should =
be enough to stop application, reconfigure it for the new database, get rid=
 of replication so the new slave database will restore all triggers and the=
n start the application for using the new database.</div>
<div>Slony uses pure SQL for copying the data so there is no problem with t=
he differences in the hardware.</div><div><br></div><div>regards</div><div>=
Szymon Guz</div></div>

--0016e6d99fa1e346ea048302ed87--