Good Day,
Alright, I changed our design to using pg_basebackup --xlog-method=stream so that the bulk of the WALs during the backup are 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 fetch them 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 might be 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 master DBs 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 only way 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 duration of 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 this specific 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
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
