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/
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 |