Documentation Home
MySQL NDB Cluster 6.1 - 7.1 Release Notes
Download these Release Notes
PDF (US Ltr) - 3.0Mb
PDF (A4) - 3.0Mb

MySQL NDB Cluster 6.1 - 7.1 Release Notes  /  Changes in MySQL Cluster NDB 6.2  /  Changes in MySQL Cluster NDB 6.2.14 (5.1.23-ndb-6.2.14) (2008-03-05)

Changes in MySQL Cluster NDB 6.2.14 (5.1.23-ndb-6.2.14) (2008-03-05)

This is a bugfix release, fixing recently discovered bugs in the previous MySQL Cluster NDB 6.2 release.

MySQL Cluster NDB 6.2 no longer in development.  MySQL Cluster NDB 6.2 is no longer being developed or maintained; if you are using a MySQL Cluster NDB 6.2 release, you should upgrade to the latest version of MySQL Cluster, which is available from .

Obtaining MySQL Cluster NDB 6.2.  You can download the latest MySQL Cluster NDB 6.2 source code and binaries for supported platforms from

This release incorporates all bugfixes and changes made in previous MySQL Cluster releases, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.23 (see Changes in MySQL 5.1.23 (2008-01-29)).


Please refer to our bug database at for more details about the individual bugs fixed in this version.

Functionality Added or Changed

  • Added the MaxBufferedEpochs data node configuration parameter, which controls the maximum number of unprocessed epochs by which a subscribing node can lag. Subscribers which exceed this number are disconnected and forced to reconnect.

    See Defining MySQL Cluster Data Nodes, for more information.

  • Replication: Introduced the slave_exec_mode system variable to control whether idempotent or strict mode is used for replication conflict resolution. Idempotent mode suppresses duplicate-key, no-key-found, and some other errors, and is needed for circular replication, multi-master replication, and some other complex replication setups when using MySQL Cluster, where idempotent mode is the default. However, strict mode is the default for storage engines other than NDB. (Bug #31609)

  • Cluster Replication: RESET MASTER now uses TRUNCATE TABLE rather than DELETE to clear the mysql.ndb_binlog_index table. This improves the performance of the statement and is less likely to leave the table in a fragmented state. (Bug #34356)

  • Formerly, when the MySQL server crashed, the generated stack dump was numeric and required external tools to properly resolve the names of functions. This is not very helpful to users having a limited knowledge of debugging techniques. In addition, the generated stack trace contained only the names of functions and was formatted differently for each platform due to different stack layouts.

    Now it is possible to take advantage of newer versions of the GNU C Library provide a set of functions to obtain and manipulate stack traces from within the program. On systems that use the ELF binary format, the stack trace contains important information such as the shared object where the call was generated, an offset into the function, and the actual return address. Having the function name also makes possible the name demangling of C++ functions.

    The library generates meaningful stack traces on the following platforms: i386, x86_64, PowerPC, IA64, Alpha, and S390. On other platforms, a numeric stack trace is still produced, and the use of the resolve_stack_dump utility is still required. (Bug #31891)

  • mysqltest now has mkdir and rmdir commands for creating and removing directories. (Bug #31004)

  • Added the Uptime_since_flush_status status variable, which indicates the number of seconds since the most recent FLUSH STATUS statement. (Community contribution by Jeremy Cole) (Bug #24822)

Bugs Fixed

  • Performance: InnoDB exhibited thread thrashing with more than 50 concurrent connections under an update-intensive workload. (Bug #22868)

  • Incompatible Change: The UPDATE statement permitted NULL to be assigned to NOT NULL columns (the implicit default value for the column data type was assigned). This was changed so that on error occurs.

    This change was reverted, because the original report was determined not to be a bug: Assigning NULL to a NOT NULL column in an UPDATE statement should produce an error only in strict SQL mode and set the column to the implicit default with a warning otherwise, which was the original behavior. See Data Type Default Values, and Bug #39265. (Bug #33699)

    References: See also: Bug #39265.

  • Incompatible Change: Previously, the parser accepted the ODBC { OJ ... LEFT OUTER JOIN ...} syntax for writing left outer joins. The parser now permits { OJ ... } to be used to write other types of joins, such as INNER JOIN or RIGHT OUTER JOIN. This helps with compatibility with some third-party applications, but is not official ODBC syntax.

    A consequence of this change is that the parser no longer permits nested { OJ ... } constructs (which are not legal ODBC syntax, anyway). Queries that use such constructs should be rewritten. For example, this query is now produces an error:

          {OJ a LEFT OUTER JOIN b ON a.a1=b.a1}
          LEFT OUTER JOIN c ON b.b1 = c.b1};

    That can be replaced by any of the following rewrites:

        {OJ a LEFT OUTER JOIN b
              LEFT OUTER JOIN c ON b.b1 = c.b1 ON a.a1=b.a1};
       {OJ a LEFT OUTER JOIN b ON a.a1=b.a1
             LEFT OUTER JOIN c ON b.b1 = c.b1};
         a LEFT OUTER JOIN b ON a.a1=b.a1 LEFT OUTER JOIN c ON b.b1 = c.b1;

    The first two are legal according to ODBC, and you nest the joins inside a single { OJ ...} clause. The third is standard SQL syntax, without ODBC decoration. It can be used with parentheses to emphasize the evaluation order:

         ((a LEFT OUTER JOIN b ON a.a1=b.a1)
             LEFT OUTER JOIN c ON b.b1 = c.b1);

    (Bug #28317)

  • Important Change; Replication: When the master crashed during an update on a transactional table while in autocommit mode, the slave failed. This fix causes every transaction (including autocommit transactions) to be recorded in the binary log as starting with a BEGIN and ending with a COMMIT or ROLLBACK.


    The current fix does not cause nontransactional changes to be wrapped in BEGIN ... COMMIT or BEGIN ... ROLLBACK when written to the binary log. For this purpose, any statements affecting tables using a nontransactional storage engine such as MyISAM are regarded as nontransactional, even when autocommit is enabled.

    (Bug #26395)

    References: See also: Bug #29288, Bug #49522.

  • Important Note; Replication: Network timeouts between the master and the slave could result in corruption of the relay log. This fix rectifies a long-standing replication issue when using unreliable networks, including replication over wide area networks such as the Internet. If you experience reliability issues and see many You have an error in your SQL syntax errors on replication slaves, we strongly recommend that you upgrade to a MySQL version which includes this fix. (Bug #26489)

  • Replication: When the Windows version of mysqlbinlog read 4.1 binary logs containing LOAD DATA INFILE statements, it output backslashes as path separators, causing problems for client programs expecting forward slashes. In such cases, it now converts \\ to / in directory paths. (Bug #34355)

  • Replication: SHOW SLAVE STATUS failed when slave I/O was about to terminate. (Bug #34305)

  • Replication: mysqlbinlog from a 5.1 or later MySQL distribution could not read binary logs generated by a 4.1 server when the logs contained LOAD DATA INFILE statements. (Bug #34141)

    References: This issue is a regression of: Bug #32407.

  • Replication: A CREATE USER, DROP USER, or RENAME USER statement that fails on the master, or that is a duplicate of any of these statements, is no longer written to the binary log; previously, either of these occurrences could cause the slave to fail. (Bug #33862)

    References: See also: Bug #29749.

  • Replication: mysqlbinlog failed to release all of its memory after terminating abnormally. (Bug #33247)

  • Replication: The error message generated due to lack of a default value for an extra column was not sufficiently informative. (Bug #32971)

  • Replication: When a user variable was used inside an INSERT statement, the corresponding binary log event was not written to the binary log correctly. (Bug #32580)

  • Replication: When using row-based replication, deletes from a table with a foreign key constraint failed on the slave. (Bug #32468)

  • Replication: SQL statements containing comments using -- syntax were not replayable by mysqlbinlog, even though such statements replicated correctly. (Bug #32205)

  • Replication: When using row-based replication from a master running MySQL 5.1.21 or earlier to a slave running 5.1.22 or later, updates of integer columns failed on the slave with Error in Unknown event: row application failed. (Bug #31583)

    References: This issue is a regression of: Bug #21842.

  • Replication: Replicating write, update, or delete events from a master running MySQL 5.1.15 or earlier to a slave running 5.1.16 or later caused the slave to crash. (Bug #31581)

  • Replication: When using row-based replication, the slave stopped when attempting to delete nonexistent rows from a slave table without a primary key. In addition, no error was reported when this occurred. (Bug #31552)

  • Replication: Issuing a DROP VIEW statement caused replication to fail if the view did not actually exist. (Bug #30998)

  • Replication: Replication of LOAD DATA INFILE could fail when read_buffer_size was larger than max_allowed_packet. (Bug #30435)

  • Replication: Replication crashed with the NDB storage engine when mysqld was started with --character-set-server=ucs2. (Bug #29562)

  • Replication: Setting server_id did not update its value for the current session. (Bug #28908)

  • Replication: Some older servers wrote events to the binary log using different numbering from what is currently used, even though the file format number in the file is the same. Slaves running MySQL 5.1.18 and later could not read these binary logs properly. Binary logs from these older versions now are recognized and event numbers are mapped to the current numbering so that they can be interpreted properly. (Bug #27779, Bug #32434)

    References: This issue is a regression of: Bug #22583.

  • Cluster Replication: Using --ndb-wait-connected caused the server to wait for a partial connection, plus an additional 3 seconds for a complete connection to the cluster. This could lead to issues with setting up the binary log. (Bug #34757)

  • Cluster API: Closing a scan before it was executed caused the application to segfault. (Bug #36375)

  • Cluster API: Using NDB API applications from older MySQL Cluster versions with libndbclient from newer ones caused the cluster to fail. (Bug #36124)

  • Cluster API: Scans having no bounds set were handled incorrectly. (Bug #35876)

  • Use of stored functions in the WHERE clause for SHOW OPEN TABLES caused a server crash. (Bug #34166)

  • Large unsigned integers were improperly handled for prepared statements, resulting in truncation or conversion to negative numbers. (Bug #33798)

  • The server crashed when executing a query that had a subquery containing an equality X=Y where Y referred to a named select list expression from the parent select. The server crashed when trying to use the X=Y equality for ref-based access. (Bug #33794)

  • ORDER BY ... DESC sorts could produce misordered results. (Bug #33697)

  • The server could crash when REPEAT or another control instruction was used in conjunction with labels and a LEAVE instruction. (Bug #33618)

  • SET GLOBAL myisam_max_sort_file_size=DEFAULT set myisam_max_sort_file_size to an incorrect value. (Bug #33382)

    References: See also: Bug #31177.

  • Granting the UPDATE privilege on one column of a view caused the server to crash. (Bug #33201)

  • For DECIMAL columns used with the ROUND(X,D) or TRUNCATE(X,D) function with a nonconstant value of D, adding an ORDER BY for the function result produced misordered output. (Bug #33143)

    References: See also: Bug #33402, Bug #30617.

  • The SHOW ENGINE INNODB STATUS and SHOW ENGINE INNODB MUTEX statements incorrectly required the SUPER privilege rather than the PROCESS privilege. (Bug #32710)

  • Tables in the mysql database that stored the current sql_mode value as part of stored program definitions were not updated with newer mode values (NO_ENGINE_SUBSTITUTION, PAD_CHAR_TO_FULL_LENGTH). This causes various problems defining stored programs if those modes were included in the current sql_mode value. (Bug #32633)

  • ROUND(X,D) or TRUNCATE(X,D) for nonconstant values of D could crash the server if these functions were used in an ORDER BY that was resolved using filesort. (Bug #30889)

  • Resetting the query cache by issuing a SET GLOBAL query_cache_size=0 statement caused the server to crash if it concurrently was saving a new result set to the query cache. (Bug #30887)

  • The Table_locks_waited waited variable was not incremented in the cases that a lock had to be waited for but the waiting thread was killed or the request was aborted. (Bug #30331)

  • The Com_create_function status variable was not incremented properly. (Bug #30252)

  • mysqld displayed the --enable-pstack option in its help message even if MySQL was configured without --with-pstack. (Bug #29836)

  • Views were treated as insertable even if some base table columns with no default value were omitted from the view definition. (This is contrary to the condition for insertability that a view must contain all columns in the base table that do not have a default value.) (Bug #29477)

  • The parser rules for the SHOW PROFILE statement were revised to work with older versions of bison. (Bug #27433)

  • resolveip failed to produce correct results for host names that begin with a digit. (Bug #27427)

  • mysqlcheck -A -r did not correctly identify all tables that needed repairing. (Bug #25347)

  • Warnings for deprecated syntax constructs used in stored routines make sense to report only when the routine is being created, but they were also being reported when the routine was parsed for loading into the execution cache. Now they are reported only at routine creation time. (Bug #21801)

  • CREATE ... SELECT did not always set DEFAULT column values in the new table. (Bug #21380)

  • If a SELECT calls a stored function in a transaction, and a statement within the function fails, that statement should roll back. Furthermore, if ROLLBACK is executed after that, the entire transaction should be rolled back. Before this fix, the failed statement did not roll back when it failed (even though it might ultimately get rolled back by a ROLLBACK later that rolls back the entire transaction). (Bug #12713)

    References: See also: Bug #34655.