MASTER
* archive_command = 'cp -v %p /var/lib/pgsql/archives/%f'
* rsync files in [MASTER:/var/lib/pgsql/archives that are +10m and delete on them once sent] to
[STANDBY:/var/lib/pgsql/archives]
STANDBY
* restore_command = 'pg_standby -d -s 2 -t /tmp/pgsql.trigger /var/lib/pgsql/archives %f %p %r 2>>standby.log'
* no cleanup to do since pg_standby cleans up old WAL's
MASTER and STANDBY are completely separate servers that do not have any common disk space.
________________________________________
From: Adrian Klaver <adrian.klaver@aklaver.com>
Sent: Thursday, April 30, 2015 7:15 PM
To: Charlton Galvarino; pgsql-general@postgresql.org
Subject: Re: [GENERAL] psql 8 warm standby strong start, weak finish
On 04/30/2015 01:49 PM, Charlton Galvarino wrote:
>>>> archiving run. Postgres will recycle WALs on its own when they are no
>>>> longer needed. Or is there is some compelling reason you want to get rid
>> of WALs?
>>>
>>> Ah. I didn't know that. I thought the cleanup was on me. Bonus!
>>
>> For more info take a look here:
>>
>> http://www.postgresql.org/docs/8.4/static/wal-configuration.html
>
> Things are running smoothly so far. The proof will be in the pudding after 48h or so. But I have changed my rsync
fromits original pull approach to push. I do need to clean up the WAL's on master once they've made it to the
warm_standby,
Why?
so in this new push approach, I only round up WAL's that are, say 10m
old, and then rsync those to warm_standby,
To the standby server pg_xlog or to the archive directory?
If it to the archive directory I am not following. The archive_command
is pushing the WALs to the archive directory and restore_command is
pulling it from that directory and then cleaning up. What is rsync doing
that is not already being done?
If directly, to the standby pg_xlog I do not see it ending well when two
independent processes are writing to the same directory.
deleting them on master when they've been xferred. warm_standby
continues to do a good job of cleaning up the archive dir w/o any fuss
from me.
>
--
Adrian Klaver
adrian.klaver@aklaver.com
