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.27 Changes in MySQL Cluster NDB 6.3.13 (5.1.24-ndb-6.3.13) (10 April 2008)
17.7.3.28 Changes in MySQL Cluster NDB 6.3.12 (5.1.23-ndb-6.3.12) (05 April 2008) »
Section Navigation      [Toggle]

17.7.3.27. Changes in MySQL Cluster NDB 6.3.13 (5.1.24-ndb-6.3.13) (10 April 2008)

This is a new source release, fixing recently discovered bugs in previous MySQL Cluster NDB 6.3 releases.

Obtaining MySQL Cluster NDB 6.3.  This is a source-only release, which you must compile and install using the instructions found in Section 2.3, “MySQL Installation Using a Source Distribution”, and in Section 17.2.1, “MySQL Cluster Multi-Computer Installation”. You can download the GPL source tarball from the MySQL FTP site at ftp://ftp.mysql.com/pub/mysql/download/cluster_telco/.

This release incorporates all bugfixes and changes made in the previous MySQL Cluster NDB 6.3 release, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.24 (see Section C.1.28, “Changes in MySQL 5.1.24 (08 April 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:

  • The ndbd and ndb_mgmd man pages have been reclassified from volume 1 to volume 8. (Bug#34642)

Bugs fixed:

  • Important Change: mysqld_safe now traps Signal 13 (SIGPIPE) so that this signal no longer kills the MySQL server process. (Bug#33984)

  • Node or system restarts could fail due an unitialized variable in the DTUP kernel block. This issue was found in MySQL Cluster NDB 6.3.11. (Bug#35797)

  • If an error occured while executing a statement involving a BLOB or TEXT column of an NDB table, a memory leak could result. (Bug#35593)

  • It was not possible to determine the value used for the --ndb-cluster-connection-pool option in the mysql client. Now this value is reported as a system status variable. (Bug#35573)

  • The ndb_waiter utility wrongly calculated timeouts. (Bug#35435)

  • A SELECT on a table with a nonindexed, large VARCHAR column which resulted in condition pushdown on this column could cause mysqld to crash. (Bug#35413)

  • ndb_restore incorrectly handled some datatypes when applying log files from backups. (Bug#35343)

  • In some circumstances, a stopped data node was handled incorrectly, leading to redo log space being exhausted following an initial restart of the node, or an initial or partial restart of the cluster (the wrong CGI might be used in such cases). This could happen, for example, when a node was stopped following the creation of a new table, but before a new LCP could be executed. (Bug#35241)

  • SELECT ... LIKE ... queries yielded incorrect results when used on NDB tables. As part of this fix, condition pushdown of such queries has been disabled; re-enabling it is expected to be done as part of a later, permanent fix for this issue. (Bug#35185)

  • ndb_mgmd reported errors to STDOUT rather than to STDERR. (Bug#35169)

  • Nested Multi-Range Read scans failed when the second Multi-Range Read released the first read's unprocessed operations, sometimes leading to an SQL node crash. (Bug#35137)

  • In some situations, a problem with synchronizing checkpoints between nodes could cause a system restart or a node restart to fail with Error 630 during restore of TX. (Bug#34756)

  • A node failure during an initial node restart followed by another node start could cause the master data node to fail, because it incorrectly gave the node permission to start even if the invalidated node's LCP was still running. (Bug#34702)

  • When a secondary index on a DECIMAL column was used to retrieve data from an NDB table, no results were returned even if the target table had a matched value in the column that was defined with the secondary index. (Bug#34515)

  • An UPDATE on an NDB table that set a new value for a unique key column could cause subsequent queries to fail. (Bug#34208)

  • If a data node in one node group was placed in the “not started” state (using node_id RESTART -n), it was not possible to stop a data node in a different node group. (Bug#34201)

  • Numerous NDBCLUSTER test failures occurred in builds compiled using icc on IA64 platforms. (Bug#31239)

  • If a START BACKUP command was issued while ndb_restore was running, the backup being restored could be overwritten. (Bug#26498)

  • REPLACE statements did not work correctly with NDBCLUSTER tables when all columns were not explicitly listed. (Bug#22045)

  • CREATE TABLE and ALTER TABLE statements using ENGINE=NDB or ENGINE=NDBCLUSTER caused mysqld to fail on Solaris 10 for x86 platforms. (Bug#19911)

  • Replication: A CHANGE MASTER TO statement with no MASTER_HEARTBEAT_PERIOD option failed to reset the heartbeat period to its default value. (Bug#34686)

  • Cluster Replication: In some cases, when updating only one or some columns in a table, the complete row was written to the binary log instead of only the updated column or columns, even when ndb_log_updated_only was set to 1. (Bug#35208)

  • Cluster Replication: Enabling the ndb_wait_connected system variable 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: Some ordered index scans could return tuples out of order. (Bug#35908)

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

  • Cluster API: NdbScanFilter::getNdbOperation(), which was inadvertently removed in MySQL Cluster NDB 6.3.11, has been restored. (Bug#35854)

  • Enabling the read_only system variable while autocommit mode was enabled caused SELECT statements for transactional storage engines to fail. (Bug#35732)

  • Executing a FLUSH PRIVILEGES statement after creating a temporary table in the mysql database with the same name as one of the MySQL system tables caused the server to crash.

    Note

    While it is possible to shadow a system table in this way, the temporary table exists only for the current user and connection, and does not effect any user privileges.

    (Bug#33275)