Hanni Ali wrote: >> I've looked at implementing a mysql-cluster in great detail and let it >> go because it's mostly meant for a setup with a fixed database-size. >> If you experience (large) growth in your database volume clustering is >> not very suitable (we're in that situation) > > I'd agree, database clustering has to be planned although replication > is fairly straight forward to allow a significant increase in read > access. You may want to consider partitioning databases though to > allow multi-master scalability. i.e. one partition for search another > for user data another for content or media etc. The main problem with clustering in mysql atm is that they limit the amount of nodes in the cluster (64 max iirc) With a max datasize per clusternode and redundancy requirements you end up with a maximum size of your database. Can't grow beyond that. > > I did a nice graphic here for simple MySQL database replication. > > http://ainkaboot.co.uk/dev/cluster-architecture.php#database-replication > Looks nice ;-) We run serveral partitioned databases and also off-load the replication of the master to a second tier of replication machines in some cases. This helps the master in coping with traffic while keeping the replication fast towards the read-slaves as well.
Grtz Ramon -- [email protected] mailing list
