From: | Rhhh Lin <ruanlinehan(at)hotmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Backup strategy using 'wal_keep_segments' |
Date: | 2017-10-31 09:53:46 |
Message-ID: | DB6PR1001MB11412F77A33606545F2AFEFDAE5E0@DB6PR1001MB1141.EURPRD10.PROD.OUTLOOK.COM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Stephen,
Thanks for replying.
I would actually be an advocate for using a proper archive_command in order to facilitate a proper (Per the documentation) PITR and backup strategy.
However, a colleague had suggested such a creative approach (Possibly, less administrative overhead, ease of maintenance? I'm not sure) and I struggled to find any evidence online in blogs/white-papers/documentation that this was a feasible approach. That said, I couldn't find any info rejecting it as a method either, which led me to post here. Essentially, this was a difference of opinion on approach, and I was looking to gather information in order to make an informed opposing argument.
My only thought now would be how could I decipher, within the sequence chain of WAL files, up to which file has the "archival" progressed to. i.e. which files are not susceptible to being called upon again for restartpoints/checkpoints. That is, where is my absolute point (or file) of archival using something along the lines of 'pg_current_xlog_location'.
Regards,
Ruan
________________________________
From: Stephen Frost <sfrost(at)snowman(dot)net>
Sent: 30 October 2017 16:41:11
To: Rhhh Lin
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Backup strategy using 'wal_keep_segments'
Greetings,
* Rhhh Lin (ruanlinehan(at)hotmail(dot)com) wrote:
> A colleague recently suggested that instead of implementing an 'archive_command' to push archivable WALs to a secondary location (for further backup to tape for example), we could instead persist the WAL files in their current location by setting the "wal_keep_segments" parameter to an extreme value e.g. 1000 and have the 'archive_command' do nothing.
Michael's points are good and I wouldn't recommend using this archive
command either, but what isn't clear to me is what you're actaully
trying to solve by using such a method..? You haven't said anywhere
what's wrong with archive_command (I know that there certainly are some
things wrong with it, of course, but there are solutions to a number of
those issues that isn't a hack like this ...).
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-10-31 10:27:58 | Re: Backup strategy using 'wal_keep_segments' |
Previous Message | John R Pierce | 2017-10-31 07:57:50 | Re: How to access a second database |