Re: Synchronous Log Shipping Replication
От | Heikki Linnakangas |
---|---|
Тема | Re: Synchronous Log Shipping Replication |
Дата | |
Msg-id | 48C780EA.3090107@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Synchronous Log Shipping Replication (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Synchronous Log Shipping Replication
Re: Synchronous Log Shipping Replication |
Список | pgsql-hackers |
Simon Riggs wrote: > On Wed, 2008-09-10 at 13:28 +0900, Fujii Masao wrote: >> On Tue, Sep 9, 2008 at 8:38 PM, Heikki Linnakangas >> <heikki.linnakangas@enterprisedb.com> wrote: >>> There's one thing I haven't figured out in this discussion. Does the write >>> to the disk happen before or after the write to the slave? Can you guarantee >>> that if a transaction is committed in the master, it's also committed in the >>> slave, or vice versa? > > The write happens concurrently and independently on both. > > Yes, you wait for the write *and* send pointer to be "flushed" before > you allow a synch commit with synch replication. (Definition of flushed > is changeable by parameters). The thing that bothers me is the behavior when the synchronous slave doesn't respond. A timeout has been discussed, after which the master just gives up on sending, and starts acting as if there's no slave. How's that different from asynchronous mode where WAL is sent to the server concurrently when it's flushed to disk, but we don't wait for the send to finish? ISTM that in both cases the only guarantee we can give is that when a transaction is acknowledged as committed, it's committed in the master but not necessarily in the slave. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: