From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Atul Kumar <akumar14871(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: confusion between max_standby_archive_delay, max_standby_archive_delay and max_standby_archive_delay |
Date: | 2023-03-12 14:01:44 |
Message-ID: | 065aeb58c2593e4087b42556de0a4af2a9ab2819.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, 2023-03-12 at 01:53 +0530, Atul Kumar wrote:
> Could someone help me in telling the difference between these three parameters
> 1. max_standby_archive_delay
> 2. max_standby_streaming_delay
> 3. recovery_min_apply_delay
>
> My basic motive is to make the standby database server to be delayed to apply the
> changes on itself, if any data has been accidentally deleted/updated/ truncated
> from the primary server.
>
> Which parameter do I need to configure to serve this purpose ? And
> When will the remaining two parameters be used ?
>
> It would be great if anyone can explain them with a brief example.
The parameter that does what you describe you want is "recovery_min_apply_delay".
The other parameters only deal with delaying replication in the face of a
replication conflict.
Note that changes are immediately shipped to the standby, what is delayed with
"recovery_min_apply_delay" is only the replay of the WAL information.
So you can recover from a logical problem like DROP TABLE by stopping the
standby, setting "recovery_target_time" to a time before the problem happened
and then restarting the standby. Then recovery will stop before the problem
is replayed.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Zheng Li | 2023-03-12 15:24:13 | Re: Support logical replication of DDLs |
Previous Message | Martijn de Munnik | 2023-03-12 08:49:45 | Re: ERROR: only immutable functions supported in continuous aggregate view |