Posted on 4 Comments

Classroom Cluster

Last week I was teaching one of the MySQL training courses, this time in Melbourne. Even with experienced users it’s important to go over the basics, as there’s always some aspects that they haven’t come across in their work. Filling in those gaps is essential before you can focus on design, optimization and scaling.

Anyway, since all my students did indeed have SQL experience, we were able to run through some of the materials at higher speed and so on Tuesday afternoon we actually had quite a bit of spare time. So we set up a MySQL Cluster using six of the student PCs in the classroom as data nodes, a configuration with two replicas. We loaded up the data from Jeremy Cole’s FlightStats demo app which provides a decent (and growing) dataset to play with.

All MySQL servers (and of course each student had one running anyway) could connect to the cluster and run queries. It’s fun to just rip the power out of a few data node PCs and see the overall system not even flinch… you just happily continue doing your queries.

Posted on 4 Comments

4 thoughts on “Classroom Cluster

  1. you could show a real demo – ripping the power of two storage nodes, that store same data 😉 it would be a nice lesson learned – though, there’s a magic behind, data crashes might still happen.

  2. A decent setup of cluster should not have a single point of failure, of course. The system does rely on the fact that there will always been at least one copy of each segment running.

    If more goes down, obviously the cluster is down. No big deal, you just start the nodes again and off you go. That is, from the last global checkpoint that was logged.

  3. I’m curious as to how you avoid delays in clients getting their responses. Do the clients each have a list of all accessible servers? If one fails during a query, how do they know to connect to the next one? Is it based on some kind of response timeout or keepalive? If one is already failed, how do clients know not to connect to it?

    Benjamin.
    http://members.optusnet.com.au/benjamincarlyle/benjamin/blog

  4. There are a couple of aspects to this.

    First of all, the storage nodes in the cluster are separate from the MySQL Servers. One or more MySQL Servers connect to the same storage node cluster (and use it for any tables with the NDBCLUSTER storage engine type).

    Each MySQL Server actually connects to *all* data storage nodes in the cluster, the cluster-internal load balancing magic takes care of the rest. So if any nodes drop out, no new connections need to be set up as the MySQL Server still has others to talk to.

    Then, apps can connect to one of more MySQL Servers, same as usual. If you use Connector/J (JDBC) then you can specify multiple servers and there’s an automatic failover in the JDBC driver. With other app languages you use whatever is done there, or may need to do such trickery yourself. It’s pretty easy to handle.

Comments are closed.