Re: synchronous replication + fsync=off?

Tomas Vondra wrote:
> On 22 Listopad 2011, 18:16, Bruce Momjian wrote:
> > Tomas Vondra wrote:
> >> While I don't recommend it, fsync=off definitely is an option,
> >> especially
> >> with sync replication. The synchronous_commit is not a 1:1 replacement.
> >>
> >> Imagine for example a master with lot of I/O, and a sync standby. By
> >> setting fsync=off on the master and fsync=on on the slave the master
> >> does
> >> not need to wait for the fsync (so the I/O is not that stressed and can
> >> handle more requests from clients), but the slave actually does fsync.
> >>
> >> So you don't force local fsync, but you're waiting for fsync from the
> >> standby. But standby doesn't need to handle all the I/O the primary has.
> >>
> >> You can't do this with synchronous_commit - that basically forces you to
> >> do local fsync on commit, or not to wait for the commit at all.
> >>
> >> Tomas
> >>
> >> Disclaimer: I haven't actually tried this, so maybe I missed something.
> >
> > I think you did. synchronous_commit really means fsync so that the
> > system is alway consistent --- there is no waiting for the fsync to
> > happen on the master (unless I am totally missing something). With
> > fsync off, you can get into cases where the heap/index files are pushed
> > to disk before the wal gets written to disk, causing the system to be
> > inconsistent in case of a crash replay.
>
> Well, but this inconsistency can happen only on the master, right? The
> slave receives on the WAL records in order, and applies them just fine.
> And it's fsync=on so it is not vulnerable to this kind of data corruption.

True.

> When the master crashes, the recovery may fail - that's expected. The
> master would have to be rebuilt from scratch in this scenario.

Ah, the recovery perhaps doesn't generate an error. It might come up
just fine, but be inconsistent.

> Yes, I know that synchronous_commit actually guarantees data consistency.
> The point of the suggested scenario was that
>
> (a) the master does not wait for the I/O (assuming that it's busy and the
> latency would be significant)
>
> (b) the master waits for the slave (sync replication)
>
> so that you know that in case of crash of the master the slave actually
> contains all the data. That's not what synchronous_commit does - you may
> loose data if you use it.

Yes, that would work.

> > I think the only use of fsync off is for performance testing so see how
> > expensive fynsc is.
>
> There's at least one more quite commonly used scenario - restoring a
> database from backup. It often speeds the process significantly and when
> something fails, you can simply start again.

True.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +