From: | Rhhh Lin <ruanlinehan(at)hotmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Backup strategy using 'wal_keep_segments' |
Date: | 2017-10-24 00:08:55 |
Message-ID: | DB6PR1001MB114103DDF216C69D0361BFA5AE470@DB6PR1001MB1141.EURPRD10.PROD.OUTLOOK.COM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thanks very much for your reply Michael.
I note that it looks like pgbarman employs pg_receivexlog; I will check it out.
Regards,
Ruan
________________________________
From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Sent: 22 October 2017 22:17:01
To: Rhhh Lin
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Backup strategy using 'wal_keep_segments'
On Mon, Oct 23, 2017 at 5:57 AM, Rhhh Lin <ruanlinehan(at)hotmail(dot)com> wrote:
> Is this approach feasible? Assuming obviously, we have sufficient disk space
> to facilitate 1000 WAL files etc.
You expose yourself to race conditions with such methods if a
checkpoint has the bad idea to recycle past segments that your logic
is copying. So I would advise to not do that. Instead of using the
archive command, you should also consider using pg_receivexlog
combined with a replication slot. This brings way more control with
the error handling.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Geoff Winkless | 2017-10-24 09:58:18 | Re: multiple sql results to shell |
Previous Message | Tom Lane | 2017-10-23 22:43:30 | Re: Two versions of an extension in the same cluster? |