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
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 |