From: | Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Barman disaster recovery solution |
Date: | 2019-02-27 14:48:37 |
Message-ID: | 13f3644c-adef-9fcc-09c9-cd14dce60656@matrix.gatewaynet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 27/2/19 4:16 μ.μ., David Steele wrote:
> On 2/27/19 2:31 PM, Achilleas Mantzios wrote:
>> On 27/2/19 1:58 μ.μ., richter(at)simkorp(dot)com(dot)br wrote:
>>> Just to notice, I d o use backup from standby and WAL archive from standby. It is possible. But you have to configure standby with option of wal archive "always".
>>
>> I guess there are issues with it. If this was so easy then pgbarman and pgbackrest would support it out of the box.
>
> There are a few issues with it:
>
> 1) If you allow the primary and standby to archive to the same repository then there needs to be some conflict resolution if they write at the same time. If they write to different repositories
> then you need to decided which one to use for a restore, or have some kind of conflict resolution between them. It gets complicated.
>
> 2) Writing only from the standby reduces load on the primary but if the connection to the primary is down then you can get behind on archiving. If something then happens to the primary then your
> recovery point will be limited.
David to quote an older email from you:
"pgBackRest currently requires some files and all WAL to be sent from the primary even when doing backup from standby. We may improve this in the future but it's not on the road map right now. "
So, I had the impression that receiving WALs from the standby was a greater technical problem.
>
> Regards,
--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Finzel | 2019-02-27 14:55:55 | idle_in_transaction_session_timeout for a set of SQL statements |
Previous Message | github kran | 2019-02-27 14:43:14 | cannot execute VACUUM during recovery |