Re: Inconsistent DB data in Streaming Replication

On Tue, Apr 9, 2013 at 9:42 AM, Samrat Revagade
<revagade(dot)samrat(at)gmail(dot)com> wrote:
>>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.
>
> Actually we are proposing that the data page on the master is not committed
> till master receives ACK from the standby. The WAL files can be flushed to
> the disk on both the master and standby, before standby generates ACK to
> master. The end objective is the same of avoiding to take base backup of old
> master to resync with new master.

Sorry for misreading your e-mail. It seems like we are on the same
page here. I too have found this an annoying limitation in using
replication in an unreliable environment.

> Yes, taking backup is major problem when the database size is more than
> several TB. It would take very long time to ship backup data over the slow
> WAN network.

For WAN environment rsync can be a good enough answer, a tiny amount
of pages will be actually transferred. This is assuming a smallish
database and low bandwidth. For larger databases avoiding the need to
read in the whole database for differences is an obvious win.

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