Re: WAL segement issues on both master and slave server

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Chris Kim <chrisk(at)propaas(dot)com>, pgsql-admin(at)postgresql(dot)org
Subject: Re: WAL segement issues on both master and slave server
Date: 2017-10-20 06:42:29
Message-ID: 1508481749.2624.4.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Chris Kim wrote:
> I am running into an issue with the number of files that reside on the
> pg_xlog directory of my compliance database server (This one is the
> master server in our master-slave setup). Sometime earlier this year,
> I modified the location of the PITR directory and that caused an issue
> with WAL segments not being sent to the correct location and crashing
> the DB. I went ahead and fixed that up so that it points to the correct
> location but since then the number of files on the pg_xlog directory
> went up from around 898 to 1025. I didn't have a chance to look in
> to this issue until now so my question is do you know if there is
> an easy way to clean up some of these files in the pg_xlog directory
> safely? I believe that there might be some orphaned files there and
> would like to clean those up.

You should never remove files manually from pg_xlog.

Look at "pg_stat_archiver" to see what's going on with archiving.
Is it behind schedule?

There are several settings that can cause pg_xlog to grow:
- very high wal_keep_segments
- very high checkpoint_segments

You probably have an old version of PostgreSQL if you didn't
touch the configuration in 5 years, but if not, you should also
look if there are active replication slots that keep WAL around.

> Also, on the Standby, the pg_xlog directory appears like it is growing
> on a daily basis. The WAL files are being cleaned up but I don't
> believe at a fast enough rate. This directory is approximately
> over 650GB in size and I would like to revisit if any of the parameters
> will need to be changed in the postgresql.conf file since it's almost
> 5 years since I last touched this.

Look at the "pg_stat_replication" view in the primary to see how
replication is doing.

Yours,
Laurenz Albe

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Cory Nemelka 2017-10-20 15:14:48 Re: Processing very large TEXT columns (300MB+) using C/libpq
Previous Message Aldo Sarmiento 2017-10-19 23:20:11 Re: Processing very large TEXT columns (300MB+) using C/libpq