I was looking into SkyTools, it sounds quite good. I am going to
revisit this PITR solution once it is implemented for sure.
Will try to keep an eye and see how it goes on live and see what
we need to adjust in time.
Thank you very much for your help really appreciated it.
Renato
Systems Administrator
e-mail: renato.oliveira@xxxxxxxxxxx
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
From: Vitaly Burshteyn
[mailto:vburshteyn@xxxxxxxxxxxx]
Sent: 15 April 2010 17:08
To: scott.lists@xxxxxxxxxxxxxxxx; Renato Oliveira
Cc: pgsql-admin@xxxxxxxxxxxxxx
Subject: Re: [ADMIN] archived WALL files question
We
manage the WAL files via skytools WALMGR
As far as log files we run a backup every 3 house and keep 12 housers worth on
the server, everything else is sent to amazon S3 via s3sync
From:
pgsql-admin-owner@xxxxxxxxxxxxxx <pgsql-admin-owner@xxxxxxxxxxxxxx>
To: Renato Oliveira <renato.oliveira@xxxxxxxxxxx>
Cc: pgsql-admin@xxxxxxxxxxxxxx <pgsql-admin@xxxxxxxxxxxxxx>
Sent: Thu Apr 15 11:56:44 2010
Subject: Re: [ADMIN] archived WALL files question
On Thu, Apr 15, 2010 at 11:31 AM, Renato Oliveira <renato.oliveira@xxxxxxxxxxx>
wrote:
Dear
all,
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.
What
do you guys do with regards to this situation, for example:
How
to you clean up the old archived logs?
For
example:
you
archive your log files from your main Postgres server to a folder /mnt/pitr for
example
You
set your standby to pick the logs from /mnt/pitr, then it archives each log as
it comes.
/mnt/pitr
will fill up very quickly and run out of space if we don’t have a process to
DELETE/ARCHIEVE older logs.
I
guess the process which picks up the logs for the standby server, needs to take
care of the logs, by deleting the older ones or by archiving them permanently?
Depends on what it is you're trying to accomplish:
*) PITR slave server constantly applying logs
If all you want is a server to constantly apply
the logs and you don't care about them afterwards, look into the '%r' macro in
pg_standby. It will automatically archive files for you -- Of course,
your standby instance needs to have write access to the /mnt/pitr folder to
delete from.
If you are using the archive_command to copy
files in the /mnt/pitr directory, and then doing a cron based copy to a backup
server, have your cronjob delete files from the primary after it is confirmed
that the logs got shipped safely to the backup.
*) Backup retention time
If you're trying to keep logs around so that
you can do a point in time recovery with old backups, you want to figure your
retention times and determine your RTO (http://en.wikipedia.org/wiki/Recovery_time_objective).
If you need to be able to recovery to
any point in time for the past 1 week with a low RTO, then you want to keep
that week's worth of logs uncompressed and available. Anything beyond
that, use a cron job to compress the logs (they usually compress pretty well
based on your data).
Basically, you need to keep all the
low-RTO required logs around so that you can quickly get at them. If you
don't have any low RTO requirements and you just want to keep a few weeks worth
of data around, I would recommend that you add a few lines of code to the end
of your backup job to compress (or you could delete if you don't want them) all
the logs prior to the backup that you are taking.
Hope this helps
--Scott
How do you guys deal with this problem?
Thank you very much in advance
Best regards
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@xxxxxxxxxxx
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
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
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 website
P Please consider the environment before printing this email
