Re: Replication

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: Gerry Reno <greno(at)verizon(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: Replication
Date: 2009-06-23 03:12:50
Message-ID: dcc563d10906222012t4592e305j48de44354a56904c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Jun 22, 2009 at 8:59 PM, Craig
Ringer<craig(at)postnewspapers(dot)com(dot)au> wrote:

> So ... it doesn't seem likely that statement-level replication would
> ever get far in Pg because of nasty issues like this one.

It's exactly what pg_pool does, and you can choose it if you know what
you're doing. But yes, it's usually a bad fit for replication by
itself.

> That was my point re concurrent execution of statements. Nothing to do
> with ensuring key uniqueness without inter-node synchronisation in
> multi-master environments.
>
> Block-level master/slave synchronous replication, however, is already on
> the way. (Also, Slony provides row-level master/slave replication that
> seems to work well for a lot of people, though it's widely admitted to
> be a bit of a pain to work with and not particularly nice.)

I think it's real easy to work with, once you understand that "it's
boss". I.e. you do things the slony way, or get used to recreating /
resubscribing a lot of times during maintenance windows when you can
run on one db. The mis-feature of no ability to drop tables caught me
out. Now we don't drop tables, period. We rename and alter to get
around that. Once I told the developers not to drop tables in order
to change them, things got better. Really it was bad habits learned
from other dbs.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Craig Ringer 2009-06-23 03:43:55 Re: Replication
Previous Message Scott Marlowe 2009-06-23 03:04:12 Re: Replication