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