Re: zero data loss recovery is possbile with pgbackrest tool?

From: Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>
To: pgsql-admin(at)lists(dot)postgresql(dot)org
Subject: Re: zero data loss recovery is possbile with pgbackrest tool?
Date: 2019-06-20 10:40:08
Message-ID: 62943f11-43f6-fd4b-6311-92b7fce90670@matrix.gatewaynet.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On 20/6/19 1:12 μ.μ., Jehan-Guillaume (ioguix) de Rorthais wrote:
> On Thu, 20 Jun 2019 08:37:21 +0300
> Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com> wrote:
>
>> On 20/6/19 12:40 π.μ., Pavan Kumar wrote:
>>> Hello Rui,
>>>
>>> yes those are committed transaction.
>>>
>>> I have tested two cases
>>>
>>> 1. complete lost. (means complete data directory, pg_wal direcoty)
>>> 2. lost few directories (deleted few directories , except pg_wal).
>>>
>>> both cases I do see latest data in the current wal is lost.
>>>
>>> when I check the recovery process , wal archives are copying from
>>> pgbackrest repository to pg_wal directory. however pgbackrest tool is not
>>> copying current wal log at all. it is only copying archived wal's/
>>>
>>> is there any way to copy current wal log with pgbackrest tool?
>> No tool that is based on archiving is able to do that. Incomplete wals don't
>> get archived till they are complete. So, you have the risk of losing
>> (maximum) 16MB worth of data.
> No, this could be more than 16MB. Archiving might be lagging as well depending
> on various circumstances and activity.
In this case we have more than one problem.
In such cases pg_wal will be quickly stuffed with unarchived files, this indicates another (usually network or some sudden unforeseen spike in activity) problem.
So yes, in such cases where we have a network or performance problem AND at the same time disaster in the cluster occurs, then it would be much more than 16MB, but then again we are having two
problems now to solve (DB loss + infrastructure).

>
>> If you want to minimize the effect of this, you
>> should set
>> https://www.postgresql.org/docs/11/runtime-config-wal.html#GUC-ARCHIVE-TIMEOUT
>> (|archive_timeout|) to a smaller value .
> This will still allow data loss.
I said minimize.
>
>
> If you don't want a secondary in sync, you might want to have a look at
> pg_receivewal.
>
> ++
>
>

--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message S. Bob 2019-06-20 18:25:48 Re: Vacuum not cleaning up rows.
Previous Message Jehan-Guillaume (ioguix) de Rorthais 2019-06-20 10:12:51 Re: zero data loss recovery is possbile with pgbackrest tool?