Re: WAL recovery

Поиск
Список
Период
Сортировка
От CG
Тема Re: WAL recovery
Дата
Msg-id 20060222195545.39914.qmail@web32512.mail.mud.yahoo.com
обсуждение исходный текст
Ответ на Re: WAL recovery  (Jeff Frost <jeff@frostconsultingllc.com>)
Ответы Re: WAL recovery  ("Joshua D. Drake" <jd@commandprompt.com>)
Список pgsql-admin
Andy,

FWIW, I /think/ the replication scheme you are trying to carry out is
implemented in Command Prompt's "Mammoth PostgreSQL Replicator" product. From
what I understand, their system will independently copy over and replay
"TransactionLog" files (translate: WAL files?) on your slave databases in a
continuous stream or in a batch. They describe a few other features in their
product that might make the commercial option worthwhile to try.

CG

--- Jeff Frost <jeff@frostconsultingllc.com> wrote:

> On Wed, 22 Feb 2006, Andy Shellam wrote:
>
> > However, if I delete my PG data directory, restore the same base backup
> from
> > yesterday, and begin recovery, it recovers right up until the last log
> file,
> > which the previous roll-forward attempt fails.
> > The log files were fully archived off the live server to begin with so I
> > can't see it's that they've changed or anything.
> >
> > Is this scenario possible - that you can keep rolling forward over log
> files
> > as long as necessary, or do you always have to start from a base backup?
> > Nothing is changing on the spare, it's literally a sitting duck.
>
> You must always start with a base backup when you begin the restore otherwise
>
> the system does not know where to begin the recovery.  What I have done in
> the
> past on a similar system is keep the secondary DB shutdown and make base
> backups as often as possible so the recovery time is suitably short when the
> secondary is needed.  Also a good idea to do test recovers on occassion to
> make sure you don't have any corrupt WAL files.  If you use rsync, then you
> can make the base backup pretty quickly depending on how much of your DB
> changes.
>
> --
> Jeff Frost, Owner     <jeff@frostconsultingllc.com>
> Frost Consulting, LLC     http://www.frostconsultingllc.com/
> Phone: 650-780-7908    FAX: 650-649-1954
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: broken restore.sql script !?
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: WAL recovery