Re: Inconsistent DB data in Streaming Replication

On Mon, Apr 8, 2013 at 7:38 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-04-08 19:26:33 +0300, Ants Aasma wrote:
>> 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

Yeah, this one alone makes the do-not-flush-before-replicating
approach impractical.

> * 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.

Yeah, delaying WAL writes until replication is successful seems
impractical, but I don't see why we couldn't optionally take into
account walsender write pointers when considering if we can write out
a page. Sure there will be some performance hit for waiting to
replicate WAL, but on the other hand having to rsync a huge database
isn't too good for performance either.

Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de