Re: PITR as Online Backup Solution

Поиск
Список
Период
Сортировка
От Andy Shellam
Тема Re: PITR as Online Backup Solution
Дата
Msg-id 20060315100023.16CA79DC891@postgresql.org
обсуждение исходный текст
Ответ на Re: PITR as Online Backup Solution  ("Thomas F. O'Connell" <tfo@sitening.com>)
Список pgsql-admin
Regarding the following questions:

> A few more questions in this thread:

> 1. With the wait-for-next-file script scenario, what happens with
> recovery.conf? Does it ever become recovery.done? What happens in the
> event of needing to recover? Does the script need a trigger to say,
> "Okay, stop waiting. We need to use what we have right now."?

Recovery.conf is still handled by postgresql in the normal way.  What you
would have to build in, is something similar to a "flag" file - ie. Tell the
script that if it can't find a file, check for the existence of a flag file,
if the flag file is not there, then continue waiting (and repeatedly check
for the flag at regular intervals.)  When it finds the flag file, we need to
"use what we have right now" and return the exit status to postgresql, which
will then rename the recovery.conf to recovery.done and startup (providing
there have been no errors in the logs).

Then when the script is running and waiting, to bring up the recovery box,
touch the location of the flag file the script is waiting to see, and at the
next check interval, your script should see the file, and return the exit
status to Postgres which will bring it up.

> 2. Are there any salient details when performing an online backup
> from one machine to another? I'm assuming filesystem is an important
> consideration since the recovery process is not like the pg_dump
> recovery process. Any other gotchas?

Mainly just watch out for symlinks (e.g. if you have tablespaces symlinked
on the live box, check the links are still valid on your recovery box - same
for the configs (postgresql.conf, pg_hba.conf, pg_ident.conf).  If you
haven't symlinked the config files on your live box, your backup dump will
have a copy of your live configuration - this may be what you want, but if
you have things like listen_addresses explicitly set to an IP address, then
it will be replicated to your recovery box and may cause Postgres to fail if
things are different between the two systems.  If you do symlink your
configs (like I do), check the symlinks on your recovery box are still
valid.

Regards

Andy



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

Предыдущее
От: "Cory Vokey"
Дата:
Сообщение: Re: Postgres process terminating
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: PITR as Online Backup Solution