DimCitus
commented
2 years ago I have a WIP branch that adds support for WAL-G to pg_auto_failover and that includes pushing and fetching base backups stored on a Cloud somewhere, and also proper integration of an archive_command and of a restore_command. We will see about the Postgres 13 pg_rewind --restore-target-wal option when I get to open the PR with my branch, thanks for the reminder.
I am not sure about making replication slots optional ; though I must admit that having a reliable restore_command hints at them not being that useful anymore. This might be done in a separate later release though.
Tiago-Anastacio
Hello,
Use case: From Postgres 13 when pg_rewind don't succeed on resynchronizing former primary, just because some WALS are missing, it is now possible to tell pg_rewind to look for them in WAL archives with option --restore-target-wal
pg_auto_failover under the hood uses pg_rewind to synchronize former primary with current one. When pg_rewind fails it triggers a full backup of current primary (through pg_basebackup )
This requires handle of restore_command in pg_autofailover (new parameter) , not only when resyncing former primary but also when building new replicas. And, probably, add a new parameter to turn replication slots optionnals (because you mostly don't need it when using log fishing replication e.g. using restore_command).
Today modern storage solutions Azure blob, S3 like formats, provide a remote storage for the backup repository (all without ssh), this is why restore_command parameter has turn a new life.
It is not that easy, but if we can avoid a full backup (particularly through pg_basebackup) it's worth it, particularly on very large databases. Nowadays, most advanced automatic failover tools handle this use case.
Thank you Tiago ANASTACIO