List:Cluster« Previous MessageNext Message »
From:Andrew Armstrong Date:April 11 2011 2:11am
Subject:RE: Clustering Technique
View as plain text  
MySQL Cluster is designed for HA; you may want to elaborate on why you think
by using MyISAM at the moment that you can't now use NDB - but your right
it's not suitable for every use case, but it's unclear from your e-mail why
you think its unsuitable to you.

- Andrew

-----Original Message-----
From: Bernhard Ocklin [mailto:bernd.ocklin@stripped] 
Sent: Tuesday, 5 April 2011 4:44 PM
To: Austin G. Smith
Cc: cluster@stripped
Subject: Re: Clustering Technique


to better understand: why do you think your apps are more programmed towards
a MyISAM type of storage? Are you using a lot of complex joins? Did you
never write those with transactions in mind? Are you simply not able to run
several instances of them in parallel on the same distributed datastore? Is
it the amount of data you store? Do you feel the product is complex?

Most of those issues can be easily addressed. Some comments inline.

Am 05.04.2011 um 05:36 schrieb Austin G. Smith:

> Greetings!
> I have been researching different methods of high availability to gain the
most out of MySQL.  I had started putting together a typical cluster based
around NDB technology- however after trying to get our testing started I
realized a lot of the applications we are using are not programmed for the
NDB model- they are primarily MyISAM.  So I started thinking again,
researching again...  Just shy of getting burnt out I turned to this
wonderful mailing list ;)
> The goal I am trying to reach is a loss-less, highly available MySQL
solution.  Due to the application side limitation of NDB model I am would
like to gain feedback on two other tracks:
> 1)      MySQL proxy that writes to two masters.  Then slaves could exist
behind these masters for the normal master/slave replication.  The strongest
point being there will be 2 head-ends that are ALWAYS up to date.  The other
bonus is the ability to split up reads between masters OR slaves..

2 heads being ALWAYS up to date is the charming advantage of NDB cluster.
Btw, we also do master/slave replication. But if you want to write to two
MySQL active masters there are other options: 

- partition your data to avoid conflicts and run a pair of active-active
- XA using InnoDB
- work with proxy like you describe

But whatever you do in active-active: consider the failure & recovery
scenario! What happens if you fail? How do you restore the failing node
without downtime? 

1) Backup remaining master 2) restore failed master 3) apply diff from fail
time to now to failed master from binlogs of the remaining master. 

Sounds complicated? Maybe you want to test semi sync master/slave from 5.5

MySQL Cluster Dev Team

> 2)      The other option I found out there is MySQL MMM.  I have not been
able to discern much information on this project at this time, but this
solutions seems it would put me where I want to be.

> I am sure this has come up for discussion many of times- I have read a
good bit of the posts I could find on the all-mighty Google.  I would still
like to ping the community and gather todays opinions.
> I appreciate any feedback that will be provided ;)
> Thank you,
> Austin Smith, A+, NET+, SMBE, MCSA
> Director of Information Techology
> Digital Compass
> (404) 410-2708 direct
> (404) 410-2701 fax
> 949 W Marietta Street, Suite X104
> Atlanta, GA 30318
> **For immediate assistance please contact our technical team at

MySQL Cluster Mailing List
For list archives:
To unsubscribe:

Clustering TechniqueAustin G. Smith5 Apr
  • Re: Clustering TechniqueBernhard Ocklin5 Apr
    • RE: Clustering TechniqueAndrew Armstrong11 Apr