On Sun, Aug 21, 2016 at 1:24 PM, Craig Ringer
<craig.ringer@2ndquadrant.com> wrote:
> On 21 Aug 2016 12:36 AM, "Bruce Momjian" <bruce@momjian.us> wrote:
>> Seems like another good idea to use pg_basebackup rather than manually
>> doing base backups; Magnus has been saying this for a while.
>
> The main time that's an issue is when you're rsync'ing to save bandwidth,
> using CoW volume snapshots, etc. pg_basebackup becomes totally impractical
> on big systems.
Yes, and that's not fun. Particularly when the backup takes so long
that WAL has already been recycled... Replication slots help here but
the partitions dedicated to pg_xlog have their limit as well.
>> I supposed there is no way we could remove this error-prone behavior
>> because replication slots must survive server restarts. Is there no way
>> to know if we are starting a standby from a fresh base backup vs.
>> restarting a standby? In that case we could clear the replication
>> slots. Are there any other error-prone things copied from the master?
>
> We could remove slots when we enter archive recovery. But I've recently
> implemented support for logical decoding from standbys, which needs slots.
> Physical slot use on standby is also handy. We cannot tell whether a slot
> was created on the replica or created on the master and copied in the base
> backup and don't want to drop slots created on the replica.
>
> I also have use cases for slots being retained in restore from snapshot, for
> re-integrating restored nodes into an MM mesh.
>
> I think a recovery.conf option to remove all slots during archive recovery
> could be handy. But mostly it comes down to tools not copying them.
Yes, I'd personally let recovery.conf out of that, as well as the
removal of replication slot data when archive recovery begins to keep
the configuration simple. The decision-making of the data included in
any backup will be done by the tool itself anyway..
--
Michael
