OpenLDAP includes a driver that allows it to store and access data held in MySQL Cluster. It uses the NDB-API to access the database and so the performance is extremely good. One of the great things about the solution is that it lets you simultaneously access the same data through both LDAP and SQL (or the NDB-API or any of the MySQL connectors). This article gives an example of how this can be done.

Someone asked me what applications were good/bad for MySQL Cluster. As I've now actually had experience with a Cluster setup and a real-life application of it, and dug through the manual, I present a few characteristics of applications that will work with Cluster, and why they are so (so that if you have an application that meets some of the characteristics but not all of them, you can decide whether it's worth it to use Cluster or not).Firstly, I'll state this -- there's actually a very limited application to MySQL cluster. I haven't assessed the disk-based cluster, only the memory-based one, so I don't know what really changes with disk-based. But after you see this list, you certainly will want to re-think your use of disk-based cluster if a lot of the inner workings don't change.The factors are listed below, but the "ruler" I keep in my mind is the fact that MySQL Cluster was developed for telecom applications.  []

If you have a 12-server MySQL Cluster with:1 Management Node3 SQL Nodes2 Data Node Groups, 4 Data Nodes per groupAnd each machine is configured to allocate 1G of memory for its function, how much data (data + indexes) can you store in total in your cluster?You can guess, but you get bonus points if you explain why and the explanation is correct.

Creating a MySQL-plugin that can be used to create a function which can in turn be used in stored procedures.

Very insightful article about how MySQL Cluster achieves fault tolerance and high availability.

Mikael Ronstrom, father of MySQL Cluster, explains the architecture of NDB (MySQL Cluster).

Stewart Smith, MySQL Cluster support at that time, introduces NDB (MySQL Cluster).

In this talk, the developers behind MySQL Replication walk through some of the new Replication features of MySQL 5.1 and MySQL 6.0, such as: Row-based Replication (5.1) is used for MySQL Cluster replication and also provides a safer way to replicate non-deterministic statements. Row-based support for mysqlbinlog client (5.1) is used to analyze the row-based binlog entries. Row-based point-in-time recovery (5.1) is used to restore a server to a particular time point regardless of binlogging format. Heartbeating (6.0) is used to manage that the master and slave connection is always up. Semi-synchronous Replication (6.0) is used to ensure that any update of the master is on the slave before transaction is acknowleged to the user. Replication Server Filtering (6.0) ensures that the user can more easily replicate in a circle. Relay log synchronization (6.0) ensures that the slave is restartable without clearing the relay log in case of crashes.

There are various setups and solutions to solve the problem of having redundant mysql masters and scaling writes on them. MySQL Cluster can be an alternative. MySQL Cluster can effectively do what DRBD and MySQL Replication do in a HA MySQL setup. But better.

This post builds upon the earlier article (Creating a simple Cluster on a single LINUX host) which explained how to install and run a Cluster where all of the nodes run on the same physical host. The single host solution is not great for a real deployment - MySQL Cluster is designed to provide a High Availability (HA) solution by synchronously replicating data between data nodes - if all of the data nodes run on a single host that that machine is a single point of failure. This article demonstrates how to split the nodes between hosts; the configuration will still be fairly simple, using just 2 machines but it should be obvious how to extend it to more.

In this talk, the developers behind MySQL Replication walk through some of the new Replication features of MySQL 5.1 and MySQL 6.0, such as: Row-based Replication (5.1) is used for MySQL Cluster replication and also provides a safer way to replicate non-deterministic statements. Row-based support for mysqlbinlog client (5.1) is used to analyze the row-based binlog entries. Row-based point-in-time recovery (5.1) is used to restore a server to a particular time point regardless of binlogging format. Heartbeating (6.0) is used to manage that the master and slave connection is always up. Semi-synchronous Replication (6.0) is used to ensure that any update of the master is on the slave before transaction is acknowleged to the user. Replication Server Filtering (6.0) ensures that the user can more easily replicate in a circle. Relay log synchronization (6.0) ensures that the slave is restartable without clearing the relay log in case of crashes.