Re: synchronous replication + fsync=off?

Поиск
Список
Период
Сортировка
Искать
От
Bruce Momjian
Тема
Re: synchronous replication + fsync=off?
Дата
Msg-id
201111221716.pAMHG8T07354@momjian.us
Ответ на
Список
Дерево обсуждения
synchronous replication + fsync=off? "Schubert, Joerg" <jschubert@cebacus.de>
Re: synchronous replication + fsync=off? Jaime Casanova <jaime@2ndquadrant.com>
Re: synchronous replication + fsync=off? "Tomas Vondra" <tv@fuzzy.cz>
Re: synchronous replication + fsync=off? Bruce Momjian <bruce@momjian.us>
Re: synchronous replication + fsync=off? "Tomas Vondra" <tv@fuzzy.cz>
Re: synchronous replication + fsync=off? Bruce Momjian <bruce@momjian.us>
Re: synchronous replication + fsync=off? Robert Treat <rob@xzilla.net>
Re: synchronous replication + fsync=off? Scott Marlowe <scott.marlowe@gmail.com>
Re: synchronous replication + fsync=off? Gregg Jaskiewicz <gryzman@gmail.com>
Tomas Vondra wrote:
> On 17 Listopad 2011, 17:07, Jaime Casanova wrote:
> > On Thu, Nov 17, 2011 at 7:52 AM, Schubert, Joerg 
> > wrote:
> >> Hello,
> >>
> >> I have two servers with battery backed power supply (USV). So it is
> >> unlikely, that both will crash at the same time.
> >>
> >> Will synchronous replication work with fsync=off?
> >> That means we will commit to system cache, but not to disk. Data will
> >> not
> >> survive a system crash but the second system should still be consistent.
> >>
> >
> > you should never use fsync=off (in production at least)
> >
> > the appropiate parameter to use is synchronous_commit which is the one
> > that controls synchronous replication:
> > off = no local nor remote synchronous commit
> > local = local synchronous commit but no remote
> > on = both, local and remote, synchronous commit
> >
> > synchronous commit = flushed to disk
> 
> 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.  

I think the only use of fsync off is for performance testing so see how
expensive fynsc is.


-- 
  Bruce Momjian          http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
В списке pgsql-general по дате отправления
От: khizer
Дата:
Сообщение: pg_standby for postgresql8.2
От: Kenneth Tilton
Дата:
FAQ