From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Aidan Van Dyk <aidan(at)highrise(dot)ca>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: is sync rep stalled? |
Date: | 2010-09-30 14:23:49 |
Message-ID: | 4CA49D75.8010804@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30.09.2010 17:09, Kevin Grittner wrote:
> Aidan Van Dyk<aidan(at)highrise(dot)ca> wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>
>>> I'm sure there's several things you can accomplish with
>>> synchronous replication, perhaps you could describe what the
>>> important use case for you is?
>
>> I'm looking for "data durability", not "server query-ability"
>
> Same here. If we used synchronous replication, the important thing
> for us would be to hold up the master for the minimum time required
> to ensure remote persistence -- not actual application to the remote
> database. We could tolerate some WAL replay time on recovery better
> than poor commit performance on the master.
You do realize that to be able to guarantee zero data loss, the master
will have to stop committing new transactions if the streaming stops for
any reason, like a network glitch. Maybe that's a tradeoff you want, but
I'm asking because that point isn't clear to many people.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-09-30 14:24:29 | Re: Using streaming replication as log archiving |
Previous Message | Kevin Grittner | 2010-09-30 14:09:59 | Re: is sync rep stalled? |