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:content-transfer-encoding;
	b=O5BHcRDkPBIW0jeCvjRGigZBjZPwAceZ2aAnXPCJEa0Ha3OfV3Kd/wOj7LuQDOCGnI
	G9qaMc/1F5/HZXK2mBYMwudftve3qGPfILbClR6WUrPlRBeN40KiIgX3XaJNi3mb0o6l
	IfoWPAaddtXabZZNy/iM1s8YgcfwL5UcWICik=
MIME-Version: 1.0
In-Reply-To: <7965A9DCF12CC14984420BCC37B1608F25AB1AEF03@Elzar.grant.co.uk>
References: <7965A9DCF12CC14984420BCC37B1608F25AB1AED49@Elzar.grant.co.uk>
	<1269959369.15416.5.camel@deimos>
	<20100330143831.GE17567@easy5.in-chemnitz.de>
	<7965A9DCF12CC14984420BCC37B1608F25AB1AEE54@Elzar.grant.co.uk>
	<4BB22F64.8080708@2ndquadrant.com>
	<7965A9DCF12CC14984420BCC37B1608F25AB1AEF03@Elzar.grant.co.uk>
Date: Wed, 31 Mar 2010 02:11:00 -0600
Message-ID: <r2kdcc563d11003310111h7a0b742av18ff953d33d2d6ea@mail.gmail.com>
Subject: Re: Migrate postgres to newer hardware
From: Scott Marlowe <scott.marlowe@gmail.com>
To: Renato Oliveira <renato.oliveira@grant.co.uk>
Cc: Greg Smith <greg@2ndquadrant.com>, Tino Schwarze <postgresql@tisc.de>,
	"pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 31, 2010 at 1:43 AM, Renato Oliveira
<renato.oliveira@grant.co.uk> wrote:
> Greg,
>
> Thank you very much for your input.
> I agree with you and I do understand where you are coming from.
>
> I do agree that in order to transition without a noticeable downtime the =
application would need to be built for that.
>
> Which one works best: bucardo, slony or Londiste?
>
> I have researched Slony and Bucardo but have not heard of =A0Londiste bef=
ore.
>
> How many people are using all three of them and their review =A0have you =
heard anything about that?

I run slony.  On our regular db there are about 2000 relations, about
1200 of those are indexes, so slony has to worry about 800 or so
relations.  It has no problem with that.  On another machine that has
some 45k relations in addition to the 2000 base relations.  That slony
instance takes 3.5 hours to run the same create set that takes 2
minutes on the machine with just 2000 relations.

Slony should be able to work for you.  See if you can schedule it so
you start your subscription right when you're entering your lowest
throughput window.  Your real bottleneck here is that source database
with a single hard drive.  That's going to limit your speed of
subscription by quite a bit.