| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Implementing incremental backup |
| Date: | 2013-06-19 22:29:34 |
| Message-ID: | CAGTBQpZcoNKwTpMKzRy0kNQmpefxss7SneDdVixLDCKGopO8cA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 19, 2013 at 7:18 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> If you have the two technologies, you could teach them to work in
> conjunction: you set up WAL replication, and tell the WAL compressor to
> prune updates for high-update tables (avoid useless traffic), then use
> incremental backup to back these up. This seems like it would have a
> lot of moving parts and be rather bug-prone, though.
I don't think it would be worse than storage-manager-level stuff. And
though more complex, don't underestimate the pros: lower footprint,
better scalability, and you get consistent online backups.
That mechanism can also be used to distill a list of modified pages,
mind you, instead of hooking into storage-manager stuff. The pro
there, is that it wouldn't amplify writes. The con there is that you
don't get consistent online backups.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2013-06-19 22:39:13 | Re: Implementing incremental backup |
| Previous Message | Tom Lane | 2013-06-19 22:23:02 | Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |