Skip navigation links
MySQL 5.1 Reference Manual :: 17 MySQL Cluster NDB 6.X/7.X :: 17.7 Changes in MySQL Cluster NDB 6.X and 7.X :: 17.7.2 Changes in MySQL Cluster NDB 7.0 :: 17.7.2.16 Changes in MySQL Cluster NDB 7.0.7 (5.1.35-ndb-7.0.7) (26 August 2009)
17.7.2.17 Changes in MySQL Cluster NDB 7.0.6 (5.1.34-ndb-7.0.6) (26 May 2009) »
Section Navigation      [Toggle]

17.7.2.16. Changes in MySQL Cluster NDB 7.0.7 (5.1.35-ndb-7.0.7) (26 August 2009)

This release incorporates new features in the NDBCLUSTER storage engine and fixes recently discovered bugs in MySQL Cluster NDB 7.0.6.

Obtaining MySQL Cluster NDB 7.0.7.  The latest MySQL Cluster NDB 7.0 binaries for supported platforms can be obtained from http://dev.mysql.com/downloads/select.php?id=14. Source code for the latest MySQL Cluster NDB 7.0 release can be obtained from the same location. You can also access the MySQL Cluster NDB 7.0 development source tree at https://code.launchpad.net/~mysql/mysql-server/mysql-cluster-7.0.

This release also incorporates all bugfixes and changes made in previous MySQL Cluster NDB 6.1, 6.2, 6.3, and 7.0 releases, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.35 (see Section C.1.15, “Changes in MySQL 5.1.35 (13 May 2009)”).

Note

Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.

Functionality added or changed:

  • Important Change: The default value of the DiskIOThreadPool data node configuration parameter has changed from 8 to 2.

  • On Solaris platforms, the MySQL Cluster management server and NDB API applications now use CLOCK_REALTIME as the default clock. (Bug#46183)

  • Formerly, node IDs were represented in the cluster log using a complex hexadecimal/binary encoding scheme. Now, node IDs are reported in the cluster log using numbers in standard decimal notation. (Bug#44248)

  • A new option --exclude-missing-columns has been added for the ndb_restore program. In the event that any tables in the database or databases being restored to have fewer columns than the same-named tables in the backup, the extra columns in the backup's version of the tables are ignored. For more information, see Section 17.4.17, “ndb_restore — Restore a MySQL Cluster Backup”. (Bug#43139)

  • Note

    This issue, originally resolved in MySQL 5.1.16, re-occurred due to a later (unrelated) change. The fix has been re-applied.

    (Bug#25984)

  • Previously, it was possible to disable arbitration only by setting ArbitrationRank to 0 on all management and API nodes. A new data node configuration parameter Arbitration simplifies this task; to disable arbitration, you can now use Arbitration = Disabled in the [ndbd default] section of the config.ini file.

    It is now also possible to configure arbitration in such a way that the cluster waits until the time determined by ArbitrationTimeout passes for an external manager to perform arbitration instead of handling it internally. This can be done by setting Arbitration = WaitExternal in the [ndbd default] section of the config.ini file.

    The default value for the Arbitration parameter is Default, which allows arbitration to proceed normally, as determined by the ArbitrationRank settings for the management and API nodes.

    For more information, see Section 17.3.2.6, “Defining MySQL Cluster Data Nodes”.

Bugs fixed:

  • Packaging: The pkg installer for MySQL Cluster on Solaris did not perform a complete installation due to an invalid directory reference in the post-install script. (Bug#41998)

  • The output from ndb_config --configinfo --xml contained quote characters (") within quoted XML attributes, causing it to be not well-formed. (Bug#46891)

  • When using multi-threaded data node processes (ndbmtd), it was possible for LQH threads to continue running even after all NDB tables had been dropped. This meant that dropping the last remaining NDB table during a local checkpoint could cause multi-threaded data nodes to fail. (Bug#46890)

  • During a global checkpoint, LQH threads could run unevenly, causing a circular buffer oveflow by the Subscription Manager, which led to data node failure. (Bug#46782)

    See also Bug#46123, Bug#46723, Bug#45612.

  • Restarting the cluster following a local checkpoint and an online ALTER TABLE on a non-empty table caused data nodes to crash. (Bug#46651)

  • A combination of index creation and drop operations (or creating and dropping tables having indexes) with node and system restarts could lead to a crash. (Bug#46552)

  • Following an upgrade from MySQL Cluster NDB 6.3.x to MySQL Cluster NDB 7.0.6, DDL and backup operations failed. (Bug#46494, Bug#46563)

  • Full table scans failed to execute when the cluster contained more than 21 table fragments.

    Note

    The number of table fragments in the cluster can be calculated as the number of data nodes, times 8 (that is, times the value of the internal constant MAX_FRAG_PER_NODE), divided by the number of replicas. Thus, when NoOfReplicas = 1 at least 3 data nodes were required to trigger this issue, and when NoOfReplicas = 2 at least 4 data nodes were required to do so.

    (Bug#46490)

  • Killing MySQL Cluster nodes immediately following a local checkpoint could lead to a crash of the cluster when later attempting to perform a system restart.

    The exact sequence of events causing this issue was as follows:

    1. Local checkpoint occurs.

    2. Immediately following the LCP, kill the master data node.

    3. Kill the remaining data nodes within a few seconds of killing the master.

    4. Attempt to restart the cluster.

    (Bug#46412)

  • Creating an index when the cluster had run out of table records could cause data nodes to crash. (Bug#46295)

  • Ending a line in the config.ini file with an extra semicolon character (;) caused reading the file to fail with a parsing error. (Bug#46242)

  • When combining an index scan and a delete with a primary key delete, the index scan and delete failed to initialize a flag properly. This could in rare circumstances cause a data node to crash. (Bug#46069)

  • OPTIMIZE TABLE on an NDB table could in some cases cause SQL and data nodes to crash. This issue was observed with both ndbd and ndbmtd. (Bug#45971)

  • The AutoReconnect configuration parameter for API nodes (including SQL nodes) has been added. This is intended to prevent API nodes from re-using allocated node IDs during cluster restarts. For more information, see Section 17.3.2.7, “Defining SQL and Other API Nodes in a MySQL Cluster”.

    This fix also introduces two new methods of the Ndb_cluster_connection class in the NDB API. For more information, see Ndb_cluster_connection::set_auto_reconnect(), and Ndb_cluster_connection::get_auto_reconnect(). (Bug#45921)

  • DML statements run during an upgrade from MySQL Cluster NDB 6.3 to NDB 7.0 were not handled correctly. (Bug#45917)

  • On Windows, the internal basestring_vsprintf() function did not return a POSIX-compliant value as expected, causing the management server to crash when trying to start a MySQL Cluster with more than 4 data nodes. (Bug#45733)

  • The signals used by ndb_restore to send progress information about backups to the cluster log accessed the cluster transporter without using any locks. Because of this, it was theoretically possible that these signals could be interefered with by heartbeat signals if both were sent at the same time, causing the ndb_restore messages to be corrupted. (Bug#45646)

  • Due to changes in the way that NDBCLUSTER handles schema changes (implementation of schema transactions) in MySQL Cluster NDB 7.0, it was not possible to create MySQL Cluster tables having more than 16 indexes using a single CREATE TABLE statement.

    This issue occurs only in MySQL Cluster NDB 7.0 releases prior to 7.0.7 (including releases numbered NDB 6.4.x).

    If you are not yet able to upgrade from an earlier MySQL Cluster NDB 7.0 release, you can work around this problem by creating the table without any indexes, then adding the indexes using a separate CREATE INDEX statement for each index. (Bug#45525)

  • storage/ndb/src/common/util/CMakeLists.txt did not build the BaseString-t test program for Windows as the equivalent storage/ndb/src/common/util/Makefile.am does when building MySQL Cluster on Unix platforms. (Bug#45099)

  • Problems could arise when using VARCHAR columns whose size was greater than 341 characters and which used the utf8_unicode_ci collation. In some cases, this combination of conditions could cause certain queries and OPTIMIZE TABLE statements to crash mysqld. (Bug#45053)

  • The warning message Possible bug in Dbdih::execBLOCK_COMMIT_ORD ... could sometimes appear in the cluster log. This warning is obsolete, and has been removed. (Bug#44563)

  • Debugging code causing ndbd to use file compression on NTFS filesystems failed with an error. (The code was removed.) This issue affected debug builds of MySQL Cluster on Windows platforms only. (Bug#44418)

  • ALTER TABLE REORGANIZE PARTITION could fail with Error 741 (Unsupported alter table) if the appropriate hash-map was not present. This could occur when adding nodes online; for example, when going from 2 data nodes to 3 data nodes with NoOfReplicas=1, or from 4 data nodes to 6 data nodes with NoOfReplicas=2. (Bug#44301)

  • Previously, a GCP STOP event was written to the cluster log as an INFO event. Now it is logged as a WARNING event instead. (Bug#43853)

  • In some cases, OPTIMIZE TABLE on an NDB table did not free any DataMemory. (Bug#43683)

  • If the cluster crashed during the execution of a CREATE LOGFILE GROUP statement, the cluster could not be restarted afterwards. (Bug#36702)

    See also Bug#34102.

  • Disk Data: Partitioning: An NDBCLUSTER table created with a very large value for the MAX_ROWS option could — if this table was dropped and a new table with fewer partitions, but having the same table ID, was created — cause ndbd to crash when performing a system restart. This was because the server attempted to examine each partition whether or not it actually existed. (Bug#45154)

  • Disk Data: If the value set in the config.ini file for FileSystemPathDD, FileSystemPathDataFiles, or FileSystemPathUndoFiles was identical to the value set for FileSystemPath, that parameter was ignored when starting the data node with --initial option. As a result, the Disk Data files in the corresponding directory were not removed when performing an initial start of the affected data node or data nodes. (Bug#46243)

  • For an IPv6-enabled MySQL server, privileges specified using standard IPv4 addresses for hosts were not matched (only IPv4-mapped addresses were handled correctly).

    As part of the fix for this bug, a new build option --disable-ipv6 has been introduced. Compiling MySQL with this option causes all IPv6-specific code in the server to be ignored.

    Important

    If the server has been compiled using --disable-ipv6, it is not able to resolve hostnames correctly when run in an IPv6 environment.

    (Bug#45606)

    See also Bug#38247, Bug#43006, Bug#45283, Bug#45584.

  • The hostname cache failed to work correctly. (Bug#45584)

    See also Bug#38247, Bug#43006, Bug#45283, Bug#45606.

  • The number of connection errors from a given host as counted by the server was periodically reset, with the result that max_connect_errors was never reached and invalid hosts were never blocked from trying to connect. (Bug#45283)

    See also Bug#38247, Bug#43006, Bug#45584, Bug#45606.

  • The IPv6 loopback address ::1 was interpeted as a hostname rather than a numeric IP address.

    In addition, the IPv6-enabled server on Windows interpeted the hostname localhost as ::1 only, which failed to match the default root@127.0.0.1 entry in the mysql.user privilege table. (Bug#43006)

    See also Bug#38247, Bug#45283, Bug#45584, Bug#45606.

  • An IPv6-enabled MySQL server did not resolve the IP addresses of incoming connections correctly, with the result that a connection that attempted to match any privilege table entries using fully-qualified domain names for hostnames or hostnames using wildcards were dropped. (Bug#38247)

    See also Bug#43006, Bug#45283, Bug#45584, Bug#45606.