From: | ohp(at)pyrenet(dot)fr |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: PITR Archive Recovery |
Date: | 2004-07-01 15:11:16 |
Message-ID: | Pine.UW2.4.53.0407011701460.28675@server.pyrenet.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Many thanks for your reply Simon
On Wed, 30 Jun 2004, Simon Riggs wrote:
> Date: Wed, 30 Jun 2004 19:29:14 +0100
> From: Simon Riggs <simon(at)2ndquadrant(dot)com>
> To: ohp(at)pyrenet(dot)fr
> Cc: pgsql-patches(at)postgresql(dot)org
> Subject: Re: [PATCHES] PITR Archive Recovery
>
> On Wed, 2004-06-30 at 12:27, ohp(at)pyrenet(dot)fr wrote:
> > Given that log files will be archieved, how can we purge them (ie know for
> > sure we won't need them anymore)
> >
>
> Good question - you're right I've not mentioned that.
>
> The answer is straightforward. Whenever you do a backup, one of the
> transaction logs will be the current one. That means any logs before the
> earliest one you can see can now be purged from the archive.
>
> So if you can see: 137,138,139 then that means anything at 136 or before
> is able to be discarded.
Ok, that's clear...
BUT not very easy to put in a backup stagtegy...
It may be ok if you user tar or cpio; but surely more complicated if you
use backup software like Netvault or Tapeware
>
> However, I'd recommend keeping more than just one backup, usually 2 or
> 3, so the actual purge point is dependant upon your data retention
> strategy, possibly linked to tape rotation etc..
>
sure
> > if I do a backup of the DATA dir, then obviously I won't need the logs
> > that were taken before. I can't just delete them all because maybe a few
> > will be archived during the backup.
> >
>
I agree
> Taking a full physical backup will normally need to exclude the pg_xlog
> directory, or at least the current xlog. Since it is being written to
> very regularly it is almost impossible to take a clean copy using
> standard utilities - though filesystem level utilities work fine.
>
Would it make sense to have SQL phrases (as I recall from my informix days
10 years ago)
like
START BACKUP LEVEL 0 where cluster would be archieved on whatever you
want, disallowing all writes and
SART BACKUP LEVEL 1 where cluster and logs would be archieved letting
read/write o databases possible...
> Best regards, Simon Riggs
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
Best regards
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp(at)pyrenet(dot)fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2004-07-01 15:28:19 | Re: [Plperlng-devel] Re: latest plperl |
Previous Message | Tom Lane | 2004-07-01 15:00:50 | Re: [PATCH] s_lock support for win32 |