From: Gerd Koenig <koenig@transporeon.com>
To: pgsql-admin@postgresql.org
Cc: Rosser Schwarz <rosser.schwarz@gmail.com>
Cc: Kiswono Prayogo <kiswono@gmail.com>
Subject: Re: Best Replication Tool
Date: Tue, 9 Feb 2010 07:59:16 +0100
Message-ID: <201002090759.16503.koenig@transporeon.com> (raw)
In-Reply-To: <37d451f71002081438v10f87e0ax1ae6533a958e9691@mail.gmail.com>
References: <99024f5f1002071922j5b14c350mb1612313690f16ec@mail.gmail.com>
<37d451f71002081438v10f87e0ax1ae6533a958e9691@mail.gmail.com>
Hi,
probably pgpool-II is worth trying. A new version has been released two days
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?
>
> 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
>
--
/====================================\
| Gerd König
| - Infrastruktur -
|
| TRANSPOREON GmbH
| Magirus-Deutz-Str. 16
| DE - 89077 Ulm
|
| Tel: +49 [0]731 16906 106
| Fax: +49 [0]731 16906 99
| koenig@transporeon.com
| www.transporeon.com
|
\====================================/
TRANSPOREON GmbH, Amtsgericht Ulm, HRB 722056
Geschäftsf.: Peter Förster, Roland Hötzl, Marc-Oliver Simon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: koenig@transporeon.com, rosser.schwarz@gmail.com, kiswono@gmail.com
Subject: Re: Best Replication Tool
In-Reply-To: <201002090759.16503.koenig@transporeon.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox