[KLUG Members] Server Mirroring

[Adam Tauno WIlliams]

> > > My final goal is to have a fault tolerant solution with a
> > > database. Have the database mirrored to two server. Use
> > > HeartBeat to fail over the actual database server application
> > > if one fails.
> > If by "database" you mean an RDBMS (SQL database engine):
> I think he does :)
> > > Anyone know if any such mirroring software?
> > No. ***Reliably*** and ***consistently*** replicating an RDBMS
> > is really really really really really H-A-R-D.  If you
> > absolutely need this as a hot-pair.... buy DB2.
> MySQL does this.  Clusters have been powering most of LiveJournal's
> writer DBs for months now.  Clustering has been available through
> third-parties for a while, but don't bother with that, since it's
> part of the core software now, in MySQL 4.1:
> http://dev.mysql.com/doc/mysql/en/NDBCluster.html
> Adam's right that it's hard to set up.  

I don't mean it is hard to setup, I mean it is hard to DO.

I'm going upon the information below (which limits its usefulness), but
NDB seems to be something else altogether and very similiar to what DB2
does.  Would make a fabulous topic for a presentation!

NDB:
http://dev.mysql.com/doc/mysql/en/MySQL_Cluster_Overview.html
A MySQL Cluster consists of computers with a set of processes executing
several MySQL servers, storage nodes for NDB Cluster, management servers
and possibly also specialized data access programs. All these programs
work together to form MySQL Cluster. When data is stored in the NDB
Cluster storage engine, the tables are stored in the storage nodes for
NDB Cluster. Those tables are directly accessible also from all other
MySQL servers in the cluster. Thus, if one application updates the
salary of an employee, all other MySQL servers that query this data can
see it immediately.
The data stored in the storage nodes for MySQL Cluster can be mirrored
and can handle failures of storage nodes with no impact other than that
a number of transactions are aborted due to losing the transaction
state. This should cause no problems bcause transactional applications
should be written to handle transaction failure. (COOL!)

vs.

Replication:
http://dev.mysql.com/doc/mysql/en/Replication_FAQ.html
Q: What issues should I be aware of when setting up two-way replication?
A: MySQL replication currently does not support any locking protocol
between master and slave to guarantee the atomicity of a distributed
(cross-server) update. In other words, it is possible for client A to
make an update to co-master 1, and in the meantime, before it propagates
to co-master 2, client B could make an update to co-master 2 that will
make the update of client A work differently than it did on co-master 1.
Thus, when the update of client A makes it to co-master 2, it will
produce tables that are different than what you have on co-master 1,
even after all the updates from co-master 2 have also propagated. This
means that you should not co-chain two servers in a two-way replication
relationship unless you are sure that your updates can safely happen in
any order, or unless you take care of mis-ordered updates somehow in the
client code.  (YIKES!)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.kalamazoolinux.org/pipermail/members/attachments/20041019/1df23b77/attachment.bin