pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
What to do when pg_xlog directory has filled up the filesystem
4+ messages / 3 participants
[nested] [flat]

* What to do when pg_xlog directory has filled up the filesystem
@ 2015-01-23 16:00  John Scalia <jayknowsunix@gmail.com>
  0 siblings, 1 reply; 4+ messages in thread

From: John Scalia @ 2015-01-23 16:00 UTC (permalink / raw)
  To: pgsql-admin

Hi all,

Just curious about this issue as it has occurred on my 9.4.0 sandbox primary server. The link to the directory specified in archive_command had disappeared, so the command 
specified in archive_command kept failing overnight. This resulted in many WAL segments piling up in the pg_xlog directory and a bunch of <wal name>.ready files appearing in the 
pg_xlog/archive.status directory. The filesystem had reached 100% full so the database quit and would not restart. I've thought about just moving some of the WAL segments 
temporarily to another filesystem, but which ones, oldest or newest? And is that really the best way to deal with this or what is the best way to deal with this kind of issue?
--
Jay


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin



^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: What to do when pg_xlog directory has filled up the filesystem
@ 2015-01-23 16:33  Jeff Frost <jeff@pgexperts.com>
  parent: John Scalia <jayknowsunix@gmail.com>
  0 siblings, 2 replies; 4+ messages in thread

From: Jeff Frost @ 2015-01-23 16:33 UTC (permalink / raw)
  To: John Scalia <jayknowsunix@gmail.com>; +Cc: pgsql-admin


> On Jan 23, 2015, at 08:00, John Scalia <jayknowsunix@gmail.com> wrote:
> 
> Hi all,
> 
> Just curious about this issue as it has occurred on my 9.4.0 sandbox primary server. The link to the directory specified in archive_command had disappeared, so the command specified in archive_command kept failing overnight. This resulted in many WAL segments piling up in the pg_xlog directory and a bunch of <wal name>.ready files appearing in the pg_xlog/archive.status directory. The filesystem had reached 100% full so the database quit and would not restart. I've thought about just moving some of the WAL segments temporarily to another filesystem, but which ones, oldest or newest? And is that really the best way to deal with this or what is the best way to deal with this kind of issue?

If you are on ext4, you can just:

tune2fs -m 0 /dev/sda1

Or whatever device you're talking about. 

That will reset the reserved space to 0.

Then you can start up PostgreSQL and let it do the archiving. After it's done:

tune2fs -m 5 /dev/sda1

To put it back to the default. 



-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin



^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: What to do when pg_xlog directory has filled up the filesystem
@ 2015-01-23 16:52  John Scalia <jayknowsunix@gmail.com>
  parent: Jeff Frost <jeff@pgexperts.com>
  1 sibling, 0 replies; 4+ messages in thread

From: John Scalia @ 2015-01-23 16:52 UTC (permalink / raw)
  To: Jeff Frost <jeff@pgexperts.com>; +Cc: pgsql-admin


On 1/23/2015 11:33 AM, Jeff Frost wrote:
>> On Jan 23, 2015, at 08:00, John Scalia <jayknowsunix@gmail.com> wrote:
>>
>> Hi all,
>>
>> Just curious about this issue as it has occurred on my 9.4.0 sandbox primary server. The link to the directory specified in archive_command had disappeared, so the command specified in archive_command kept failing overnight. This resulted in many WAL segments piling up in the pg_xlog directory and a bunch of <wal name>.ready files appearing in the pg_xlog/archive.status directory. The filesystem had reached 100% full so the database quit and would not restart. I've thought about just moving some of the WAL segments temporarily to another filesystem, but which ones, oldest or newest? And is that really the best way to deal with this or what is the best way to deal with this kind of issue?
> If you are on ext4, you can just:
>
> tune2fs -m 0 /dev/sda1
>
> Or whatever device you're talking about.
>
> That will reset the reserved space to 0.
>
> Then you can start up PostgreSQL and let it do the archiving. After it's done:
>
> tune2fs -m 5 /dev/sda1
>
> To put it back to the default.
>
Thanks, Jeff!


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin



^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: What to do when pg_xlog directory has filled up the filesystem
@ 2015-01-24 02:56  Cliff Pratt <enkiduonthenet@gmail.com>
  parent: Jeff Frost <jeff@pgexperts.com>
  1 sibling, 0 replies; 4+ messages in thread

From: Cliff Pratt @ 2015-01-24 02:56 UTC (permalink / raw)
  To: Jeff Frost <jeff@pgexperts.com>; +Cc: John Scalia <jayknowsunix@gmail.com>; pgsql-admin

That works with ext3 too.

Cheers,

Cliff

On Sat, Jan 24, 2015 at 5:33 AM, Jeff Frost <jeff@pgexperts.com> wrote:

>
> > On Jan 23, 2015, at 08:00, John Scalia <jayknowsunix@gmail.com> wrote:
> >
> > Hi all,
> >
> > Just curious about this issue as it has occurred on my 9.4.0 sandbox
> primary server. The link to the directory specified in archive_command had
> disappeared, so the command specified in archive_command kept failing
> overnight. This resulted in many WAL segments piling up in the pg_xlog
> directory and a bunch of <wal name>.ready files appearing in the
> pg_xlog/archive.status directory. The filesystem had reached 100% full so
> the database quit and would not restart. I've thought about just moving
> some of the WAL segments temporarily to another filesystem, but which ones,
> oldest or newest? And is that really the best way to deal with this or what
> is the best way to deal with this kind of issue?
>
> If you are on ext4, you can just:
>
> tune2fs -m 0 /dev/sda1
>
> Or whatever device you're talking about.
>
> That will reset the reserved space to 0.
>
> Then you can start up PostgreSQL and let it do the archiving. After it's
> done:
>
> tune2fs -m 5 /dev/sda1
>
> To put it back to the default.
>
>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
>

^ permalink  raw  reply  [nested|flat] 4+ messages in thread


end of thread, other threads:[~2015-01-24 02:56 UTC | newest]

Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2015-01-23 16:00 What to do when pg_xlog directory has filled up the filesystem John Scalia <jayknowsunix@gmail.com>
2015-01-23 16:33 ` Jeff Frost <jeff@pgexperts.com>
2015-01-23 16:52   ` John Scalia <jayknowsunix@gmail.com>
2015-01-24 02:56   ` Cliff Pratt <enkiduonthenet@gmail.com>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox