Skip site navigation (1) Skip section navigation (2)

Re: Warm Standby - log shipping

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Mark Steben" <msteben(at)autorevenue(dot)com>,<pgsql-admin(at)postgresql(dot)org>
Subject: Re: Warm Standby - log shipping
Date: 2008-12-18 22:19:38
Message-ID: 494A7819.EE98.0025.0@wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-admin
>>> "Mark Steben" <msteben(at)autorevenue(dot)com> wrote: 
 
> We are at postgresql 8.2.5
 
You really should update to 8.2.11 or consider going to 8.3.5.
 
http://www.postgresql.org/support/versioning
 
> 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?
 
Once you complete recovery you don't have a good way back, short of
getting a new base backup.  If you have space, you could stop the
replica server without leaving recovery state, do a copy of the
cluster to another directory, restart your replica, start the copied
cluster's server, complete recovery, and start running your reports.
 
> 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?
 
I'd get a fresh base backup from which to start.
 
-Kevin

In response to

Responses

pgsql-admin by date

Next:From: Joshua D. DrakeDate: 2008-12-18 22:20:35
Subject: Re: Warm Standby - log shipping
Previous:From: Mark StebenDate: 2008-12-18 21:43:10
Subject: Warm Standby - log shipping

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group