Re: Replication: slave is in permanent startup 'recovery'

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: Replication: slave is in permanent startup 'recovery'
Дата
Msg-id 4DA7405C.8050103@fuzzy.cz
обсуждение исходный текст
Ответ на Re: Replication: slave is in permanent startup 'recovery'  (Craig Ringer <craig@postnewspapers.com.au>)
Список pgsql-general
Dne 14.4.2011 10:01, Craig Ringer napsal(a):
> That's a limitation of streaming replication. It's a lot like the issue
> Oracle has with running out of undo or redo log space. Essentially, my
> understanding is that the hot standby server cannot replay WAL archives
> to keep up with the master's changes at the same time as running
> queries. To avoid getting too far behind the master because of a huge or
> stuck query, it'll cancel very long-running queries.
>
> Again from my limited understanding, the reason it can't replay WAL is
> because the WAL records include overwrites of pages VACUUMed and re-used
> on the master. HS is block-level replication; it cannot keep a page
> in-place on the slave when the master has erased or overwritten it.

I guess it's worth mentioning there's another solution to this problem,
implemented in 9.1 - it's called feedback. That means the standby asks
the primary not to overwrite the blocks - see this

http://developer.postgresql.org/pgdocs/postgres/hot-standby.html#HOT-STANDBY-CONFLICT

But obviously this is not for free - you have to pay a price, in this
case a bloat on the primary (as it can't do VACUUM properly).

regards
Tomas

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

Предыдущее
От: David Kerr
Дата:
Сообщение: Calculating memory allocaiton per process
Следующее
От: Andrew Sullivan
Дата:
Сообщение: Re: SSDs with Postgresql?