Search Postgresql Archives

Re: synchronous replication + fsync=off?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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


-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux