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.3 Changes in MySQL Cluster NDB 6.3 :: 17.7.3.21 Changes in MySQL Cluster NDB 6.3.19 (5.1.29-ndb-6.3.19) (21 November 2008)
17.7.3.22 Changes in MySQL Cluster NDB 6.3.18 (5.1.28-ndb-6.3.18) (03 October 2008) »
Section Navigation      [Toggle]

17.7.3.21. Changes in MySQL Cluster NDB 6.3.19 (5.1.29-ndb-6.3.19) (21 November 2008)

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

This release incorporates all bugfixes and changes made in previous MySQL Cluster NDB 6.3 releases, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.29 (see Section C.1.23, “Changes in MySQL 5.1.29 (11 October 2008)”).

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:

  • Cluster API: Important Change: MGM API applications exited without raising any errors if the connection to the management server was lost. The fix for this issue includes two changes:

    1. The MGM API now provides its own SIGPIPE handler to catch the “broken pipe” error that occurs when writing to a closed or reset socket. This means that MGM API now behaves the same as NDB API in this regard.

    2. A new function ndb_mgm_set_ignore_sigpipe() has been added to the MGM API. This function makes it possible to bypass the SIGPIPE handler provded by the MGM API.

    (Bug#40498)

  • Cluster Replication: Important Note: This release of MySQL Cluster derives in part from MySQL 5.1.29, where the default value for the --binlog-format option changed to STATEMENT. That change does not affect this or future MySQL Cluster NDB 6.x releases, where the default value for this option remains MIXED, since MySQL Cluster Replication does not work with the statement-based format. (Bug#40586)

  • When performing an initial start of a data node, fragment log files were always created sparsely — that is, not all bytes were written. Now it is possible to override this behavior using the new InitFragmentLogFiles configuration parameter. (Bug#40847)

Bugs fixed:

  • Cluster API: Failed operations on BLOB and TEXT columns were not always reported correctly to the originating SQL node. Such errors were sometimes reported as being due to timeouts, when the actual problem was a transporter overload due to insufficient buffer space. (Bug#39867, Bug#39879)

  • Undo logs and data files were created in 32K increments. Now these files are created in 512K increments, resulting in shorter creation times. (Bug#40815)

  • Redo log creation was very slow on some platforms, causing MySQL Cluster to start more slowly than necessary with some combinations of hardware and operating system. This was due to all write operations being synchronized to disk while creating a redo log file. Now this synchronization occurs only after the redo log has been created. (Bug#40734)

  • Transaction failures took longer to handle than was necessary.

    When a data node acting as transaction coordinator (TC) failed, the surviving data nodes did not inform the API node initiating the transaction of this until the failure had been processed by all protocols. However, the API node needed only to know about failure handling by the transaction protocol — that is, it needed to be informed only about the TC takeover process. Now, API nodes (including MySQL servers acting as cluster SQL nodes) are informed as soon as the TC takeover is complete, so that it can carry on operating more quickly. (Bug#40697)

  • It was theoretically possible for stale data to be read from NDBCLUSTER tables when the transaction isolation level was set to ReadCommitted. (Bug#40543)

  • The LockExecuteThreadToCPU and LockMaintThreadsToCPU parameters did not work on Solaris. (Bug#40521)

  • SET SESSION ndb_optimized_node_selection = 1 failed with an invalid warning message. (Bug#40457)

  • A restarting data node could fail with an error in the DBDIH kernel block when a local or global checkpoint was started or triggered just as the node made a request for data from another data node. (Bug#40370)

  • Restoring a MySQL Cluster from a dump made using mysqldump failed due to a spurious error: Can't execute the given command because you have active locked tables or an active transaction. (Bug#40346)

  • O_DIRECT was incorrectly disabled when making MySQL Cluster backups. (Bug#40205)

  • Heavy DDL usage caused the mysqld processes to hang due to a timeout error (NDB error code 266). (Bug#39885)

  • Executing EXPLAIN SELECT on an NDBCLUSTER table could cause mysqld to crash. (Bug#39872)

  • Events logged after setting ALL CLUSTERLOG STATISTICS=15 in the management client did not always include the node ID of the reporting node. (Bug#39839)

  • The MySQL Query Cache did not function correctly with NDBCLUSTER tables containing TEXT columns. (Bug#39295)

  • A segfault in Logger::Log caused ndbd to hang indefinitely. This fix improves on an earlier one for this issue, first made in MySQL Cluster NDB 6.2.16 and MySQL Cluster NDB 6.3.17. (Bug#39180)

    See also Bug#38609.

  • Memory leaks could occur in handling of strings used for storing cluster metadata and providing output to users. (Bug#38662)

  • A duplicate key or other error raised when inserting into an NDBCLUSTER table caused the current transaction to abort, after which any SQL statement other than a ROLLBACK failed. With this fix, the NDBCLUSTER storage engine now performs an implicit rollback when a transaction is aborted in this way; it is no longer necessary to issue an explicit ROLLBACK statement, and the next statement that is issued automatically begins a new transaction.

    Note

    It remains necessary in such cases to retry the complete transaction, regardless of which statement caused it to be aborted.

    (Bug#32656)

    See also Bug#47654.

  • Error messages for NDBCLUSTER error codes 1224 and 1227 were missing. (Bug#28496)

  • Partitioning: Dropping or creating an index on a partitioned table managed by the InnoDB Plugin locked the table. (Bug#37453)

  • Disk Data: Issuing concurrent CREATE TABLESPACE, ALTER TABLESPACE, CREATE LOGFILE GROUP, or ALTER LOGFILE GROUP statements on separate SQL nodes caused a resource leak that led to data node crashes when these statements were used again later. (Bug#40921)

  • Disk Data: Disk-based variable-length columns were not always handled like their memory-based equivalents, which could potentially lead to a crash of cluster data nodes. (Bug#39645)

  • Disk Data: O_SYNC was incorrectly disabled on platforms that do not support O_DIRECT. This issue was noted on Solaris but could have affected other platforms not having O_DIRECT capability. (Bug#34638)

  • Cluster API: The MGM API reset error codes on management server handles before checking them. This meant that calling an MGM API function with a null handle caused applications to crash. (Bug#40455)

  • Cluster API: It was not always possible to access parent objects directly from NdbBlob, NdbOperation, and NdbScanOperation objects. To alleviate this problem, a new getNdbOperation() method has been added to NdbBlob and new getNdbTransaction() methods have been added to NdbOperation and NdbScanOperation. In addition, a const variant of NdbOperation::getErrorLine() is now also available. (Bug#40242)

  • Cluster API: NdbScanOperation::getBlobHandle() failed when used with incorrect column names or numbers. (Bug#40241)

  • Cluster API: The MGM API function ndb_mgm_listen_event() ignored bind addresses.

    As part of this fix, it is now possible to specify bind addresses in connectstrings. See Section 17.3.2.3, “The MySQL Cluster Connectstring”, for more information. (Bug#38473)

  • Cluster API: The NDB API example programs included in MySQL Cluster source distributions failed to compile. (Bug#37491)

    See also Bug#40238.