| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Arjun Ranade <ranade(at)nodalexchange(dot)com> |
| Cc: | Scot Kreienkamp <Scot(dot)Kreienkamp(at)la-z-boy(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_dump on a standby for a very active master |
| Date: | 2019-02-12 17:59:40 |
| Message-ID: | 20190212175940.GQ6197@tamriel.snowman.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-general |
Greetings,
* Arjun Ranade (ranade(at)nodalexchange(dot)com) wrote:
> Yeah, that was one thing I was planning to try. The other potential
> solution is to use barman (we are using barman on all db servers including
> standbys) to restore the latest backup to a VM and then take the pg_dump
> from there. But I was hoping there would be a way in the settings to
> prevent such a workaround.
Performing a file-level backup and then restoring that and then
taking a pg_dump of restored cluster works quite well as a solution, in
my experience, even better is when you can do a delta restore over top
of the prior restore, updating just the files which were different, as
that can be much faster.
Thanks!
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Arjun Ranade | 2019-02-12 18:02:38 | Re: pg_dump on a standby for a very active master |
| Previous Message | Scot Kreienkamp | 2019-02-12 17:36:08 | RE: pg_dump on a standby for a very active master |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Arjun Ranade | 2019-02-12 18:02:38 | Re: pg_dump on a standby for a very active master |
| Previous Message | Scot Kreienkamp | 2019-02-12 17:36:08 | RE: pg_dump on a standby for a very active master |