Good Day,
Alright, I changed our design to using pg_basebackup --xlog-method=stream so that the bulk of the WALs during the
backupare taken care of by streaming as they are produced, so we might avoid the need
for feeding from the WAL archive if we choose to do this on a non-busy day (like weekend). it is pretty obvious to me
now(after much fiddling with the params on the upstream standby) that the only
server that can produce and archive WAL files is the primary master, and that anyone needing those files should try to
fetchthem from this archive.
I see a new option in archive_mode added in 9.5 : always which deals with exactly that. However I think that the docs
mightbe more informative on this, in the 9.3, 9.4 docs, like a note that
archive_command does nothing when in standby (recovery).
On 18/11/2016 18:31, Achilleas Mantzios wrote:
> Hello,
>
> We are using 9.3.10 on a hot standby, and I am trying to setup cascading replication in order to clone one of our
masterDBs to the cloud (lifting the heavy burden from the master).
> I am noticing that setting archive_mode , archive_command on the hot standby have absolutely zero effect.
> Can a standby (re)produce wal files for archiving / purposed for feeding to a downstream standby or is streaming the
onlyway it works?
> In the docs (9.3) I didn't find anything regarding those parameters when used on the standby server.
>
> Currently on the master we don't keep a window of wals large enough to contain the activity of that many days as the
durationof the cloning of the data disks to the cloud will last. I was thinking
> if we could just leave the master as is with its current (shorter term) archiving settings (3 days), and tweak only
thisspecific hot standby to archive the wals on its own, providing a larger
> window (7 days+) for the new downstream standby to catch up before we revert to streaming.
>
> Am I missing anything?
>
--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt