In MySQL 5.1 the NDB storage engine was removed. Development continued in a fork of MySQL called MySQL Cluster. The latest version of this is MySQL Cluster 7.2.6, which is based on MySQL 5.5.22.

This meant that in Squeeze it was only possible to install MySQL Cluster with NDB from the source code, which generally caused problems by conflicting with the other mysql packages.

A .deb package is now available with the latest version of MySQL Cluster, but this installs to /opt and therefore doesn't meet the various debian standards policies.

Overview of MySQL Cluster

Cluster is more than just a plugin for cluster. It requires other server components, and has modifications to the server code to add additional hooks to support the NDB plugin.

The NDB storage engine stores data spread across a cluster. This allows it to massively scale both reads and writes beyond what any one server would be capable of. There are 3 types of node that form the cluster:

At least one of each is required for a functioning cluster, but at least 2 of each is required to ensure the cluster remains available if any node fails (High Availability).

In addition there is an API which can connect directly to the cluster which allows software to control the cluster and to access the data without requiring an SQL node (libndbclient6).

There are also Cluster-specific client programs to control the cluster (eg ndb_mgm).

Proposed packages

Overlap with mysql-5.5

There is overlap with mysql-5.5. Because there are versioned dependancies on packages such as libmysqlclient18 it isn't possible to create a cluster package providing libmysqlclient18 as a virtual package, and a similar issue with mysql-client.

Luckily libmysqlclient18 in MySQL 5.5 is ABI compatible with the one in MySQL Cluster 7.2, therefore we can simply omit the libmysqlclient18 from the cluster packages and instead depend on the one from mysql-5.5.

Similarly with mysql-client the protocol is identical and therefore the mysql-5.5 version can be used.

mysql-common is another potential source of conflict. It provides /etc/mysql/my.cnf but there are additional NDB-specific options where it would be useful to distribute an example configuration. Other packages depend on specific versions of it cannot be replaced by a virtual package. However since 7.2 is based on 5.5 all non-NDB options are identical, therefore we can use the my.cnf from 5.5's mysql-common fine. We can instead provide the NDB-specific options in a mysql-cluster-common package in the file /etc/mysql/conf.d/my-cluster.cnf which will be included by my.cnf.

mysql-cluster packages

Common packages

Client packages

MySQL client programs are not packages (eg mysql), instead it depends on mysql-client from mysql-5.5.

Management node

Packaged separately from data/sql as a server will usually act as only one type of node, therefore only needs one set of binaries.

Data node

Packaged separately from mgmt/sql as a server will usually act as only one type of node, therefore only needs one set of binaries.

SQL node (the equivalent of mysql-server-5.5)

Packaged separately from mgmt/data as a server will usually act as only one type of node, therefore only needs one set of binaries.


tzdata trigger

<Sevet> periapt: by the way the mysql cluster packages have a trigger on tzdata that loads the timezone data into mysql (either via mysql cli or running a mysql bootstrap). it means whenever tzdata gets updated the copy of the timezone data in mysql is also updated. would that be a useful feature to add to mysql-5.5 too?
<Sevet> the way i'm doing it isn't necessarily the best way to do it though so might need some discussion - eg some users may not want that feature so should it be configurable, is a bootstrap best or might it be better to set a flag that's checked in debian-start, and might it even be worth putting it into a separate package to allow users to easily choose whether to use that feature or not (which might require debian-start.d directory hooks if it's decided not to use bootstrap)
<Sevet> if it's an example of common code between 5.5 and 7.2 then making it a separate package would let the same package be used with both versions

Since this code will be common, I've chosen to move this into a separate package. The current implementation (uses mysql if mysqld is running, bootstrapped mysqld if not) doesn't require any debian-start.d hooks, therefore should work with both the existing 5.5 and once the tzdata trigger is removed from 7.2 that too. Development is at

Relevant bug reports