Re: PITR for replication?

Поиск
Список
Период
Сортировка
От Christopher Browne
Тема Re: PITR for replication?
Дата
Msg-id m33c7nxepi.fsf@wolfe.cbbrowne.com
обсуждение исходный текст
Ответ на Update on PITR  ("Simon Riggs" <simon@2ndquadrant.com>)
Список pgsql-hackers
Oops! jrogers@neopolitan.com ("J. Andrew Rogers") was seen spray-painting on a wall:
> I may be completely missing the point here, but it looks to me as
> though the PITR archival mechanism is also most of a native
> replication facility.  Is there anyone reason this couldn't be
> extended to replication, and if so, is anyone planning on using it
> as such?
>
> My memory is fuzzy on this point, but I seem to recall that this is
> (was?) how replication is more-or-less done for many of the big
> commercial RDBMS.

What isn't clear to me at this point is whether PITR is set up to
allow the database to remain "live and accessible" while updates are
being loaded in.

If that's NOT the case, then it is in no way a meaningful replacement
for replication, vastly useful though it may be.

At those times I have seen Oracle(tm) archive logs being applied to
support PITR-related functionality, the DB hasn't been "up and
running."  I suspect that may have changed by now, which would
certainly be handy for replication.
-- 
(format nil "~S@~S" "cbbrowne" "ntlug.org")
http://cbbrowne.com/info/multiplexor.html
As of next Tuesday, all terminal input will be line-at-a-time.
Please update your programs.


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

Предыдущее
От: Rod Taylor
Дата:
Сообщение: Re: Function to kill backend
Следующее
От: Chris Browne
Дата:
Сообщение: Re: Update on PITR