Re: Synchronization levels in SR
От | marcin mank |
---|---|
Тема | Re: Synchronization levels in SR |
Дата | |
Msg-id | AANLkTi=-iHTXfTcxY2L-CX45Kuhfwnu5TS3kx5vSsJ3H@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Synchronization levels in SR (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Synchronization levels in SR
|
Список | pgsql-hackers |
On Tue, Sep 7, 2010 at 5:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > We can *not* allow the slave to replay WAL ahead of what is known > committed to disk on the master. The only way to make that safe > is the compare-notes-and-ship-WAL-back approach that Robert mentioned. > > If you feel that decoupling WAL application is absolutely essential > to have a credible feature, then you'd better bite the bullet and > start working on the ship-WAL-back code. > In the mode where it is not required that the WAL is applied (only sent to the slave / synced to slave disk) one alternative is to have a separate pointer to the last WAL record that can be safely applied on the slave. Then You can send the un-synced WAL to the slave (while concurrently syncing it on the master). When both the slave an the master sync complete, one can give the client a commit notification, increase the pointer, and send it to the slave (it would be a separate WAL record type I guess). In case of master failure, the slave can discard the un-applied WAL after the pointer. Greetings marcin
В списке pgsql-hackers по дате отправления: