From: | Alexander Stoddard <alexander(dot)stoddard(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | James Keener <jim(at)jimkeener(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org, Rakesh Kumar <rakeshkumar464(at)mail(dot)com>, Kellner Thiemo <thiemo(dot)kellner(at)usb(dot)ch> |
Subject: | Re: PostgreSQL suitable? |
Date: | 2017-12-19 17:00:12 |
Message-ID: | CADDNc-CJJmMtW+muMQ0CFN5foenAGLwZcBPEpOqk7x=3DCbcZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Dec 19, 2017 at 10:39 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Greetings,
>
> * James Keener (jim(at)jimkeener(dot)com) wrote:
> > Would a storage block level incremental like zfs work?
>
> This really depends on what you want out of your backups and just
> exactly how the ZFS filesystem is set up. Remember that any backup of
> PG that doesn't use PG's start/stop backup must be atomic across all
> tablespaces and even then that really just allows you to bring PG back
> up as of that point of the snapshot. I wouldn't recommend trying to
> play WAL forward from that kind of a backup. If you use do use
> pg_start/stop_backup with ZFS snapshots, and make sure to track all of
> the WAL that's generated between the start/stop backup and ensure it's
> reliably stored, etc, then they can work, but it's not simple.
>
>
I believe that the thread started with a data warehouse use case. That
might be one application where data ingestion and processing can be stopped
and started in a controlled manner. As opposed to a continuously live
system where changes are going to continually accumulate in the WAL.
Best regards,
Alex
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2017-12-19 17:06:44 | Re: AWS Aurora and PG 10 |
Previous Message | Tory M Blue | 2017-12-19 16:59:08 | Re: AWS Aurora and PG 10 |