Re: Configuring synchronous replication
От | Aidan Van Dyk |
---|---|
Тема | Re: Configuring synchronous replication |
Дата | |
Msg-id | 20100917153033.GF12415@oak.highrise.ca обсуждение исходный текст |
Ответ на | Re: Configuring synchronous replication (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Configuring synchronous replication
|
Список | pgsql-hackers |
* Robert Haas <robertmhaas@gmail.com> [100917 11:24]: > On Fri, Sep 17, 2010 at 11:22 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > > On Fri, 2010-09-17 at 09:36 -0400, Aidan Van Dyk wrote: > > > >> I want to have them configured in a fsync WAL/style sync rep, I want to > >> make sure that if the master comes up first after I get power back, it's > >> not going to be claiming transactions are committed while the slave > >> (which happens to have 4x the disks because it keeps PITR backups for a > >> period too) it still chugging away on SCSI probes yet, not gotten to > >> having PostgreSQL up yet... > > > > Nobody has mentioned the ability to persist the not-committed state > > across a crash before, and I think it's an important discussion point. > > Eh? I think all Aidan is asking for is the ability to have a mode > where sync rep is really always sync, or nothing commits. Rather than > timing out and continuing merrily on its way... Right, I'm not asking for a "new" mode. I'm just hope that there will be a way to guarantee my "sync rep" is actually replicating. Having it "not replicate" simply because no slave has (yet) connected means I have to dance jigs around pg_hba.conf so that it won't allow non-replication connections until I've manual verified that the replication slave is connected... a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
В списке pgsql-hackers по дате отправления: