Re: Replication and fsync

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(at)gmail(dot)com> wrote:

> On 24 October 2013 15:04, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> > On Thu, Oct 24, 2013 at 10:39 AM, <maillists0(at)gmail(dot)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.
>