On Tue, Apr 28, 2015 at 10:00 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On 4/24/15 4:29 PM, Andres Freund wrote:
>>> Shouldn't this be backed up by pg_dump(all?)?
>>
>> Given it deals with LSNs and is, quite fundamentally due to concurrency, non transactional, I doubt it's worth it.
Theother side's slots also aren't going to be backed up as pg dump obviously can't know about then. So the represented
datawon't make much sense.
>
> I agree it might not be the best match. But we should consider that we
> used to say, a backup by pg_dumpall plus configuration files is a
> complete backup. Now we have replication slots and possibly replication
> identifiers and maybe similar features in the future that are not
> covered by this backup method.
That's true. But if you did backup the replication slots with
pg_dump, and then you restored them as part of restoring the dump,
your replication setup would be just as broken as if you had never
backed up those replication slots at all.
I think the problem here is that replication slots are part of
*cluster* configuration, not individual node configuration. If you
back up a set of nodes that make up a cluster, and then restore them,
you might hope that you will end up with working slots established
between the same pairs of machines that had working slots between them
before. But I don't see a way to make that happen when you look at it
from the point of view of backing up and restoring just one node. As
we get better clustering facilities into core, we may develop more
instances of this problem; the best way of solving it is not clear to
me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company