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)”).
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)
This issue, originally resolved in MySQL 5.1.16, re-occurred due to a later (unrelated) change. The fix has been re-applied.
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)
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.
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.
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:
Local checkpoint occurs.
Immediately following the LCP, kill the master data node.
Kill the remaining data nodes within a few seconds of killing the master.
Attempt to restart the cluster.
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.
If the server has been compiled using
--disable-ipv6
, it is not able to resolve
hostnames correctly when run in an IPv6 environment.
The hostname cache failed to work correctly. (Bug#45584)
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)
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)
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)
User Comments
Add your own comment.