| From: | Gustav Karlsson <Gustav(dot)Karlsson(at)BEKK(dot)no> |
|---|---|
| To: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: Deleting old WAL-files |
| Date: | 2015-05-20 05:29:41 |
| Message-ID: | 4D89A73C-B5DE-40F2-B8B7-4C9AE1E7105C@bekk.no |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Thank you all for great answers and pointing me to the relevant documentation!
Regards,
Gustav
On May 19, 2015, at 3:29 PM, Gilberto Castillo <gilberto(dot)castillo(at)etecsa(dot)cu>
wrote:
>
>
>> Gustav Karlsson wrote:
>>> I am looking for a good method of determining what WAL-segments can be
>>> deleted from our backup-
>>> archive.
>>>
>>> We are using Postgresql 9.3 and do nightly basebackups along with
>>> archiving of WAL-segments.
>>>
>>> We would like to prevent our backup-archive from growing forever, and
>>> thus delete basebackups and WAL-
>>> segments older than say 1 year.
>>>
>>> Is there a good way of finding the oldest WAL-segment needed for a given
>>> basebackup? (If not, what is
>>> the typical method for deleting old WAL-segments?)
>>
>> The backup contains a file "backup_label" which contains a line like
>>
>> START WAL LOCATION: 0/83000028 (file 000000010000000000000083)
>>
>> That is the oldest file needed for recovery.
>>
>> But a simple solution would be to keep WAL archives for one day more than
>> your oldest
>> base backup, that way you can never miss a WAL archive that you need.
>
> See you:
>
> http://www.postgresql.org/docs/current/static/pgarchivecleanup.html
>
>
>
> Saludos,
> Gilberto Castillo
> ETECSA, La Habana, Cuba
> ---
> This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE running at host imx3.etecsa.cu
> Visit our web-site: <http://www.kaspersky.com>, <http://www.viruslist.com>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas SIMON | 2015-05-20 15:41:45 | Re: Performances issues with SSD volume ? |
| Previous Message | Wei Shan | 2015-05-20 02:48:43 | Re: Create Index CONCURRENTLY Hangs Indefinitely. |