Re: PITR restore hot standby

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: PITR restore hot standby
Дата
Msg-id 1116879753.3844.409.camel@localhost.localdomain
обсуждение исходный текст
Ответ на PITR restore hot standby  (Postgres General <pgsql-general@list.coretech.ro>)
Ответы Re: PITR restore hot standby  ("pgsql-general@list.coretech.ro" <pgsql-general@list.coretech.ro>)
Список pgsql-general
On Mon, 2005-05-23 at 16:17 +0300, Postgres General wrote:
> I am trying to setup a "hot standby" on a second machine.
> I have created a "recovery.conf" file and started a restore with logs
> from the primary machine. everything was OK.
>
> now a have new transaction logs generated by the primary machine and I
> want to "play" them on the secondary one. I have stopped postgres,
> recreated "recovery.conf", started postgres and I get the following error:
>
> ----------------------------------------------------------------
> LOG:  database system was shut down at 2005-05-23 05:19:34 PDT
> LOG:  starting archive recovery
> LOG:  restore_command = "/usr/cbmp/core/bin/restore_pg_tlog %f %p"
> LOG:  restored log file "0000000100000008000000C4" from archive
> LOG:  invalid resource manager ID 53 at 8/C4FFFEF8
> LOG:  invalid primary checkpoint record
> LOG:  restored log file "0000000100000008000000C4" from archive
> LOG:  invalid resource manager ID 52 at 8/C4FFFEBC
> LOG:  invalid secondary checkpoint record
> PANIC:  could not locate a valid checkpoint record
> LOG:  startup process (PID 18297) was terminated by signal 6
> LOG:  aborting startup due to startup process failure
> LOG:  logger shutting down
> ----------------------------------------------------------------
>
> what is the procedure for creating a "hot standby" (continuously feeding
> a series of WAL files created by the primary machine into the secondary
> one) ?

Sounds like you've tried to do two recoveries on the same server. The
control file doesn't match the log files you've provided to it in your
script/program, so the recovery has not been setup correctly. This
doesn't look like a bug...

The backup system doesn't know about the primary, so just let the log
files stream in and it will work. Once the recovery terminates normally,
you cannot restart it. You need to perform the base backup again and
then begin streaming the files through once more.

If you have more information, perhaps it would be possible to say more.

Professional support is available. Some enhancements should be available
in 8.1, as well as further documentation.

Best Regards, Simon Riggs
http://www.2ndquadrant.com



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

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: pg_dump in a production environment
Следующее
От: Scott Frankel
Дата:
Сообщение: Re: urgent: another postmaster