Re: Replication and fsync - Mailing list pgsql-general

From maillists0@gmail.com
Subject Re: Replication and fsync
Date
Msg-id CAB+OxSD9keWt-+N6-R19mKH9iRhcViCo1AKcBsHb-JMutR6_Tg@mail.gmail.com
Whole thread Raw
In response to Re: Replication and fsync  (Alban Hertroys <haramrae@gmail.com>)
Responses Re: Replication and fsync
List pgsql-general
Thank you for the answers. I'm still confused. If fsync is not replicated to the slave, then how is replication affected by a corrupt master? If the master dies and there's a commit recorded in the wal log that didn't actually happen, wouldn't the slave still be expected to be in a sane state, with the wal logs accurately reflecting what's on disk?

Maybe I just don't understand streaming replication enough. The docs seem to say that synchronous commits mean that the slave also has to verify a write before a transaction is considered complete. How does fsync affect the way/order in which statements are sent to the slave for replication?


On Thu, Oct 24, 2013 at 9:42 AM, Alban Hertroys <haramrae@gmail.com> wrote:
On 24 October 2013 15:04, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Thu, Oct 24, 2013 at 10:39 AM,  <maillists0@gmail.com> wrote:
>> Am I wrong? If I'm wrong, is there still danger to the slave
>> in this kind of setup?
>
> No, I think.

Corruption due to fsync being off on the master will be replicated to
the slave, or - if corruption is bad enough - replication will fail to
replicate affected records entirely. Of course, turning fsync off is
no guarantee for corruption - it's the other way around: having it on
guarantees that you don't get corruption (provided that... etc).

You could disable replication while fsync is off. I'd verify the data
on the master (by creating a dump, for example) before re-enabling it
again, though.

--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.

pgsql-general by date:

Previous
From: David Johnston
Date:
Subject: Re: Wrong estimate in query plan
Next
From: Tom Lane
Date:
Subject: Re: GIST index : order Hack : getting the order used by CLUSTER .. USING my_index