Re: Streaming-only Remastering

Поиск
Список
Период
Сортировка
От Rob Wultsch
Тема Re: Streaming-only Remastering
Дата
Msg-id CAGdn2ujAfqdtYijj52Bg9o+FMe-USHsUb3kAuvKQT3n=Xz2aFg@mail.gmail.com
обсуждение исходный текст
Ответ на Streaming-only Remastering  (Joshua Berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Sun, Jun 10, 2012 at 11:47 AM, Joshua Berkus <josh@agliodbs.com> wrote:
> So currently we have a major limitation in binary replication, where it is not possible to "remaster" your system
(thatis, designate the most caught-up standby as the new master) based on streaming replication only.  This is a major
limitationbecause the requirement to copy physical logs over scp (or similar methods), manage and expire them more than
doublesthe administrative overhead of managing replication.  This becomes even more of a problem if you're doing
cascadingreplication. 
>
> Therefore I think this is a high priority for 9.3.
>
> As far as I can tell, the change required for remastering over streaming is relatively small; we just need to add a
newrecord type to the streaming protocol, and then start writing the timeline change to that.  Are there other steps
requiredwhich I'm not seeing? 
>

Problem that may exist and is likely out of scope:
It is possible for a master with multiple slave servers to have slaves
which have not read all of the logs off of the master. It is annoying
to have to rebuild a replica because it was 1kb behind in reading logs
from the master. If the new master could deliver the last bit of the
old masters logs that would be very nice.

--
Rob Wultsch
wultsch@gmail.com


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Time for pgindent run?
Следующее
От: Noah Misch
Дата:
Сообщение: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)