Functionality added or changed:
Many queries in MySQL Cluster are executed as range scans or full table scans. All queries that do not use a unique hash index or the primary hash index use this access method. In a distributed system it is crucial that batching is properly performed.
In previous versions, the batch size was fixed to 16 per data node. In this version it is configurable per MySQL Server. So for queries using lots of large scans it is appropriate to set this parameter rather large and for queries using many small scans only fetching a small amount of records it is appropriate to set it low.
The performance of queries can easily change as much as 40% based on how this variable is set.
In future versions more logic will be implemented for
assessing the batch size on a per-query basis. Thus, the
semantics of the new configuration variable
ScanBatchSize are likely to change.
The fixed size overhead of the ndbd process has been greatly decreased. This is also true for the overhead per operation record as well as overhead per table and index.
A number of new configuration variables have been introduced to enable configuration of system buffers. Configuration variables for specifying the numbers of tables, unique hash indexes, and ordered indexes have also been introduced.
New configuration variables:
Configuration variables no longer used:
MaxNoOfIndexes (split into the two above).
In previous versions
were performed as one big transaction. In this version, all of
these statements are automatically separated into several
This removes the limitation that one could not change very
large tables due to the
MySQL CLuster's online backup feature now backs up indexes so that both data and indexes are restored.
In previous versions it was not possible to use
NULL in indexes. This is now possible for
all supported index types.
Much work has been put onto making
AUTO_INCREMENT features work as for other
table handlers. Autoincrements as a partial key is still only
-i option for initial startup of
ndbd has been removed. Initial startup
still can be specified by using the
option. The reason for this is to ensure that it is clear what
takes place when using
--initial: this option
completely removes all data from the disk and should only be
used at initial start, in certain software upgrade cases, and
in some cases as a workaround when nodes cannot be restarted
The management client (ndb_mgm) now has
additional commands and more information is printed for some
commands such as
In previous versions, the files were called
ndb_0.. when it wasn't possible to
allocate a node ID when starting the node. To ensure that
files are not so easily overwritten, these files are now named
ndb_pid.., where pid is the process ID
assigned by the OS.
The default parameters have changed for
ndb_mgmd and ndbd. In
particular, they are now started as daemons by default. The
-n option has been removed since it could
cause confusion as to its meaning (nostart or nodaemon).
In the configuration file, you can now use
[NDBD] as an alias for
[MYSQLD] as an
[NDB_MGMD] as an alias for
[NDB_MGMD] are now the preferred
designations, although the older ones will continue to be
supported for some time to come in order to maintain
Many more checks for consistency in configuration have been introduced to in order to provide quicker feedback on configuration errors.
In the connect string, it is now possible to use both
,” as the separator between
entries. Thus, "nodeid=2,host=localhost:2200" is equivalent to
In the configuration file, it is also possible to use
=” for assignment values. For
MaxNoOfOrderedIndexes : 128 and
MaxNoOfOrderedIndexes = 128 are equivalent
The configuration variable names are now case insensitive, so
MaxNoOfOrderedIndexes: 128 is equivalent to
MAXNOOFORDEREDINDEXES = 128.
It is possible now to set the backup directory separately from
FileSystemPath by using the
BackupDir configuration variable.
Log files and trace files can now be placed in any directory
by setting the
FileSystemPath is no longer mandatory and
Queries involving tables from different databases are now supported.
It is now possible to update the primary key.
The performance of ordered indexes has been greatly improved, particularly the maintenance of indexes on updates, inserts and deletes.
Quite a few bugs fixed.