Re: How do I stop/disable PITR and safely clean WAL segments?

From: Vladimir Rusinov <vladimir(at)greenmice(dot)info>
To: gnanam(at)zoniac(dot)com
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: How do I stop/disable PITR and safely clean WAL segments?
Date: 2011-01-18 07:46:53
Message-ID: AANLkTikiJ2_S=fDvhkdpDp-kgVGDiLQo4KYk0wM3+g-F@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Tue, Jan 18, 2011 at 8:18 AM, Gnanakumar <gnanam(at)zoniac(dot)com> wrote:

> Hi,
>
> Our production server is running PostgreSQL v8.2.3 on CentOS release 5.2
> (Final).
>
> We've setup PITR in our production server. For some reasons, after setting
> up PITR, we're not able to manage and maintain it. Eventually, our WAL
> archive drive (secondary drive) has become full (100% use) and additional
> WAL archive segments that are to be archived got accumulated in pg_xlog/
> directory itself (which is available in primary drive)
>
> PITR SETUP DETAILS
>
> There are 2 drives:
>
> 1. Primary drive (pgsql/data/ directory resides) is 400 GB.
> 2. Secondary drive (WAL archives) is 300 GB. All WAL archives are written
> to this secondary drive.
>
> Now, we've decided to stop/disable PITR.
>
> My question is, in this situation, how do I stop/disable PITR and safely
> clean up all WAL segments from both the drives?
>
> What are the recommended/suggested ways? Experts advice/idea/suggestion on
> this are highly appreciated.
>

1. specify /bin/true as your archive comand. Postgresql will remove wal
files waiting for archiving, thinking they are copied successfully.
2. some wal files won't be removed by postgres, as they are already marked
as failed to copy. To be safe, wait N days and then remove wal files older
then N days.

BTW, I'd rather fix PITR archiving policy. You need to make snapshots
sometimes and remove old ones with old wal files. I'm usually doing weekly
snapshots keeping 2 of them and having 2 weeks of wal logs - that gives me
ability to restore at any point of the 1-2 weeks and restore would go faster
for current week (as I'll use latest snaphot for it).

--
Vladimir Rusinov
http://greenmice.info/

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Vladislav Geller 2011-01-18 07:49:05 Re: Migrating a live database
Previous Message Vladimir Rusinov 2011-01-18 07:39:32 Re: Migrating a live database