Re: Inconsistent DB data in Streaming Replication
От | Andres Freund |
---|---|
Тема | Re: Inconsistent DB data in Streaming Replication |
Дата | |
Msg-id | 20130408163822.GB29465@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Inconsistent DB data in Streaming Replication (Ants Aasma <ants@cybertec.at>) |
Ответы |
Re: Inconsistent DB data in Streaming Replication
|
Список | pgsql-hackers |
On 2013-04-08 19:26:33 +0300, Ants Aasma wrote: > On Mon, Apr 8, 2013 at 6:50 PM, Shaun Thomas <sthomas@optionshouse.com> wrote: > > On 04/08/2013 05:34 AM, Samrat Revagade wrote: > > > >> One solution to avoid this situation is have the master send WAL > >> records to standby and wait for ACK from standby committing WAL files > >> to disk and only after that commit data page related to this > >> transaction on master. > > > > > > Isn't this basically what synchronous replication does in PG 9.1+? > > Not exactly. Sync-rep ensures that commit success is not sent to the > client before a synchronous replica acks the commit record. What > Samrat is proposing here is that WAL is not flushed to the OS before > it is acked by a synchronous replica so recovery won't go past the > timeline change made in failover, making it necessary to take a new > base backup to resync with the new master. I seem to remember this > being discussed when sync rep was committed. I don't recall if the > idea was discarded only on performance grounds or whether there were > other issues too. Thats not going to work for a fair number of reasons: * wal is streamed *from disk* not from memory * what if the local node crashes/restarts immediately? Then the standby is farther ahead than the master. * the performance implications of never writing data before flushing it are pretty severe * ... So this doesn't seem to solve anything. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: