1

I'm using Postgresql 13 on Debian 10.6 and learning about logical replication.

I've set up logical replication with one publisher and one subscriber of one table. I'm wondering what my options are for recovering data (or rolling back) when, for example, someone accidentally does something on the publisher side like updating all the data in the table with the wrong value, or even deleting everything from a table. With logical replication these unintentional changes will of course be applied to the subscriber.

I've relentlessly searched online but have had no luck finding out what my options are. I read about PITR but I'm thinking that's suited more for physical replication, whereas I want to test rolling back changes on a specific database on a server.

Improve this question

1 Answer 1

Reset to default
1

Logical replication doesn't have anything to offer you here. PostgreSQL doesn't offer "AS OF" queries, but even if it did you could just do them in the master, rather than in the replica.

PITR is the thing you want. It is its own thing, it is not particularly tied to physical replication. About the only thing they have in common is that they both involve WAL files. I think most modern implementations of physical replication would use replication slots, not a WAL archive, which means the WAL needed to do PITR is likely not even available unless you have gone out of your way to design specifically for PITR as well as for replication.

The logical replica records all changes into its own WAL stream, including changes driven by logical replication. So if you keep a WAL archive and base backups of the replica, you could restore a copy of the replica and put it through PITR if you wanted to (but again, why not just do PITR on a copy of the master? What does doing it on a copy of the replica instead earn you?)

There are way to do in-table or out-of-table logging of row changes, and these can be used to restore tables to a prior state. But they don't have anything to do with the logical replication feature.

Improve this answer
1
  • 2
    How to handle duplicate key error on original primary node which is now serving as standby node. So when subscription is started on primary and secondary is publisher, then subscription fails with duplicate keys error as primary already has the data before node went down
    – nishi
    Commented Aug 4, 2021 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.