You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'll create an issue for this, hope one day we will implement it. Does not seem a big chunk of work and testing. Though I expect only hard-boiled DBA want something like this.
Currently, delta backups are applied on top of other backups. Either base backup or other delta backup.
Delta backup Y from backup X contains all blocks changed since the start of backups X. Also, Y will contain all files WAL-G cannot track blockwise: SLRUs, configs, FSMs, VMs etc.
When a replica is falling behind the primary we can use information from delta-backup to jump through the WAL history: we know blocks numbers that need to be updated.
Here I propose to implement command like wal-g catchup PATH --from-lsn LSN.
PATH should contain PGDATA shut down in recovery somewhere after LSN. WAL-G will look through delta backups and try to restore on most recent point in the history of the backup.
O has somewhat similar functionality in RMAN.
We can read LSN from pg_control, but this seems too intrusive.
The text was updated successfully, but these errors were encountered:
I'll create an issue for this, hope one day we will implement it. Does not seem a big chunk of work and testing. Though I expect only hard-boiled DBA want something like this.
Currently, delta backups are applied on top of other backups. Either base backup or other delta backup.
Delta backup Y from backup X contains all blocks changed since the start of backups X. Also, Y will contain all files WAL-G cannot track blockwise: SLRUs, configs, FSMs, VMs etc.
When a replica is falling behind the primary we can use information from delta-backup to jump through the WAL history: we know blocks numbers that need to be updated.
Here I propose to implement command like
wal-g catchup PATH --from-lsn LSN
.PATH should contain PGDATA shut down in recovery somewhere after LSN. WAL-G will look through delta backups and try to restore on most recent point in the history of the backup.
O has somewhat similar functionality in RMAN.
We can read LSN from pg_control, but this seems too intrusive.
The text was updated successfully, but these errors were encountered: