Warm Standby - log shipping

Поиск
Список
Период
Сортировка
От Mark Steben
Тема Warm Standby - log shipping
Дата
Msg-id D52D639EA1DC422DA3807EB17AF72239@dei26g028534
обсуждение исходный текст
Ответы Re: Warm Standby - log shipping  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Warm Standby - log shipping  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Warm Standby - log shipping  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-admin
Hi folks,
I'm learning to use log shipping in our development environment with the
expectation to use it
In production next month.
We are at postgresql 8.2.5  Our master is in Massachusetts and our standby
is in Norfolk, Va.
We plan on using the Norfolk server not so much as a recovery failover but
as a replicated database
To run reports and establish a data warehousing environment.  As such the
plan is to run  the
Standby in recovery state for the majority of the day, then 'complete'
recovery there, bring it
Online, perform our reporting and data warehousing functions (in read-only
mode of course),
Then bring it back into recovery mode, letting the updates catch up for the
next days processing.

My questions are:

1. Is this a proper usage of log shipping?
2. If yes, what are the preferred mechanisms for forcing a standby server to
'complete' a recovery, then to force it back into recovery mode once
everything is finished.  So far, I have simply stopped the server, renamed
the recovery.conf file then restarted the server.
When done, I go the other way.  This doesn't always work as there are files
sometimes being copied from master to standby, then get only partially
copied into the pg_xlog directory on the standby.  I do use a script in
recovery.conf that 'waits' for xlogs to be copied over
but the problem occurs when I am not in recovery mode and the recovery.conf
file is not being invoked.
3. I am currently in a state where a log got partially copied and postgres
cannot find a valid checkpoint to restart.  What is the best way to remedy
this situation?  Pg_resetxlog perhaps?

Thanks for your help

Mark Steben│Database Administrator│
@utoRevenue-R- "Join the Revenue-tion"
COME SEE US AT NADA BOOTH #1021, HALL B,  IN NEW ORLEANS!
95 Ashley Ave. West Springfield, MA., 01089
413-243-4800 x1512 (Phone) │ 413-732-1824 (Fax)
@utoRevenue is a registered trademark and a division of Dominion Enterprises






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

Предыдущее
От: Chris Browne
Дата:
Сообщение: Re: password strength verification
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Warm Standby - log shipping