From: | Maletin von Oertzen <maletin(at)cpan(dot)org> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: HOT Standby - slave does not appear to be removing wal files |
Date: | 2013-05-23 13:02:10 |
Message-ID: | loom.20130515T102902-507@post.gmane.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Eduardo Morras <emorrasg <at> yahoo.es> writes:
>
> On Wed, 06 Mar 2013 19:09:43 -0700
> CS DBA <cs_dba <at> consistentstate.com> wrote:
> > We actually are in HOT standby mode, and it is working. However we are
> > also migrating a second db from an older (8.4) server into this master
> > so we did a dump (using the 9.2.2 pg_dump binary) from the 8.4 db and
> > then restored it into our current 9.2 master
>
> I don't know, but maybe the dump from 8.4 to your master is one big
transaction that must be rolled by the
> slave. So the slave must store all wal files to be able to undo the big
dump transaction.
>
> --- ---
> Eduardo Morras <emorrasg <at> yahoo.es>
>
We have the same problem, when we drop a big schema
and import it again (with \i and autocommit on).
To use pg_basebackup with the option -x, we have
wal_keep_segments set to 32.
And we use pg_archive_cleanup_command:
archive_cleanup_command='/usr/lib/postgresql/9.2/bin/pg_archivecleanup
/var/lib/postgresql/9.2/main/pg_xlog %r'
But we get at least 118 WAL-Files.
In the past, we did not set ssl_renegotiation_limit=0
and the archive_command copied quickly so many
WAL-Files to pg_xlog, that the postgresql-database
stopped with no space left on device /var.
https://bugs.launchpad.net/ubuntu/+source/postgresql-9.1/+bug/1018307
From | Date | Subject | |
---|---|---|---|
Next Message | Virupaksha Kanjilal | 2013-05-24 21:37:52 | Output of pg_controldata |
Previous Message | Amit Langote | 2013-05-23 08:33:25 | Re: WAL files not following sequence |