Replication & recovery_min_apply_delay

Поиск
Список
Период
Сортировка
Искать
От
Konstantin Knizhnik
Тема
Replication & recovery_min_apply_delay
Дата
Msg-id
b271715f-f945-35b0-d1f5-c9de3e56f65e@postgrespro.ru
Список
Дерево обсуждения
Replication & recovery_min_apply_delay Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Re: Replication & recovery_min_apply_delay Alvaro Herrera <alvherre@2ndquadrant.com>
Re: Replication & recovery_min_apply_delay Thomas Munro <thomas.munro@gmail.com>
Re: Replication & recovery_min_apply_delay Michael Paquier <michael@paquier.xyz>
Re: Replication & recovery_min_apply_delay Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Re: Replication & recovery_min_apply_delay Alvaro Herrera <alvherre@2ndquadrant.com>
Re: Replication & recovery_min_apply_delay Michael Paquier <michael@paquier.xyz>
Re: Replication & recovery_min_apply_delay Alvaro Herrera <alvherre@2ndquadrant.com>
Re: Replication & recovery_min_apply_delay Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Re: Replication & recovery_min_apply_delay Alexander Korotkov <a.korotkov@postgrespro.ru>
Re: Replication & recovery_min_apply_delay Michael Paquier <michael@paquier.xyz>
Re: Replication & recovery_min_apply_delay Michael Paquier <michael@paquier.xyz>
Re: Replication & recovery_min_apply_delay Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Re: Replication & recovery_min_apply_delay Michael Paquier <michael@paquier.xyz>
Re: Replication & recovery_min_apply_delay Asim R P <apraveen@pivotal.io>
Re: Replication & recovery_min_apply_delay Asim Rama Praveen <apraveen@pivotal.io>
Re: Replication & recovery_min_apply_delay Asim R P <apraveen@pivotal.io>
Re: Replication & recovery_min_apply_delay Asim R P <apraveen@pivotal.io>
Re: Replication & recovery_min_apply_delay Daniel Gustafsson <daniel@yesql.se>
Re: Replication & recovery_min_apply_delay Mahendra Singh Thalor <mahi6run@gmail.com>
Re: Replication & recovery_min_apply_delay Daniel Gustafsson <daniel@yesql.se>
Re: Replication & recovery_min_apply_delay Dilip Kumar <dilipbalaut@gmail.com>
Re: Replication & recovery_min_apply_delay Dilip Kumar <dilipbalaut@gmail.com>
Re: Replication & recovery_min_apply_delay Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Replication & recovery_min_apply_delay Dilip Kumar <dilipbalaut@gmail.com>
Re: Replication & recovery_min_apply_delay Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Replication & recovery_min_apply_delay Mahendra Singh Thalor <mahi6run@gmail.com>
Hi hackers,

One of our customers was faced with the following problem:
he has setup  physical primary-slave replication but for some reasons 
specified very large (~12 hours)
recovery_min_apply_delay. I do not know precise reasons for such large 
gap between master and replica.
But everything works normally until replica is restarted. Then it starts 
to apply WAL, comes to the point where record timestamp is less then 12 
hours older
and ... suspends recovery. No WAL receiver is launched and so nobody is 
fetching changes from master.
It may cause master's WAL space overflow (if there is replication slot) 
and loose of data in case of master crash.

Looks like the right behavior is to be able launch WAL receiver before 
replica reaches end of WAL.
For example, we can launch it before going to sleep in recoveryApplyDelay.
We need to specify start LSN for WAL sender. I didn't find better 
solution except iterating WAL until I reach the last valid record.

I attach small patch which implements this approach.
I wonder if it can be considered as acceptable solution of the problem 
or there can be some better approach?

-- 
Konstantin Knizhnik
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company

В списке pgsql-hackers по дате отправления
От: Peter Eisentraut
Дата:
От: Hubert Zhang
Дата:
FAQ