From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "Oliver *EXTERN*" <ofabelo(at)gmail(dot)com> |
Cc: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Best backup strategy for production systems |
Date: | 2014-06-23 09:50:00 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B17D1274E@ntex2010i.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Oliver wrote:
>> About many wal generated, reading documentation, I've done a error I think .. :
[...]
>> So I modified my archive_timeout parameter to 60 .. so I understand now that it is creating wal
>> files each min. of 16MB each one, correct? Even not being fill (because there isn't activity in the
>> database), it will create wal files each min. of 16MB, and for that, I've had my archiving filesystem
>> full quickly. Correct? I've modified parameter now to original value, 0, so it is disabled now.
> I'm seeing now that my wal files are rotated each 5min, and each one has 16MB of size .. So I'm not
> understanding very well why this occurs, if I would have 60 in my archive_timeout value.
I'd say that you are hitting the default value of "checkpoint_timeout" there.
A checkpoint will generate some WAL.
As far as I remember, running into "archive_timeout" will not cause the current
segment to be archived if there has been no activity at all.
So if the database is completely idle, that's what I'd expect.
You could drastically reduce the size of archived WAL segments that are almost empty
by compressing them with something like "gzip -1".
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | John Scalia | 2014-06-23 14:24:14 | Wal archive way behind in streaming replication |
Previous Message | Евгений Селявка | 2014-06-23 08:48:45 | Re: PostgreSQL db |