16.10.2. MySQL 5.1 Development Roadmap for MySQL Cluster
What is said here is a status report based on recent commits to
the MySQL 5.1 source tree. It should be noted all 5.1
development is subject to change.
There are currently 4 major new features being developed for
Integration of MySQL Cluster into
MySQL replication: This will make it possible to
update from any MySQL Server in the cluster and still have
the MySQL Replication handled by one of the MySQL Servers in
the cluster, with the state of the slave side remaining
consistent with the cluster acting as the master.
Support for disk-based
records: Records on disk will be supported.
Indexed fields including the primary key hash index must
still be stored in RAM but all other fields can be on disk.
Variable-sized records: A
column defined as
uses 260 bytes of storage independent of what is stored in
any particular record. In MySQL 5.1 Cluster tables, only the
portion of the column actually taken up by the record will
be stored. This will make possible a reduction in space
requirements for such columns by a factor of 5 in many
Users will be able to define partitions based on columns
that are part of the primary key. The MySQL Server will be
able to discover whether it is possible to prune away some
of the partitions from the
Partitioning based on
LIST handlers will be possible, as well
as subpartitioning. This feature should also be available
for many other handlers, and not only
In addition, we are working to increase the 8KB size limit for
rows containing columns of types other than
TEXT in Cluster
tables. This is due to the fact that rows are currently fixed in
size and the page size is 32,768 bytes (minus 128 bytes for the
row header). Currently, this means that if we allowed more than
8KB per record, any remaining space (up to approximately 14,000
bytes) would be left empty. In MySQL 5.1, we plan to fix this
limitation so that using more than 8KB in a given row does not
result in the remainder of the page being wasted.