List:Cluster« Previous MessageNext Message »
From:Luke H. Crouch Date:August 30 2004 2:09pm
Subject:RE: Multiple Management Nodes?
View as plain text  
> He has 4 MySQL-servers, of which 1 is master and 3 slaves. 
> They all have 4GB of RAM, and they're 
> swapping between 1MB and 6MB on his slaves, and on the master 41MB.
> So we should use more then 4GB of RAM per server you guess? 
> Hope not...

With 4 machines, each with 4GB of RAM, you'll have 16GB of RAM total available. But, since
you'll have the database replicated, you'll actually only be able to hold about a 7.5GB
database, since when it is replicated, it will consume 15GB. You can set the parameters
for memory usage in your cluster config file...DataMemory is memory allocated to the
actual data, and IndexMemory is the memory allocated to indexes.

In any case, it depends on how large your database is. It's probably un-reasonable to try
to get a terabyte database into a cluster in its current state.

> True, but than I run in the situation that if master1 goes 
> down, master2 should be used to 
> write. And if master1 then comes back-up, they would be very 
> out of sync, wouldn't they? 
> That's why I'd like to use MySQL Cluster, cause if I'm 
> understanding it right, 
> this problem would not occur with it. Is that correct? :) The 
> client want's the 
> 99.999xx% uptime guarantee, and I'd like to sleep at night 
> and not restoring replication issues :)

the short-comings of replication as you describe them are exactly correct, and the main
reason you'd want to use a cluster rather than typical replication. there are more big
administrative challenges to the typical replication setup, but there are more technical
and budget restrictions with the cluster setup. to borrow from make your
decisions accordingly. =)

Multiple Management Nodes?Wouter de Jong27 Aug
  • Re: Multiple Management Nodes?Mikael Ronström7 Sep
RE: Multiple Management Nodes?Luke H. Crouch27 Aug
  • Re: Multiple Management Nodes?Wouter de Jong30 Aug
RE: Multiple Management Nodes?Luke H. Crouch30 Aug