Re: PostgreSQL in the press again
От | Christopher Browne |
---|---|
Тема | Re: PostgreSQL in the press again |
Дата | |
Msg-id | m34qjynvo4.fsf@knuth.knuth.cbbrowne.com обсуждение исходный текст |
Ответ на | PostgreSQL in the press again (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: PostgreSQL in the press again
(Andrew Sullivan <ajs@crankycanuck.ca>)
Re: PostgreSQL in the press again (Jan Wieck <JanWieck@Yahoo.com>) |
Список | pgsql-advocacy |
Martha Stewart called it a Good Thing when peter_e@gmx.net (Peter Eisentraut) wrote: > Thomas Hallgren wrote: >> Master + read-only slaves: >> - Slony-I when all sites are trusted >> - dbMirror for untrusted slaves and/or table based master slave >> assignment - Mammoth Replicator, proprietary ??? >> - erServer ??? > > That begs the question in turn why there are so many master/slave > replication solutions. I mean, I don't care, but this > categorization doesn't really answer the original question. I think there are multiple answers because of the combination of: a) Coding before thinking, where some of the systems have been "hacked together" without too much forethought; b) Greatly varying implementation strategies. For instance, one of the big problems we encountered with eRServer was in its use of memory. The "snapshot" notion it uses tends to lead to fairly spectacular RAM consumption. Had it gotten more design effort, earlier on, perhaps it could have been more modest in memory usage. That became one of the design requirements for Slony-I... Part of the history has been that people in a rush to get some form of replication working looked at different "parts of the elephant," and, seeing different things, implemented different things. If a system can get a bit more "thoughtfulness" applied to it, it may well become forcibly preferable to the other options. >> Multi-master: >> - C-JDBC, Will be transaction safe once PostgreSQL has XA >> - pgPool, not transaction safe ??? > > These are not multimaster solutions in the sense that you can write > to any one of multiple hosts. In a sense, they are really > master/slave solutions with the program components distributed > differently. To write, you always have to go through one host. The pgpool approach is somewhat ambiguous, but you're probably right. My expectation of a "multimaster" system is that I should be able to fire an update at any of the 'masters' and expect it to propagate to the rest of the databases more or less automatically. That's not what either XA or pgpool do. -- (format nil "~S@~S" "cbbrowne" "acm.org") http://www.ntlug.org/~cbbrowne/linuxdistributions.html Rules of the Evil Overlord #158. "I will exchange the labels on my folder of top-secret plans and my folder of family recipes. Imagine the hero's surprise when he decodes the stolen plans and finds instructions for Grandma's Potato Salad." <http://www.eviloverlord.com/>
В списке pgsql-advocacy по дате отправления: