From: Gerd Koenig <koenig@transporeon.com>
Organization: Transporeon GmbH
To: pgsql-admin@postgresql.org
Subject: Re: Best Replication Tool
Date: Tue, 9 Feb 2010 07:59:16 +0100
User-Agent: KMail/1.12.4 (Linux/2.6.31.12-174.2.3.fc12.i686; KDE/4.3.5; i686;
 ;
	)
Cc: Rosser Schwarz <rosser.schwarz@gmail.com>,
	Kiswono Prayogo <kiswono@gmail.com>
References: <99024f5f1002071922j5b14c350mb1612313690f16ec@mail.gmail.com>
	<37d451f71002081438v10f87e0ax1ae6533a958e9691@mail.gmail.com>
In-Reply-To: <37d451f71002081438v10f87e0ax1ae6533a958e9691@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201002090759.16503.koenig@transporeon.com>

Hi,

probably pgpool-II is worth trying. A new version has been released two day=
s=20
ago....
http://pgfoundry.org/projects/pgpool

hth ..:GERD:..


On Monday 08 February 2010 23:38:54 Rosser Schwarz wrote:
> On Sun, Feb 7, 2010 at 8:22 PM, Kiswono Prayogo <kiswono@gmail.com> wrote:
> > Hi, i'm really new to postgresql replication, was there any
> > replication tool for postgresql that can do real-time replication from
> > 1 database to ~3-10 database (on the other machines) with little
> > overhead for load balancing purpose?
>=20
> If, by "real time", you mean that a tuple created or changed on the
> master is visible to queries on an arbitrary slave within a few
> seconds, then Bucardo and Slony are both good candidates.  I've used
> Bucardo in just such an environment, along with its master-master
> capability.  Of the two, I definitely prefer the former, but this
> isn't an advocacy list, and they both work.
>=20
> The amount of overhead you'll experience is a function of how "chatty"
> your data is -- the higher the volume of changes it needs to
> replicate, the more work it will take to keep those changes flowing
> out to the slave nodes.  If you update the same tuple three times in a
> five second period, that's three tuples you'll be replicating out to
> each slave.
>=20
> Another important consideration is the size of your replication sets
> (in Slony terms; "herds" in Bucardo).  The bigger they are -- the more
> tables they include -- the more work it will take to replicate any
> changes in any of their member objects.  IME, you'll typically do well
> to keep your sets down to the smallest meaningful groups you can.
> Particularly, you'll want to group together tables that are
> interrelated by foreign keys (this is especially important if you're
> using Slony, and have any plans to support switching masters), or that
> you expect to be modified together -- for example, all the tables that
> might be modified in the course of a new order being entered into your
> OLTP application.
>=20
> rls
>=20

=2D-=20
/=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\
| Gerd K=F6nig
| - Infrastruktur -
|
| TRANSPOREON GmbH
| Magirus-Deutz-Str. 16=20
| DE - 89077 Ulm
|
| Tel: +49 [0]731 16906 106
| Fax: +49 [0]731 16906 99
| koenig@transporeon.com
| www.transporeon.com
|
\=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/


TRANSPOREON GmbH, Amtsgericht Ulm, HRB 722056
Gesch=E4ftsf.: Peter F=F6rster, Roland H=F6tzl, Marc-Oliver Simon