Re: Issues with Quorum Commit

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Issues with Quorum Commit
Дата
Msg-id 4CAF71AE.5040006@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Issues with Quorum Commit  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Issues with Quorum Commit  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
On 08.10.2010 17:26, Fujii Masao wrote:
> On Fri, Oct 8, 2010 at 5:10 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com>  wrote:
>> Do we really need that?
>
> Yes. But if there is no unsent WAL when the master goes down,
> we can start new standby without new backup by copying the
> timeline history file from new master to new standby and
> setting recovery_target_timeline to 'latest'.

.. and restart the standby.

> In this case,
> new standby advances the recovery to the latest timeline ID
> which new master uses before connecting to the master.
>
> This seems to have been successful in my test environment.
> Though I'm missing something.

Yeah, that should work, but it's awfully complicated.

>> I don't think that's acceptable, we'll need to fix
>> that if that's the case.
>
> Agreed.
>
>> You can cross timelines with the archive, though. But IIRC there was some
>> issue with that too, you needed to restart the standbys because the standby
>> scans what timelines exist at the beginning of recovery, and won't notice
>> new timelines that appear after that?
>
> Yes.
>
>> We need to address that, apart from any of the other things discussed wrt.
>> synchronous replication. It will benefit asynchronous replication too. IMHO
>> *that* is the next thing we should do, the next patch we commit.
>
> You mean to commit that capability before synchronous replication? If so,
> I disagree with you. I think that it's not easy to address that problem.
> So I'm worried about that implementing that capability first means the miss
> of sync rep in 9.1.

It's a pretty severe shortcoming at the moment. For starters, it means 
that you need a shared archive, even if you set wal_keep_segments to a 
high number. Secondly, it's a lot of scripting to get it working, I 
don't like the thought of testing failovers in synchronous replication 
if I have to do all that. Frankly, this seems more important to me than 
synchronous replication.

It shouldn't be too hard to fix. Walsender needs to be able to read WAL 
from preceding timelines, like recovery does, and walreceiver needs to 
write the incoming WAL to the right file.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Rob Wultsch
Дата:
Сообщение: Re: Issues with Quorum Commit
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WIP: Triggers on VIEWs