Re: Core team statement on replication in PostgreSQL

From: Hannu Krosing <hannu(at)krosing(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Fetter <david(at)fetter(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Core team statement on replication in PostgreSQL
Date: 2008-06-01 20:42:29
Message-ID: 1212352949.18365.18.camel@huvostro
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

On Thu, 2008-05-29 at 13:37 -0400, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
> > On Thu, May 29, 2008 at 08:46:22AM -0700, Joshua D. Drake wrote:
> >> The only question I have is... what does this give us that PITR
> >> doesn't give us?
>
> > It looks like a wrapper for PITR to me, so the gain would be ease of
> > use.
>
> A couple of points about that:
>
> * Yeah, ease of use is a huge concern here. We're getting beat up
> because people have to go find a separate package (and figure out
> which one they want), install it, learn how to use it, etc. It doesn't
> help that the most mature package is Slony which is, um, not very
> novice-friendly or low-admin-complexity. I personally got religion
> on this about two months ago when Red Hat switched their bugzilla
> from Postgres to MySQL because the admins didn't want to deal with Slony
> any more. People want simple.
>
> * The proposed approach is trying to get to "real" replication
> incrementally. Getting rid of the loss window involved in file-by-file
> log shipping is step one,

Actually we can already do better than file-by-file by using
pg_xlogfile_name_offset() which was added sometime in 2006. SkyTools for
example does this to get no more than a few seconds failure window.

Doing this synchronously would be of course better.

probably we should use the same "modes/protocols" as DRBD when
determining when a "sync" wal write is "done"

quote from 
http://www.slackworks.com/~dkrovich/DRBD/usingdrbdsetup.html#AEN76

Table 1. DRBD Protocols

Protocol
Description
A
A write operation is complete as
soon as the data is written to disk
and sent to the network.
B
A write operation is complete as
soon as a reception acknowledgement
arrives.
C
A write operation is complete as
soon as a write acknowledgement
arrives.

There are also additional paramaters you can pass to the disk and net
options. See the drbdsetup man page for additional information

/end quote

> and I suspect that step two is going to be
> fixing performance issues in WAL replay to ensure that slaves can keep
> up. After that we'd start thinking about how to let slaves run
> read-only queries. But even without read-only queries, this will be
> a useful improvement for HA/backup scenarios.
>
> regards, tom lane
>

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Hannu Krosing 2008-06-01 21:14:39 Re: Core team statement on replication in PostgreSQL
Previous Message Hannu Krosing 2008-06-01 20:42:11 Re: Core team statement on replication in PostgreSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Sabino Mullane 2008-06-01 21:13:05 Re: Overhauling GUCS
Previous Message Hannu Krosing 2008-06-01 20:42:11 Re: Core team statement on replication in PostgreSQL