|
On Fri, 4 Aug 2000, Michael Taylor wrote:
> If you think MySQL is going to be easier to cluster, please enlighten me.
> I'd like some sort of a rough blueprint for clustering MySQL myself. I am
> looking to cluster it for a OLTP-style database.
The clustering of databases should be about the same. Mysql is easier to
administer than the rest, but the clustering is just a matter of putting
an entry into ipvs with ipvsadm.
That said, clustering of databases requires some thought
here's an excerpt from the long gestating next version of the HOWTO
Joe
--------------------
6.6.2.6 Databases
Normal databaseds (eg mysqld, ie anything else but
Oracle's parallel database server for several 100k$)
running under LVS suffer the same restrictions of single
writer/many readers as does any other service where user
can write to files on the real-server (eg smtp).
Databases running independantly on several real-servers
have to be kept synchronised for content, just as do
webservers. If the database files are read-only as far
as the LVS users are concerned, and the LVS administrator
can update each copy of the database on the real-servers
at regular intervals (eg a script running at
3am) then you can run a copy of the databased on each
real-server, reading the files which you are
keeping synchronised.
Online transaction processing requires that LVS users
be able to write to the database.
If you try to do this by setting up an LVS where each real-server
has a databased and its own database files, then writes
from a particular user will go to only one of the real-servers.
The database files on the other real-servers will not
be updated and subsequent LVS users will be presented
with inconsistent copies of the database files.
The Linux Scalable Database project
http://lsdproject.sourceforge.net/ is working on code to
serialise client writes so that they can be written to all
real-servers by an intermediate agent. Their code is experimental
at the moment, but is a good prospect in the long term for
setting up multiple databased and file systems on separate
real-servers.
The next approach, of having databaseds on each real-server
accessing a common filesystem on a back-end server, fails.
Tests with mysqld running on each of two real-servers working off
the same database files mounted from a backend machine, showed that
reads were OK, but writes from any real-server either weren't seen
by the other mysqld or corrupted the database files. Presumably
each mysqld thinks it owns the database files and keeps copies
of locks and pointers. If another mysqld is updating the filesystem
at the same time then these first set of locks and pointers are invalid.
In an early attempt to setup this sort of LVS
jake buchholz <jake@xxxxxxxxxx> setup an LVS'ed mysql
database with a webinterface. LVS was to serve http
and each real-server to connect to the mysqld running
on itself. Jake wanted the mysql service to be lvs'ed as
well and for each real-server to be a mysql client. The solution
was to have 2 VIPs on the director, one for http and the other
for mysqld. Each http real-server makes a mysql request to the
myqslVIP. In this case no real-server is allowed to have both
a mysqld and an httpd. A single copy of the database is nfs'ed from a
fileserver. This works for reads.
Production LVS databases, eg the service implemented by
Ryan Hulsker <RHulsker@xxxxxxxxxxxxxxxxxxxxxxx> (sample load
data at http://www.secretshopnet.com/mrtg/) have the LVS users
connect to database clients (perl scripts running under a webpage)
on each real-server. These database clients connect to a
single databased running on a backend machine that the client
can't access. You don't scale the database with LVS this way,
but the user connects to the database client on the real-server
which handles the intermediate dataprocessing, increasing your throughput.
--
Joseph Mack mack@xxxxxxxxxxx
|
