Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id C1BBC632C2E for ; Mon, 19 Apr 2010 12:34:47 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 28237-02 for ; Mon, 19 Apr 2010 15:34:35 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ew0-f220.google.com (mail-ew0-f220.google.com [209.85.219.220]) by mail.postgresql.org (Postfix) with ESMTP id 0C164632A26 for ; Mon, 19 Apr 2010 12:34:34 -0300 (ADT) Received: by ewy20 with SMTP id 20so1653769ewy.21 for ; Mon, 19 Apr 2010 08:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type; bh=51zWf/4nVOR/lua8VrSkdeP2DSua4DlpKk/72j9qu7k=; b=ooLIWtsJiZRx9R5IwDSbQS71dE24KzYalX57XONOw1hd4/phdKdSohJmhjTnA8avbS lthvKyiwV/UydSSQwwnpa8dFs2UAtQ/x6gKbKOxAMPgBRWuhfvSdQ5/PYNr7p2pQfLZm nveB0QYvzDhXSX7JO0xdZhzIOqmWvUx5LBLU4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=pqHbJcEV+5IG75GyMzoc0+83XsWwMjbdFgW3vkLsKRZnDjhiunoDXHBRNqS/64Vkaa aMQUkd9WTLsVOvw/zo8Ce9jKJjzE8Mv4dVG6fQfOE4OsZIGPVraSPkhnuId/7U5b5u/+ LKr8EK7V0errcA4PzrFOTKbVIPhGwHI8qKfUE= Received: by 10.87.40.32 with SMTP id s32mr4304588fgj.21.1271691273829; Mon, 19 Apr 2010 08:34:33 -0700 (PDT) Received: from [192.168.1.253] (adsl-71-140-54-198.dsl.pltn13.pacbell.net [71.140.54.198]) by mx.google.com with ESMTPS id 23sm2161211mun.31.2010.04.19.08.34.30 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Apr 2010 08:34:32 -0700 (PDT) Message-ID: <4BCC7804.9070604@gmail.com> Date: Mon, 19 Apr 2010 08:34:28 -0700 From: Frederiko Costa User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc11 Thunderbird/3.0.4 MIME-Version: 1.0 To: pgsql-admin@postgresql.org Subject: Re: archived WALL files question References: <7965A9DCF12CC14984420BCC37B1608F25AC0B99AD@Elzar.grant.co.uk> <4BC6F21D0200002500030956@gw.wicourts.gov> <7965A9DCF12CC14984420BCC37B1608F25AC0B99E4@Elzar.grant.co.uk> In-Reply-To: <7965A9DCF12CC14984420BCC37B1608F25AC0B99E4@Elzar.grant.co.uk> Content-Type: multipart/alternative; boundary="------------040508000308080208050200" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.888 tagged_above=-10 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, T_TO_NO_BRKTS_FREEMAIL=0.01 X-Spam-Level: X-Archive-Number: 201004/256 X-Sequence-Number: 34350 This is a multi-part message in MIME format. --------------040508000308080208050200 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Renato, I had the same question. I think, as far as I understood, the point is that if you have a few base backups, not only logs replay would be faster for a recovery but also you don't need to archive WAL segments before the base backup. ** I also have a question regarding the frequency of log shipping from the primary server to a directory exported to the standby server. The standby server is stopped ready to be launched in recovery mode. The point is in the primary server. I noticed the new logs files don't get copied to the directory specified on the archive_command. It's only copied when I do the pg_start_backup()/pg_stop_backup() base backup. Is this behaviour only achieved if I set archive_timeout? I did not want to do that, because I thought as soon as the 16MB WAL segment file got created it would be copied to the exported directory. Besides, I don't think I would need to perform base backups frequently. Any advice? Thanks On 04/16/2010 12:00 AM, Renato Oliveira wrote: > I am sorry Kevin, I really appreciate your experience and your knowledge, and that's why I am asking; I thought the base backup was only necessary once. For example once you have done your first base backup, that is it, all you need is to replay the logs and backup the logs. > > What would be the reason(s) for you to do weekly base backups? > > Thank you very much > > Best regards > > Renato > > > > Renato Oliveira > Systems Administrator > e-mail:renato.oliveira@grant.co.uk > > Tel: +44 (0)1763 260811 > Fax: +44 (0)1763 262410 > http://www.grant.co.uk/ > > Grant Instruments (Cambridge) Ltd > > Company registered in England, registration number 658133 > > Registered office address: > 29 Station Road, > Shepreth, > CAMBS SG8 6GB > UK > > -----Original Message----- > > > From: Kevin Grittner [mailto:Kevin.Grittner@wicourts.gov] > Sent: 15 April 2010 17:02 > To: Renato Oliveira;pgsql-admin@postgresql.org > Subject: Re: [ADMIN] archived WALL files question > > Renato Oliveira wrote: > > >> I was reading again the documentation... "The archive command >> should generally de designed to refuse to overwrite any >> pre-existing archive file." This means it will keep writing logs >> to the folder specified forever, and without an intervention, the >> media will run out of space. >> > Overwriting an existing file wouldn't help with that, since the > filenames keep changing. It might, for example, prevent > accidentally wiping out the WAL files from one database cluster with > WAL files from another by copying the postgresql.conf file and > neglecting to change the archive script. > > >> What do you guys do with regards to this situation, for example: >> How to you clean up the old archived logs? >> > We keep two weekly base backups and all the WAL files needed to > recover from the earlier of the two to present. We also keep an > archival copy of the first base backup of each month with just the > WAL files needed to start it. We delete WAL files when no longer > needed to support this retention policy. It's all pretty automatic > based on bash scripts run from cron jobs. > > Of course, you'll want to tailor your strategy to your business > needs. > > -Kevin > > > > -----Original Message----- > > > P Please consider the environment before printing this email > CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies. > > VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s). > > OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit ourhttp://www.grant.co.uk/Support/openxml.html > > > --------------040508000308080208050200 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Renato,

I had the same question. I think, as far as I understood, the point is that if you have a few base backups, not only logs replay would be faster for a recovery but also you don't need to archive WAL segments before the base backup.

**
I also have a question regarding the frequency of log shipping  from the primary server to a directory exported to the standby server. The standby server is stopped ready to be launched in recovery mode. The point is in the primary server. I noticed the new logs files don't get copied to the directory specified on the archive_command. It's only copied when I do the pg_start_backup()/pg_stop_backup() base backup. Is this behaviour only achieved if I set archive_timeout? I did not want to do that, because I thought as soon as the 16MB WAL segment file got created it would be copied to the exported directory. Besides, I don't think I would need to perform base backups frequently.

Any advice?

Thanks

On 04/16/2010 12:00 AM, Renato Oliveira wrote:
I am sorry Kevin, I really appreciate your experience and your knowledge, and that's why I am asking; I thought the base backup was only necessary once. For example once you have done your first base backup, that is it, all you need is to replay the logs and backup the logs.

What would be the reason(s) for you to do weekly base backups?

Thank you very much

Best regards

Renato



Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

-----Original Message-----


From: Kevin Grittner [mailto:Kevin.Grittner@wicourts.gov]
Sent: 15 April 2010 17:02
To: Renato Oliveira; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] archived WALL files question

Renato Oliveira <renato.oliveira@grant.co.uk> wrote:

  
I was reading again the documentation... "The archive command
should generally de designed to refuse to overwrite any
pre-existing archive file."  This means it will keep writing logs
to the folder specified forever, and without an intervention, the
media will run out of space.
    
Overwriting an existing file wouldn't help with that, since the
filenames keep changing.  It might, for example, prevent
accidentally wiping out the WAL files from one database cluster with
WAL files from another by copying the postgresql.conf file and
neglecting to change the archive script.

  
What do you guys do with regards to this situation, for example:
How to you clean up the old archived logs?
    
We keep two weekly base backups and all the WAL files needed to
recover from the earlier of the two to present.  We also keep an
archival copy of the first base backup of each month with just the
WAL files needed to start it.  We delete WAL files when no longer
needed to support this retention policy.  It's all pretty automatic
based on bash scripts run from cron jobs.

Of course, you'll want to tailor your strategy to your business
needs.

-Kevin



-----Original Message-----


P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).

OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our http://www.grant.co.uk/Support/openxml.html


  
--------------040508000308080208050200--