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