A long time ago, in a galaxy far, far away, peter_e@gmx.net (Peter Eisentraut) wrote:
> Bradley Kieser wrote:
>> I desperately need to set up a real time replication of several
>> databases (for failover) between two servers. Last time I looked at
>> the PG replication it wasn't yet production level. I wonder if
>> anyone on this list is doing this successfully and if you won't
>> mind sharing your experience and giving me any tips that you may
>> think would be handy from a real world perspective I would very
>> much appreciate it.
>
> To ensure high availability, using DRBD to replicate the storage or
> using a shared storage (e.g., EMC^2) does the job. That saves you
> the trouble of having to set up and manage a database replication
> solution at all.
Regrettably, "disk replication" schemes aren't generally able to cope
with keeping the database up and alive while replication is taking
place.
You need to shut down the database that is attached to a
"target/slave" system every time you "sync" the target/slave against
the source/master.
If the _sole_ goal is failover, then that will be defined to be
"fine."
But when the people paying for the duplicate set of hardware realize
that it's sitting there "otherwise useless" at any time that there
hasn't been a failure, they'll presumably agitate for some 'better'
sort of replication...
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://cbbrowne.com/info/lisp.html
"Computers double in speed every 18 months or so, so any "exponential
time" problem can be solved in linear time by waiting the requisite
number of months for the problem to become solvable in one month and
then starting the computation." -- pratt@Sunburn.Stanford.EDU
