Skip site navigation (1) Skip section navigation (2)

Re: Core team statement on replication in PostgreSQL

From: "Marko Kreen" <markokr(at)gmail(dot)com>
To: "Aidan Van Dyk" <aidan(at)highrise(dot)ca>
Cc: "Dave Page" <dpage(at)pgadmin(dot)org>, "Douglas McNaught" <doug(at)mcnaught(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "David Fetter" <david(at)fetter(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Core team statement on replication in PostgreSQL
Date: 2008-05-29 16:27:38
Message-ID: e51f66da0805290927w2edd8318pdf717b76fec4c700@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers
On 5/29/08, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
> * Dave Page <dpage(at)pgadmin(dot)org> [080529 12:03]:
> > On Thu, May 29, 2008 at 4:48 PM, Douglas McNaught <doug(at)mcnaught(dot)org> wrote:
> > > I think the idea is that WAL records would be shipped (possibly via
>  > > socket) and applied as they're generated, rather than on a
>  > > file-by-file basis.  At least that's what "real-time" implies to me...
>  >
>  > Yes, we're talking real-time streaming (synchronous) log shipping.
>
> But synchronous streaming doesn't mean the WAL has to be *applied* on
>  the salve yet.  Just that it has to be "safely" on the slave (i.e on
>  disk, not just in kernel buffers).
>
>  The whole single-threaded WAL replay problem is going to rear it's ugly
>  head here too, and mean that a slave *won't* be able to keep up with a
>  busy master if it's actually trying to apply all the changes in
>  real-time.  Well, actually, if it's synchronous, it will keep up, but it
>  just means that now your master is IO capabilities is limited to the
>  speed of the slaves single-threaded WAL application.

I don't think thats a problem.  If the user runs its server at the
limit of write-bandwidth, thats its problem.

IOW, with synchronous replication, we _want_ the server to lag behind
slaves.

About the single-threading problem - afaik, the replay is mostly I/O bound
so threading would not buy you much.

-- 
marko

In response to

Responses

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2008-05-29 16:29:58
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Steve AtkinsDate: 2008-05-29 16:22:26
Subject: Re: Core team statement on replication in PostgreSQL

pgsql-advocacy by date

Next:From: Joshua D. DrakeDate: 2008-05-29 16:29:58
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Robert TreatDate: 2008-05-29 16:26:03
Subject: Re: State of PostgreSQL, BOF at OSCON?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group