Re: Core team statement on replication in PostgreSQL

From: Dimitri Fontaine <dim(at)hi-media(dot)com>
To: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, David Fetter <david(at)fetter(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Core team statement on replication in PostgreSQL
Date: 2008-05-29 22:12:31
Message-ID: 5966F428-2B4C-4383-B123-077D23DF9A55@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I'd first want to applaud core decision: having bare PostgreSQL
propose a reliable and simple to set-up synchronous replication
solution is an excellent perspective! ...

Le 29 mai 08 à 23:42, Robert Treat a écrit :
> I would have thought the read only piece would have been more
> important than
> the synchronous piece. In my experience readable slaves is the big
> selling
> point in both Oracle and MySQL's implementations, and people are not
> nearly
> as concerned if there is a small asynchronous window.

... Even more so when you're confronted to this exact problem.
A fellow PG user ended up having both the WAL and the data replicated
by DRBD (protocol C) and some heartbeat scripts to do the automatic
failover. This wasn't easy to setup, and to some extend we're still
concerned about the reliability part of it. We know about the "easy to
use" part of it: we didn't get it.

While at it, would it be possible for the "simple" part of the core
team statement to include automatic failover?
That would mean for current master when it's going to stop on error
(fatal) to tell the slave to warm-up. Of course in case of more severe
crash the slave would have to get started by other means, but covering
the fatal error path and have the master restart as a slave would only
add up to the reliability... wouldn't it?

> It would also be easier to implement on some level; we have already
> solved the
> asynchronus wal shipping problem, so we would just need to solve the
> read-only bits. For synchronus hot standby, you have to solve both the
> synchronus shipping and the read-only bits. Seems like more work
> with less
> upside that read-only slaves vs. pitr warm standby we have now.
>
> Interesting that core views this differently.

core seems to think read-only slave is more complex than synchronous
slave, in term of slave read only long transaction and master vacuums
for example.

Regards,
- --
dim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkg/Kk8ACgkQlBXRlnbh1bneKACeMK+fSp8VExctndo46X76NTxV
atIAn2UYw1g/4RPddypqirrZcqg5C7gm
=JeA6
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Tom Lane 2008-05-29 22:29:01 Re: Core team statement on replication in PostgreSQL
Previous Message Chris Browne 2008-05-29 22:06:39 Re: Core team statement on replication in PostgreSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-05-29 22:18:07 Re: intercepting WAL writes
Previous Message Chris Browne 2008-05-29 22:06:39 Re: Core team statement on replication in PostgreSQL