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:
- Management node (ndb_mgmd)
- Data node (ndbd / ndbmtd)
- SQL node (mysqld)
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).
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.
- Depends on mysql-common for my.cnf which includes /etc/mysql/conf.d files.
- Provides /etc/mysql/conf.d/my-cluster.cnf included from /etc/mysql/my.cnf
MySQL client programs are not packages (eg mysql), instead it depends on mysql-client from mysql-5.5.
- Depends on mysql-cluster-client-7.2
- Provides the ndb_* binaries
- This includes the ndb_mgm client for connecting to a management node to monitor/control the cluster.
- This packages ClusterJ, a Java connector for the NDB cluster
Packaged separately from data/sql as a server will usually act as only one type of node, therefore only needs one set of binaries.
- Contains the management node binaries (ndb_mgmd and init.d scripts)
Packaged separately from mgmt/sql as a server will usually act as only one type of node, therefore only needs one set of binaries.
- Contains the data node binaries (ndbd and ndbmtd and init.d scripts)
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.
- Contains the usual MySQL Server binaries and plugins (mysqld, mysqld_safe, init.d/logrotate/etc scripts, plugins and so on)
- Distributes the MySQL Cluster source code installing as a tarball in /usr/src
- The MySQL Cluster testsuite
- Differs from MySQL Server testsuite in that it contains additional NDB tests
<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 https://github.com/SteveAyre/mysql-tzdata.