Re: Standby node using replication slot not visible in pg_stat_replication while catching up
От | Andres Freund |
---|---|
Тема | Re: Standby node using replication slot not visible in pg_stat_replication while catching up |
Дата | |
Msg-id | 20140310122413.GA27167@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Standby node using replication slot not visible in pg_stat_replication while catching up (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Standby node using replication slot not visible in
pg_stat_replication while catching up
|
Список | pgsql-hackers |
Hi, On 2014-03-10 21:06:53 +0900, Michael Paquier wrote: > I have been playing a bit with the replication slots, and I noticed a > weird behavior in such a scenario: > 1) Create a master/slave cluster, and have slave use a replication slot > 2) Stop the master > 3) Create a certain amount of WAL, during my tests I played with 4~5GB of WAL > 4) Restart the slave, it catches up with the WALs that master has > retained in pg_xlog. > I noticed that while the standby using the replication slot catches > up, it is not visible in pg_stat_replication on master. This makes > monitoring of the replication lag difficult to follow, particularly in > the case where the standby disconnects from the master. Once the > standby has caught up, it reappears once again in pg_stat_replication. > I didn't have a look at the code to see what is happening, but is this > behavior expected? Does the use of replication slots actually alter the behaviour? I don't see how the slot code could influence things to that degree here. Could it be that it's just restoring code from the standby's pg_xlog or using restore_command? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: