Re: Sync Rep v19
От | Dimitri Fontaine |
---|---|
Тема | Re: Sync Rep v19 |
Дата | |
Msg-id | m2r5aezrsd.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | Re: Sync Rep v19 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Sync Rep v19
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > was. So you could then say things like "is the most recent time at > which the standby was caught up within the last 30 seconds?", which > would be a useful thing to monitor, and right now there's no way to do Well in my experience with replication, that's not what I want to monitor. If the standby is synchronous, then it's not catching up, it's streaming. If it were not, it would not be a synchronous standby. When a standby is asynchronous then what I want to monitor is its lag. So the CATCHUP state is useful to see that a synchronous standby candidate can not yet be a synchronous standby. When it just lost its synchronous status (and hopefully another standby is now the sync one), then it's just asynchronous and I want to know its lag. > it. There's also a BACKUP state, but I'm not sure it makes sense to > lump that in with the others. Some day it might be possible to stream > WAL and take a backup at the same time, over the same connection. > Maybe that should be a separate column or something. BACKUP is still meaningful if you stream WAL at the same time, because you're certainly *not* applying them while doing the base backup, are you? So you're not yet a standby, that's what BACKUP means. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: