Re: Best Replication Tool

From: Gerd Koenig <koenig(at)transporeon(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Cc: Rosser Schwarz <rosser(dot)schwarz(at)gmail(dot)com>, Kiswono Prayogo <kiswono(at)gmail(dot)com>
Subject: Re: Best Replication Tool
Date: 2010-02-09 06:59:16
Message-ID: 201002090759.16503.koenig@transporeon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

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(at)gmail(dot)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(at)transporeon(dot)com
| www.transporeon.com
|
\====================================/

TRANSPOREON GmbH, Amtsgericht Ulm, HRB 722056
Geschäftsf.: Peter Förster, Roland Hötzl, Marc-Oliver Simon

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Lutz Steinborn 2010-02-09 08:48:31 migration problem 8.1.17 --> 8.4.2
Previous Message Tom Lane 2010-02-09 01:36:01 Re: Re: "effective_io_concurrency" cannot be changed error when starting 8.4.2 instance