Re: Simultaneously streaming database replication and pg_dump, yet observing zero lag
От | Scott Ribe |
---|---|
Тема | Re: Simultaneously streaming database replication and pg_dump, yet observing zero lag |
Дата | |
Msg-id | EE1482C5-35B8-487B-89A2-9157C5B8ABB5@elevated-dev.com обсуждение исходный текст |
Ответ на | Simultaneously streaming database replication and pg_dump, yet observing zero lag (Matt Patey <matt.patey@ableton.com>) |
Ответы |
Re: Simultaneously streaming database replication and
pg_dump, yet observing zero lag
Re: Simultaneously streaming database replication and pg_dump, yet observing zero lag |
Список | pgsql-admin |
On Apr 30, 2015, at 8:00 AM, Matt Patey <matt.patey@ableton.com> wrote: > > We have a streaming replication setup, where the replication slave runs pg_dump every hour. Our lag monitor shows an expectedsawtooth shape, where pg_dump runs coincide with a climbing lag, which ends abruptly when pg_dump is finished. Thisis, to the best of my knowledge, expected behaviour. The lag pattern occasionally disappears though, and when lookingat system processes we see that the database is recovering WAL data, and pg_dump is also running. How is this evenpossible? Any query (and pg_dump is a series of queries) does not necessarily block recovery. AFAIK, it’s only when the query requiresa version of a row which would be removed by WAL replay that the recovery gets blocked. So it’s possible for pg_dumpto not block recovery, but in any reasonably active db I think it’s unlikely—exactly what you’re seeing. -- Scott Ribe scott_ribe@elevated-dev.com http://www.elevated-dev.com/ https://www.linkedin.com/in/scottribe/ (303) 722-0567 voice
В списке pgsql-admin по дате отправления: