Re: Inconsistent DB data in Streaming Replication - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Inconsistent DB data in Streaming Replication
Date
Msg-id 29529.1365603031@sss.pgh.pa.us
Whole thread Raw
In response to Re: Inconsistent DB data in Streaming Replication  (Amit Kapila <amit.kapila@huawei.com>)
Responses Re: Inconsistent DB data in Streaming Replication
Re: Inconsistent DB data in Streaming Replication
List pgsql-hackers
Amit Kapila <amit.kapila@huawei.com> writes:
> On Wednesday, April 10, 2013 3:42 PM Samrat Revagade wrote:
>> Sorry, this is incorrect. Streaming replication continuous, master is not
>> waiting, whenever the master writes the data page it checks that the WAL
>> record is written in standby till that LSN.

> I am not sure it will resolve the problem completely as your old-master can
> have some WAL extra then new-master for same timeline. I don't remember
> exactly will timeline switch feature
> take care of this extra WAL, Heikki can confirm this point?
> Also I think this can serialize flush of data pages in checkpoint/bgwriter
> which is currently not the case.

Yeah.  TBH this entire discussion seems to be "let's cripple performance
in the normal case so that we can skip doing an rsync when resurrecting
a crashed, failed-over master".  This is not merely optimizing for the
wrong thing, it's positively hazardous.  After a fail-over, you should
be wondering whether it's safe to resurrect the old master at all, not
about how fast you can bring it back up without validating its data.
IOW, I wouldn't consider skipping the rsync even if I had a feature
like this.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [BUGS] replication_timeout not effective
Next
From: Andres Freund
Date:
Subject: Re: Inconsistent DB data in Streaming Replication