MySQL Lists are EOL. Please join:

List:Cluster« Previous MessageNext Message »
From:Martino Piccinato Date:July 15 2005 8:55am
Subject:Re: evaluation of mysql cluster (comparison with oracle rac cluster)
View as plain text  
Chad Martin wrote:

>Martino Piccinato wrote:
>  
>
>>4) Storage space scalability. Full replication on a "shared nothing"
>>cluster has a shortcoming in available storage space as every new node
>>added must have at least as much space as the other nodes. This might
>>not be a problem for a x*10GB database but can become very expensive for
>>a x*100GB (many disk for every node) and really difficult for a TB
>>database: Whether you add shared storage or raid disks you have to fully
>>duplicate the entire DB storage for every single server.
>>    
>>
>
>I don't understand this.  What do you mean by "full replication"?  You
>seem to imply that everytime you add a node to a MySQL Cluster, you bump
>up the number of replicas by one.  That's not how you do things, since
>that totally kills the scalability of it.  You set your number of
>replicas at 2 or 3 and add nodes as your storage/performance demands
>dictate.  Your last sentence above is totally false.  Read up on Cluster
>a little more.
>
>  
>

you are right about that, I initially got mysql cluster storage working 
totally wrong.


>>>- Third, due to the fact of having a physical data partition to node
>>>relationship, shared nothing systems are not flexible at all to adapt to
>>>changing business requirements. When the business grows, you cannot
>>>easily enlarge your system incrementally to address your growing
>>>business needs. You can upgrade all existing nodes, keeping them
>>>symmetrical and
>>>avoiding data repartitioning. In most cases upgrading all nodes is too
>>>expensive; you have to add new nodes and to reorganize - to physically
>>>repartition - the existing database. Having no need for reorganization is
>>>always better than the most sophisticated reorganization facility.
>>>      
>>>
>
>This is true as long as you're more concerned with time lost due to data
>repartitioning as opposed to time lost due to hardware failure downtime.
> It kinda depends on your priorities.
>
>  
>
mmm well yes and no... data repartitioning is something that will happen 
for sure if your business grow. Shared storage hardware failure might 
not happen (depending on your hardware configuration) at all (I mean 
"have a much lower probability to happen").

Does anybody know how time/CPU consuming is repartitioning datas on a 
mysql cluster? can it be done without interrupting the service?



>>>- Finally, shared nothing systems, due to their use of a rigid
>>>restricted access
>>>scheme, fail to fully exploit the potential for high fault-tolerance
>>>available
>>>in clustered systems.
>>>      
>>>
>
>What?  Are they claiming that have a single point of failure is more
>fault-tolerant?
>
>  
>

I agree on that.



Thread
evaluation of mysql cluster (comparison with oracle rac cluster)Martino Piccinato11 Jul
  • Re: evaluation of mysql cluster (comparison with oracle rac cluster)Chad Martin13 Jul
    • Re: evaluation of mysql cluster (comparison with oracle rac cluster)Martino Piccinato15 Jul