PG 9.3 Switch streaming to wal shipping - Mailing list pgsql-general

From Andy Colson
Subject PG 9.3 Switch streaming to wal shipping
Date
Msg-id 5429C36D.7050607@squeakycode.net
Whole thread Raw
Responses Re: PG 9.3 Switch streaming to wal shipping
List pgsql-general
Hi All.

I have a slave that was using streaming replication, and all was well,
but its far away (remote data center), and its using too much bandwidth
at peak times.

I'm switching it to wal shipping at night.  I don't really need it
constantly up to date, nightly is good enough.

In my recovery.conf, I disabled the primary_conninfo, and have:

restore_command = 'cp /pub/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup /pub/archive/ %r'

I restart PG, and all seems well.  It reached a consisten state and
allows read-only queries.  Cool.  Except its spamming the log with lines
like:
Sep 29 15:28:13 webserv postgres[17735]: [125-1] ,,2014-09-29
15:28:13.329 CDT,: LOG:  restored log file "00000002000000B900000015"
from archive
Sep 29 15:28:18 webserv postgres[17735]: [126-1] ,,2014-09-29
15:28:18.358 CDT,: LOG:  restored log file "00000002000000B900000015"
from archive
Sep 29 15:28:23 webserv postgres[17735]: [127-1] ,,2014-09-29
15:28:23.387 CDT,: LOG:  restored log file "00000002000000B900000015"
from archive


The answer to that, I thought was pg_standby.  So I changed:

restore_command = 'pg_standby -d /pub/archive %f %p  2>>/tmp/standby.log'

I restart PG, but now it never reaches consistency, wont allow queries,
and /tmp/standbylog show's its trying to start with an old file:


Keep archive history: no cleanup required
running restore:      OK
Trigger file:         <not set>
Waiting for WAL file: 00000002000000B900000004
WAL file path:        /pub/archive/00000002000000B900000004
Restoring to:         pg_xlog/RECOVERYXLOG
Sleep interval:       5 seconds
Max wait interval:    0 forever
Command for restore:  cp "/pub/archive/00000002000000B900000004"
"pg_xlog/RECOVERYXLOG"
Keep archive history: no cleanup required
WAL file not present yet.

00000002000000B900000004 doesn't exist, I've already moved past it.
(Also, note, the first log I posted above accessing
00000002000000B900000015 is much later after me messing around some more)


I understand why cp is spamming the log, I guess, but I don't understand
why I cant just replace it with pg_standby.

Any hints on how to set this up?

Thanks for your time.

-Andy


pgsql-general by date:

Previous
From: Nick Guenther
Date:
Subject: Re: table versioning approach (not auditing)
Next
From: pbj@cmicdo.com
Date:
Subject: BDR Global Sequences