jlar310@gmail.com ("Jeff Larsen") writes:
>> Alvaro Herrera wrote:
>> > Glyn Astill wrote:
>> >> Thanks everyone for your replies. EnterpriseDB looks like the way to
>> >> go if we want good replication.
>> >
>> > Sorry, this makes no sense to me -- EnterpriseDB has no replication
>> > solution that I know of.
>>
>> Yeah, there is:
>>
>> http://www.enterprisedb.com/products/enterprisedb_replication.do
>
> Yes, but I'd like something better than "near real time" as the above
> page describes. Or maybe someone could clarify that.... Besides,
> EnterpriseDB does not save me enough money. In my current commercial
> DB, if a transaction is committed on the master, it is guaranteed to
> be committed to the secondary. In our business, losing one customer
> order could lose us the customer for good.
I believe that what they are using is a version of Slony-I, which
certainly falls into the "near real time" replication category.
Historically, when people think they require "something better than
near-real-time," they frequently find that the "something better"
turns out to be too expensive to live with.
"Near real time" usually refers to the notion of asynchronous
replication, where it is a little bit nondeterministic how far behind
a replica may be. (Which is definitely the case for Slony-I.)
Unfortunately, the only way to make things deterministic (or to get
from "near real time" to "*GUARANTEED* real time") is to jump to
synchronous replication, which is not much different from 2PC (Two
Phase Commit), and which is certain to be prohibitively expensive
across a WAN.
At this point, I tend to get visions of Tom Cruise telling Jack
Nicholson, "I want real time replication!", and getting the response:
"You can't HANDLE real time replication!"
--
(format nil "~S@~S" "cbbrowne" "linuxfinances.info")
http://cbbrowne.com/info/slony.html
"Any sufficiently complicated C or Fortran program contains an ad hoc
informally-specified bug-ridden slow implementation of half of Common
Lisp." -- Philip Greenspun
