From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Albert Shih <Albert(dot)Shih(at)obspm(dot)fr> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: How to manage WAL |
Date: | 2010-02-11 23:39:30 |
Message-ID: | 20100211233930.GL3145@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Albert Shih wrote:
> Le 11/02/2010 à 17:00:33-0600, Kevin Grittner a écrit
> > Albert Shih <Albert(dot)Shih(at)obspm(dot)fr> wrote:
> >
> > > I would like to known what's best way to manage the WAL.
> >
> > You should design a policy which meets your particular needs. We
> > keep two PITR base backups and all the WAL files from before the
> > start of the first (based on the information in the backup file)
> > through current. We also save monthly archival PITR base backups
> > with just the WAL files needed to restore them (again, based on the
> > backup files). Your needs may be different.
>
> Hum...I'm not sure I really understand what you doing.
>
> Maybe I'm doing everything wrong but this is what I did :
>
> t=0 SELECT pg_start_backup('label');
> rsync /pgsql backup_server:/
> SELECT pg_stop_backup();
>
> t> 1 cron with rsync /WAL backup_server:
>
> but after some time the /WAL become big. So is it a solution to
> stop the database, delete everything in /WAL and begin a new cycle (t=0 select etc...) ?
You could do that if you wanted, but there's a window during which you
have no backup at all. Perhaps it's better to take a second base
backup, start archiving to a different directory /WAL2, and when the
second base backup is done you can delete /WAL
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Renato Oliveira | 2010-02-12 09:58:38 | PG_DUMP backup |
Previous Message | Albert Shih | 2010-02-11 23:32:25 | Re: How to manage WAL |