Re: WAL recovery

From: CG <cgg007(at)yahoo(dot)com>
To: pgsql-admin(at)postgresql(dot)org, Jeff Frost <jeff(at)frostconsultingllc(dot)com>, Andy Shellam <andy(dot)shellam(at)mailnetwork(dot)co(dot)uk>
Subject: Re: WAL recovery
Date: 2006-02-22 19:55:45
Message-ID: 20060222195545.39914.qmail@web32512.mail.mud.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)frostconsultingllc(dot)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(at)frostconsultingllc(dot)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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Joshua D. Drake 2006-02-22 20:09:11 Re: WAL recovery
Previous Message Tom Lane 2006-02-22 18:59:35 Re: broken restore.sql script !?