On 05-01-2015 10:02, Michael Paquier wrote:
On Mon, Jan 5, 2015 at 6:51 PM, Edson Carlos Ericksson Richter
<edsonrichter@xxxxxxxxxxx> wrote:
Would this kind of count being recorded somewhere else?
How does the server knows that the wal_segments have been exhausted?
You should evaluate the amount of wal_keep_segments necessary using
the replication lag in terms of WAL position differences (LSN) between
the master and its slaves. pg_stat_replication gives you the WAL
position (LSN) up to where each slave has received WAL information.
Combine it with pg_current_xlog_location() to determine what is the
current location master is writing WAL and you can evaluate the number
of WAL files that need to be retained on master. Knowing that each WAL
file is normally 16MB, simply use pg_xlog_location_diff to calculate
the WAL lag as a difference of bytes (for 9.4 a simple difference
operation is possible with the data type pg_lsn), and then guess from
it the number of WAL files that are actually necessary.
If you care that much about WAL retention btw, consider using
replication slots with 9.4, just be careful to monitor the partition
where pg_xlog sits in.
Despite being a completely valid statement, I've two contrary thoughts
about it:
1) I cannot migrate production servers at my free will. It requires long
planning, and probably will happen only in one or two years from now
(year end 2015 or 2016)
2) I do prefer to monitor how much wal segments I'm really using (and in
need), and then fix them up to 25% above this limit, than giving a
chance to blow my disk space (I mean, is preferable to stop replication
than put in risk whole database because of disk space)
Thanks,
Edson
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
