Re: PostgreSQL in the press again - Mailing list pgsql-advocacy
From | Christopher Browne |
---|---|
Subject | Re: PostgreSQL in the press again |
Date | |
Msg-id | m34qjynvo4.fsf@knuth.knuth.cbbrowne.com Whole thread Raw |
In response to | PostgreSQL in the press again (Simon Riggs <simon@2ndquadrant.com>) |
Responses |
Re: PostgreSQL in the press again
Re: PostgreSQL in the press again |
List | 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 by date: