Re: Synch Rep for CommitFest 2009-07

Поиск
Список
Период
Сортировка
От Rick Gigger
Тема Re: Synch Rep for CommitFest 2009-07
Дата
Msg-id DA346E39-AE5A-4DB3-A3AA-60566DE1978C@alpinenetworking.com
обсуждение исходный текст
Ответ на Re: Synch Rep for CommitFest 2009-07  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Synch Rep for CommitFest 2009-07  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
On Jul 16, 2009, at 12:07 AM, Heikki Linnakangas wrote:

> Dimitri Fontaine wrote:
>> Le 15 juil. 09 à 23:03, Heikki Linnakangas a écrit :
>> Furthermore, the counter-argument against having the primary
>> able to send data from the archives to some standby is that it should
>> still work when primary's dead, but as this is only done in the setup
>> phase, I don't see that being able to continue preparing a not-yet-
>> ready
>> standby against a dead primary is buying us anything.
>
> The situation arises also when the standby falls badly behind. A
> simple
> solution to that is to add a switch in the master to specify "always
> keep X MB of WAL in pg_xlog". The standby will then still find it in
> pg_xlog, making it harder for a standby to fall so much behind that it
> can't find the WAL it needs in the primary anymore. Tom suggested that
> we can just give up and re-sync with a new base backup, but that
> really
> requires built-in base backup capability, and is only practical for
> small databases.

If you use an rsync like algorithm for doing the base backups wouldn't
that increase the size of the database for which it would still be
practical to just re-sync?  Couldn't you in fact sync a very large
database if the amount of actual change in the files was a small
percentage of the total size?

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

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: [PATCH] DefaultACLs
Следующее
От: Grzegorz Jaskiewicz
Дата:
Сообщение: Re: boolean in C