| From: | David Steele <david(at)pgmasters(dot)net> |
|---|---|
| To: | Ron <ronljohnsonjr(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Barman versus pgBackRest |
| Date: | 2018-09-04 16:33:34 |
| Message-ID: | 610d537a-fc2e-0938-c623-feeccca0aa64@pgmasters.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 9/4/18 7:41 AM, Ron wrote:
> On 03/09/2018 08:56 AM, David Steele wrote:
>
>>> - use replication slots for backingup wal on the backup server.
>> Another good feature. We have not added it yet because pgBackRest was
>> originally written for very high-volume clusters (100K+ WAL per day) and
>> our parallel async feature answers that need much better. We recommend
>> a replicated standby for more update-to-date data.
>
> Every N minutes you copy the WAL files to the backup server?
[Accidentally hit send on the previous post, here's the rest...]
WAL segments are transferred whenever Postgres indicates that a segment
is finished via the archive_command. Async archiving "looks ahead" to
find WAL segments that are ready to archive.
You can use archive_timeout to force Postgres to push a WAL segment
every N seconds for clusters that have idle time.
Regards,
--
-David
david(at)pgmasters(dot)net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Holly Gibons | 2018-09-04 18:13:02 | PostgreSQL: Copy from File missing data error |
| Previous Message | David Steele | 2018-09-04 16:29:48 | Re: Barman versus pgBackRest |