Re: Inconsistent DB data in Streaming Replication

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Inconsistent DB data in Streaming Replication
Дата
Msg-id 29529.1365603031@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Inconsistent DB data in Streaming Replication  (Amit Kapila <amit.kapila@huawei.com>)
Ответы Re: Inconsistent DB data in Streaming Replication  (Andres Freund <andres@2ndquadrant.com>)
Re: Inconsistent DB data in Streaming Replication  (Shaun Thomas <sthomas@optionshouse.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [BUGS] replication_timeout not effective
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Inconsistent DB data in Streaming Replication