Christopher Browne wrote:
> > 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.
The ones mentioned above certainly keep the database running at all
times until a failover.
> 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.
The slave database doesn't run at all while the master is alive.
> 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...
If you can set up a true database-level replication system that does
something useful with the slave server while the master is running
(i.e., load balancing) for the same price (hardware + labor +
post-installation service) that you (or I or someone) can set up a disk
replication system for then it would be interesting. So far I haven't
seen it happening. In my experience, load balancing is not needed in
most cases, so no one is going to bother paying for the extra
functionality that they don't need.
The other advantage of disk replication is that you can secure almost
any service in that same way (web, dns, ldap, etc.), so the management
and setup effort spent on any particular service diminishes.