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 по дате отправления: