|
Hi Scott, Yes, I thought of increasing wal_keep_segments but it doesn’t seem to be a bullet proof solution. It locks that much space and most of the time it is a wasted space since streaming will be working and you really
don’t need these logs hanging around. Besides, things work fine in primary->slave configuration because archive_command ships the logs constantly to slave and if slave is in good hands of streaming it cleans up the logs. It will use it only when
it is necessary for gap resolution. However, it doesn’t work from slave->slave configuration because the archive_command has no meaning there while it is recovery mode and it has no logs of its own. This restriction limits the cascade feature and makes it fragile in my opinion. It could break anytime and you end up rebuilding. Thanks, Murthy From: pgsql-admin-owner@xxxxxxxxxxxxxx [mailto:pgsql-admin-owner@xxxxxxxxxxxxxx]
On Behalf Of Scott Whitney My only response that might help you with this is that my setup is: Server 1) primary production db server (5432) Server 2) replicates production (5432) also primary for non-production use (6432) Server 3) (offsite) replicates #2 (5432 -> 7432 internally and 6432 -> 6432) AND hosts internal databases So: 1) Production 2) Replication + non production 3) Internal + replication of NON production + replication of PRODUCTION (via the cascaded server) I would find that when replicating the PRODUCTION server internally (#3), I had not set wal_keep_segments high enough, due to the lag of WAN replication, production and non production would replicate fine (gigabit backend), but sometimes when a load of data was being updated/moved/deleted, the offsite (#3) would fall behind far enough that it could not recover without a new pg base backup, in essence setting up replication again. I solved this by upping the wal_keep_segments.
|
