MySQL Cluster 6.3.20 has been released

Dear MySQL Cluster users,

MySQL Cluster 6.3.20, a new version of the popular Open Source Database
Management System, has been released.  MySQL Cluster is a High
Availability Database for Real-Time, Mission Critical Applications.
The release is now available in source and binary form for a number of
platforms (Linux, Solaris, Mac OS X) from our download pages at

  http://dev.mysql.com/downloads/cluster/

and mirror sites.  Note that not all mirror sites may be up to date at
this point in time, so if you can't find this version on some mirror,
please try again later or choose another download site.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches etc.:

  http://forge.mysql.com/wiki/Contributing

The following section lists important, incompatible and security
changes since the previous MySQL Cluster 6.3.17 release.  The full
changelog including many more fixes can be viewed online at

  http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-news-6-3.html

This is a bugfix release which replaces MySQL Cluster 6.3.17.
Please note: MySQL Cluster 6.3.17 was based on MySQL 5.1.27,
             MySQL Cluster 6.3.20 is  based on MySQL 5.1.30 -
so in addition to the changes to the cluster part (listed in this mail),
the changes to the general server versions 5.1.28, 5.1.29, and 5.1.30
apply. Please find them at

   http://dev.mysql.com/doc/refman/5.1/en/news-5-1-x.html


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)

 * MySQL Cluster: 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)

 * MySQL Cluster: It is no longer a requirement for database
   autodiscovery that an SQL node already be connected to the cluster at
   the time that a database is created on another SQL node. It is no
   longer necessary to issue CREATE DATABASE (or CREATE SCHEMA)
   statements on an SQL node joining the cluster after a database is
   created in order for the new SQL node to see the database and any
   NDCLUSTER tables that it contains. (Bug#39612)


Bugs fixed:

 * Cluster API: MySQL Cluster: 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)

 * MySQL Cluster: 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)

 * MySQL Cluster: 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)

 * MySQL Cluster: 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)

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

 * MySQL Cluster: The LockExecuteThreadToCPU and LockMaintThreadsToCPU
   parameters did not work on Solaris. (Bug#40521)

 * MySQL Cluster: SET SESSION ndb_optimized_node_selection = 1 failed
   with an invalid warning message. (Bug#40457)

 * MySQL Cluster: 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)

 * MySQL Cluster: 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)

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

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

 * MySQL Cluster: Executing EXPLAIN SELECT on an NDBCLUSTER table could
   cause mysqld to crash. (Bug#39872)

 * MySQL Cluster: 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)

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

 * MySQL Cluster: 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.

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

 * MySQL Cluster: A duplicate key 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 supports rollback of individual
   statements in such cases, and it is no longer necessary to issue an
   explicit ROLLBACK and then retry the entire transaction. (Bug#32656)

 * MySQL Cluster: Error messages for NDBCLUSTER error codes 1224 and
   1227 were missing. (Bug#28496)

 * MySQL Cluster: When a transaction included a multi-row insert to an
   NDBCLUSTER table that caused a constraint violation, the transaction
   failed to roll back. (Bug#395638)

 * MySQL Cluster: Starting the MySQL Server with the --ndbcluster option
   plus an invalid command-line option (for example, using mysqld
   --ndbcluster --foobar) caused it to hang while shutting down the
   binlog thread. (Bug#39635)

 * MySQL Cluster: Dropping and then re-creating a database on one SQL
   node caused other SQL nodes to hang. (Bug#39613)

 * MySQL Cluster: Setting a low value of MaxNoOfLocalScans (< 100) and
   performing a large number of (certain) scans could cause the
   Transaction Coordinator to run out of scan fragment records, and then
   crash. Now when this resource is exhausted, the cluster returns Error
   291 (Out of scanfrag records in TC (increase MaxNoOfLocalScans))
   instead. (Bug#39549)

 * MySQL Cluster: Creating a unique index on an NDBCLUSTER table caused
   a memory leak in the NDB subscription manager (SUMA) which could lead
   to mysqld hanging, due to the fact that the resource shortage was not
   reported back to the NDB kernel correctly. (Bug#39518)
   See also Bug#39450.

 * MySQL Cluster: Embedded libmysqld with NDB did not drop table events.
   (Bug#39450)

 * MySQL Cluster: Unique identifiers in tables having no primary key
   were not cached. This fix has been observed to increase the
   efficiency of INSERT operations on such tables by as much as 50%.
   (Bug#39267)

 * MySQL Cluster: When restarting a data node, an excessively long
   shutodwn message could cause the node process to crash. (Bug#38580)

 * MySQL Cluster: After a forced shutdown and initial restart of the
   cluster, it was possible for SQL nodes to retain .FRM files
   corresponding to NDBCLUSTER tables that had been dropped, and thus to
   be unaware that these tables no longer existed. In such cases,
   attempting to re-create the tables using CREATE TABLE IF NOT EXISTS
   could fail with a spurious Table ... doesn't exist error. (Bug#37921)

 * MySQL Cluster: A statement of the form DELETE FROM table WHERE
   primary_key=value or UPDATE table WHERE primary_key=value where there
   was no row whose primary key column had the stated value appeared to
   succeed, with the server reporting that 1 row had been changed.
   This issue was only known to affect MySQL Cluster NDB 6.3.11 and
   later NDB 6.3 versions. (Bug#37153)

 * Cluster Replication: In some cases, dropping a database on the master
   could cause table logging to fail on the slave, or, when using a
   debug build, could cause the slave mysqld to fail completely.
   (Bug#39404)

 * Partitioning: This bug was introduced in MySQL Cluster NDB 6.3.19.
   (Bug#40954)
   This regression was introduced by Bug#30573, Bug#33257, Bug#33555.

 * 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.4.2, "The 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.

 * Cluster API: Passing a value greater than 65535 to
   NdbInterpretedCode::add_val() and NdbInterpretedCode::sub_val()
   caused these methods to have no effect. (Bug#39536)


Regards,
enjoy the holidays as they are applicable to you,
and a Happy New Year 2009 to all of you!

On behalf of the MySQL Build Team at Sun,
Jörg Brühe

-- 
Joerg Bruehe,  MySQL Build Team,  [email protected]
Sun Microsystems GmbH,   Sonnenallee 1,   D-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering     Muenchen: HRB161028





-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[email protected]