Re: AW: AW: AW: AW: Replication Testing- How to introduce a Lag

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: AW: AW: AW: AW: Replication Testing- How to introduce a Lag
Дата
Msg-id 89d63402747edb3bf80ff668fdd63cc77334f446.camel@cybertec.at
обсуждение исходный текст
Ответ на AW: AW: AW: AW: Replication Testing- How to introduce a Lag  ("Subramanian,Ramachandran" <ramachandran.subramanian@alte-leipziger.de>)
Ответы AW: AW: AW: AW: AW: Replication Testing- How to introduce a Lag
Список pgsql-novice
On Mon, 2026-03-23 at 16:36 +0000, Subramanian,Ramachandran wrote:
> I noticed that  RBAs are not incremented one for one . i.e  1 row inserted does not mean RBA=RBA+1 . 1 row updated 
doesnot mean RBA=RBA+1  
>
> I have ALTER SYSTEM SET recovery_min_apply_delay=300000 ; ( on the stand by side )
>
> On the Source side
> A simple create table results in a RBA difference of 108328
>
> A simple insert of 1 row results in a RBA difference of 296   sometimes 96
>
> Is there a way to estimate roughly the amount of data that remains to be transfered ? 

I don't know what an RBA is...

If you are using recovery_min_apply_delay, don't measure the replication lag
with regard to the replay_lsn, because replay is deliberately delayed.
Instead, measure the difference to flush_lsn, the WAL position successfully
transferred to the standby and persisted there.

Yours,
Laurenz Albe



В списке pgsql-novice по дате отправления: