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=XiSKBkFK0tYcSXGW1TMxgBrjnRv2mwVlq+02K42W9QoZOa4XTGuE/sqACW3bfl0jTk
	sXkjlX96JepFJGssw/5bf4rgmlhR+/EVHv+4DWl4h0TcNcC19ncyA0iJ7enNh+OI4ERa
	TbytIehR4JX3B7rOaMXPy9gelULnDWJZ8fqHw=
MIME-Version: 1.0
In-Reply-To: <99024f5f1002071922j5b14c350mb1612313690f16ec@mail.gmail.com>
References: <99024f5f1002071922j5b14c350mb1612313690f16ec@mail.gmail.com>
Date: Mon, 8 Feb 2010 15:38:54 -0700
Message-ID: <37d451f71002081438v10f87e0ax1ae6533a958e9691@mail.gmail.com>
Subject: Re: Best Replication Tool
From: Rosser Schwarz <rosser.schwarz@gmail.com>
To: Kiswono Prayogo <kiswono@gmail.com>
Cc: pgsql-admin@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1

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?

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.

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.

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.

rls

-- 
:wq