Sreedhar S
2014-10-18 01:31:33 UTC
Dear MySQL users,
MySQL Cluster is the distributed, shared-nothing variant of MySQL. This
storage engine provides:
- Real-time performance based on in-memory storage (with
checkpointing to disk)
- Read & write scalability through transparent auto-sharding
- 99.999% High Availability with no single point of failure and
on-line maintenance
- SQL and NoSQL API (including C++, Java, http, Memcached and
JavaScript/Node.js)
- Active-Active/Multi-Master geographic replication
MySQL Cluster 7.3.7, has been released and can be downloaded from
http://www.mysql.com/downloads/cluster/
where you will also find Quick Start guides to help you get your first
MySQL Cluster database up and running.
The release notes are available from:
http://dev.mysql.com/doc/relnotes/mysql-cluster/7.3/en/mysql
-cluster-news-5-6-21-ndb-7-3-7.html
MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.
More details can be found at
http://www.mysql.com/products/cluster/
Enjoy !
Changes in MySQL Cluster NDB 7.3.7 (5.6.21-ndb-7.3.7) (2014-10-17)
MySQL Cluster NDB 7.3.7 is a new release of MySQL Cluster, based
on MySQL Server 5.6 and including features from version 7.3 of the
NDB storage engine, as well as fixing a number of recently
discovered bugs in previous MySQL Cluster releases.
Obtaining MySQL Cluster NDB 7.3. MySQL Cluster NDB 7.3 source
code and binaries can be obtained from
http://dev.mysql.com/downloads/cluster/.
For an overview of changes made in MySQL Cluster NDB 7.3, see
MySQL Cluster Development in MySQL Cluster NDB 7.3
(http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-development-
<http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-development-5-6-ndb-7-3.html>
5-6-ndb-7-3.html
<http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-development-5-6-ndb-7-3.html>).
This release also 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.6 through
MySQL 5.6.21 (see Changes in MySQL 5.6.21 (2014-09-23)
(http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-21.html)).
Bundled SSL Update (Commercial Releases)
* Starting with this release, commercial distributions of MySQL
Cluster NDB 7.3 are built using OpenSSL 1.0.1i.
Functionality Added or Changed
* After adding new data nodes to the configuration file of a
MySQL Cluster having many API nodes, but prior to starting any
of the data node processes, API nodes tried to connect to
these "missing" data nodes several times per second, placing
extra loads on management nodes and the network. To reduce
unnecessary traffic caused in this way, it is now possible to
control the amount of time that an API node waits between
attempts to connect to data nodes which fail to respond; this
is implemented in two new API node configuration parameters
StartConnectBackoffMaxTime and ConnectBackoffMaxTime.
Time elapsed during node connection attempts is not taken into
account when applying these parameters, both of which are
given in milliseconds with approximately 100 ms resolution. As
long as the API node is not connected to any data nodes as
described previously, the value of the
StartConnectBackoffMaxTime parameter is applied; otherwise,
ConnectBackoffMaxTime is used.
In a MySQL Cluster with many unstarted data nodes, the values
of these parameters can be raised to circumvent connection
attempts to data nodes which have not yet begun to function in
the cluster, as well as moderate high traffic to management
nodes.
For more information about the behavior of these parameters,
see Defining SQL and Other API Nodes in a MySQL Cluster
(http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-api-defi
<http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-api-definition.html>
nition.html
<http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-api-definition.html>).
(Bug #17257842)
* Added the --exclude-missing-tables option for ndb_restore.
When enabled, the option causes tables present in the backup
but not in the target database to be ignored. (Bug #57566, Bug
#11764704)
Bugs Fixed
* When assembling error messages of the form Incorrect state for
node n state: node_state, written when the transporter failed
to connect, the node state was used in place of the node ID in
a number of instances, which resulted in errors of this type
for which the node state was reported incorrectly. (Bug
#19559313, Bug #73801)
* In some cases, transporter receive buffers were reset by one
thread while being read by another. This happened when a race
condition occurred between a thread receiving data and another
thread initiating disconnect of the transporter (disconnection
clears this buffer). Concurrency logic has now been
implemented to keep this race from taking place. (Bug
#19554279, Bug #73656)
* The failure of a data node could in some situations cause a
set of API nodes to fail as well due to the sending of a
CLOSE_COMREQ signal that was sometimes not completely
initialized. (Bug #19513967)
* A more detailed error report is printed in the event of a
critical failure in one of the NDB internal sendSignal*()
methods, prior to crashing the process, as was already
implemented for sendSignal(), but was missing from the more
specialized sendSignalNoRelease() method. Having a crash of
this type correctly reported can help with identifying
configuration hardware issues in some cases. (Bug #19414511)
References: See also Bug #19390895.
* ndb_restore failed to restore the cluster's metadata when
there were more than approximately 17 K data objects. (Bug
#19202654)
* Parallel transactions performing reads immediately preceding a
delete on the same tuple could cause the NDB kernel to crash.
This was more likely to occur when separate TC threads were
specified using the ThreadConfig configuration parameter. (Bug
#19031389)
* Attribute promotion between different TEXT types (any of
TINYTEXT, TEXT, MEDIUMTEXT, and LONGTEXT) by ndb_restore was
not handled properly in some cases. In addition, TEXT values
are now truncated according to the limits set by mysqld (for
example, values converted to TINYTEXT from another type are
truncated to 256 bytes). In the case of columns using a
multibyte character set, the value is truncated to the end of
the last well-formed character.
Also as a result of this fix, conversion to a TEXT column of
any size that uses a different character set from the original
is now disallowed. (Bug #18875137)
* The NDB optimized node recovery mechanism attempts to transfer
only relevant page changes to a starting node in order to
speed the recovery process; this is done by having the
starting node indicate the index of the last global checkpoint
(GCI) in which it participated, so that the node that was
already running copies only data for rows which have changed
since that GCI. Every row has a GCI metacolumn which
facilitates this; for a deleted row, the slot formerly stpring
this row's data contains a GCI value, and for deleted pages,
every row on the missing page is considered changed and thus
needs to be sent.
When these changes are received by the starting node, this
node performs a lookup for the page and index to determine
what they contain. This lookup could cause a real underlying
page to be mapped against the logical page ID, even when this
page contained no data.
One way in which this issue could manifest itself occurred
after cluster DataMemory usage approached maximum, and
deletion of many rows followed by a rolling restart of the
data nodes was performed with the expectation that this would
free memory, but in fact it was possible in this scenario for
memory not to be freed and in some cases for memory usage
actually to increase to its maximum.
This fix solves these issues by ensuring that a real physical
page is mapped to a logical ID during node recovery only when
this page contains actual data which needs to be stored. (Bug
#18683398, Bug #18731008)
* When a data node sent a MISSING_DATA signal due to a buffer
overflow and no event data had yet been sent for the current
epoch, the dummy event list created to handle this
inconsistency was not deleted after the information in the
dummy event list was transferred to the completed list. (Bug
#18410939)
* Incorrect calculation of the next autoincrement value
following a manual insertion towards the end of a cached range
could result in duplicate values sometimes being used. This
issue could manifest itself whne using certain combinations of
values for auto_increment_increment, auto_increment_offset,
and ndb_autoincrement_prefetch_sz.
This issue has been fixed by modifying this calculation to
ensure that the next value from the cache as computed by NDB
is of the form auto_increment_offset + (N *
auto_increment_increment. This avoids any rounding up by the
MySQL Server of the returned value, which could result in
duplicate entries when the rounded-up value fell outside the
range of values cached by NDB. (Bug #17893872)
* ndb_show_tables --help output contained misleading information
about the --database (-d) option. In addition, the long form
of the option (--database) did not work properly. (Bug
#17703874)
* Using the --help option with ndb_print_file caused the program
to segfault. (Bug #17069285)
* For multithreaded data nodes, some threads do communicate
often, with the result that very old signals can remain at the
top of the signal buffers. When performing a thread trace, the
signal dumper calculated the latest signal ID from what it
found in the signal buffers, which meant that these old
signals could be erroneously counted as the newest ones. Now
the signal ID counter is kept as part of the thread state, and
it is this value that is used when dumping signals for trace
files. (Bug #73842, Bug #19582807)
* Cluster Replication: The fix for Bug #18770469 in the MySQL
Server made changes in the transactional behavior of the
temporary conversion tables used when replicating between
tables with different schemas. These changes as implemented
are not compatible with NDB, and thus the fix for this bug has
been reverted in MySQL Cluster. (Bug #19692387)
References: See also Bug #19704825.
* Cluster API: The fix for Bug #16723708 stopped the
ndb_logevent_get_next() function from casting a log event's
ndb_mgm_event_category to an enum type, but this change
interfered with existing applications, and so the function's
original behavior is now reinstated. A new MGM API function
exhibiting the corrected behavior ndb_logevent_get_next2() has
been added in this release to take the place of the reverted
function, for use in applications that do not require backward
compatibility. In all other respects apart from this, the new
function is identical with its predecessor. (Bug #18354165)
* Cluster API: NDB API scans leaked Ndb_cluster_connection
objects after nextResult() was called when an operation
resulted in an error. This leak locked up the corresponding
connection objects in the DBTC kernel block until the
connection was closed. (Bug #17730825)
* ClusterJ: Retrieval of values from BLOB and TEXT columns by
ClusterJ column accessor methods was not handled correctly.
(Bug #18419468, Bug #19028487)
On Behalf of the MySQL Cluster and the Oracle/MySQL RE Team
Sreedhar S
MySQL Cluster is the distributed, shared-nothing variant of MySQL. This
storage engine provides:
- Real-time performance based on in-memory storage (with
checkpointing to disk)
- Read & write scalability through transparent auto-sharding
- 99.999% High Availability with no single point of failure and
on-line maintenance
- SQL and NoSQL API (including C++, Java, http, Memcached and
JavaScript/Node.js)
- Active-Active/Multi-Master geographic replication
MySQL Cluster 7.3.7, has been released and can be downloaded from
http://www.mysql.com/downloads/cluster/
where you will also find Quick Start guides to help you get your first
MySQL Cluster database up and running.
The release notes are available from:
http://dev.mysql.com/doc/relnotes/mysql-cluster/7.3/en/mysql
-cluster-news-5-6-21-ndb-7-3-7.html
MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.
More details can be found at
http://www.mysql.com/products/cluster/
Enjoy !
Changes in MySQL Cluster NDB 7.3.7 (5.6.21-ndb-7.3.7) (2014-10-17)
MySQL Cluster NDB 7.3.7 is a new release of MySQL Cluster, based
on MySQL Server 5.6 and including features from version 7.3 of the
NDB storage engine, as well as fixing a number of recently
discovered bugs in previous MySQL Cluster releases.
Obtaining MySQL Cluster NDB 7.3. MySQL Cluster NDB 7.3 source
code and binaries can be obtained from
http://dev.mysql.com/downloads/cluster/.
For an overview of changes made in MySQL Cluster NDB 7.3, see
MySQL Cluster Development in MySQL Cluster NDB 7.3
(http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-development-
<http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-development-5-6-ndb-7-3.html>
5-6-ndb-7-3.html
<http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-development-5-6-ndb-7-3.html>).
This release also 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.6 through
MySQL 5.6.21 (see Changes in MySQL 5.6.21 (2014-09-23)
(http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-21.html)).
Bundled SSL Update (Commercial Releases)
* Starting with this release, commercial distributions of MySQL
Cluster NDB 7.3 are built using OpenSSL 1.0.1i.
Functionality Added or Changed
* After adding new data nodes to the configuration file of a
MySQL Cluster having many API nodes, but prior to starting any
of the data node processes, API nodes tried to connect to
these "missing" data nodes several times per second, placing
extra loads on management nodes and the network. To reduce
unnecessary traffic caused in this way, it is now possible to
control the amount of time that an API node waits between
attempts to connect to data nodes which fail to respond; this
is implemented in two new API node configuration parameters
StartConnectBackoffMaxTime and ConnectBackoffMaxTime.
Time elapsed during node connection attempts is not taken into
account when applying these parameters, both of which are
given in milliseconds with approximately 100 ms resolution. As
long as the API node is not connected to any data nodes as
described previously, the value of the
StartConnectBackoffMaxTime parameter is applied; otherwise,
ConnectBackoffMaxTime is used.
In a MySQL Cluster with many unstarted data nodes, the values
of these parameters can be raised to circumvent connection
attempts to data nodes which have not yet begun to function in
the cluster, as well as moderate high traffic to management
nodes.
For more information about the behavior of these parameters,
see Defining SQL and Other API Nodes in a MySQL Cluster
(http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-api-defi
<http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-api-definition.html>
nition.html
<http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-api-definition.html>).
(Bug #17257842)
* Added the --exclude-missing-tables option for ndb_restore.
When enabled, the option causes tables present in the backup
but not in the target database to be ignored. (Bug #57566, Bug
#11764704)
Bugs Fixed
* When assembling error messages of the form Incorrect state for
node n state: node_state, written when the transporter failed
to connect, the node state was used in place of the node ID in
a number of instances, which resulted in errors of this type
for which the node state was reported incorrectly. (Bug
#19559313, Bug #73801)
* In some cases, transporter receive buffers were reset by one
thread while being read by another. This happened when a race
condition occurred between a thread receiving data and another
thread initiating disconnect of the transporter (disconnection
clears this buffer). Concurrency logic has now been
implemented to keep this race from taking place. (Bug
#19554279, Bug #73656)
* The failure of a data node could in some situations cause a
set of API nodes to fail as well due to the sending of a
CLOSE_COMREQ signal that was sometimes not completely
initialized. (Bug #19513967)
* A more detailed error report is printed in the event of a
critical failure in one of the NDB internal sendSignal*()
methods, prior to crashing the process, as was already
implemented for sendSignal(), but was missing from the more
specialized sendSignalNoRelease() method. Having a crash of
this type correctly reported can help with identifying
configuration hardware issues in some cases. (Bug #19414511)
References: See also Bug #19390895.
* ndb_restore failed to restore the cluster's metadata when
there were more than approximately 17 K data objects. (Bug
#19202654)
* Parallel transactions performing reads immediately preceding a
delete on the same tuple could cause the NDB kernel to crash.
This was more likely to occur when separate TC threads were
specified using the ThreadConfig configuration parameter. (Bug
#19031389)
* Attribute promotion between different TEXT types (any of
TINYTEXT, TEXT, MEDIUMTEXT, and LONGTEXT) by ndb_restore was
not handled properly in some cases. In addition, TEXT values
are now truncated according to the limits set by mysqld (for
example, values converted to TINYTEXT from another type are
truncated to 256 bytes). In the case of columns using a
multibyte character set, the value is truncated to the end of
the last well-formed character.
Also as a result of this fix, conversion to a TEXT column of
any size that uses a different character set from the original
is now disallowed. (Bug #18875137)
* The NDB optimized node recovery mechanism attempts to transfer
only relevant page changes to a starting node in order to
speed the recovery process; this is done by having the
starting node indicate the index of the last global checkpoint
(GCI) in which it participated, so that the node that was
already running copies only data for rows which have changed
since that GCI. Every row has a GCI metacolumn which
facilitates this; for a deleted row, the slot formerly stpring
this row's data contains a GCI value, and for deleted pages,
every row on the missing page is considered changed and thus
needs to be sent.
When these changes are received by the starting node, this
node performs a lookup for the page and index to determine
what they contain. This lookup could cause a real underlying
page to be mapped against the logical page ID, even when this
page contained no data.
One way in which this issue could manifest itself occurred
after cluster DataMemory usage approached maximum, and
deletion of many rows followed by a rolling restart of the
data nodes was performed with the expectation that this would
free memory, but in fact it was possible in this scenario for
memory not to be freed and in some cases for memory usage
actually to increase to its maximum.
This fix solves these issues by ensuring that a real physical
page is mapped to a logical ID during node recovery only when
this page contains actual data which needs to be stored. (Bug
#18683398, Bug #18731008)
* When a data node sent a MISSING_DATA signal due to a buffer
overflow and no event data had yet been sent for the current
epoch, the dummy event list created to handle this
inconsistency was not deleted after the information in the
dummy event list was transferred to the completed list. (Bug
#18410939)
* Incorrect calculation of the next autoincrement value
following a manual insertion towards the end of a cached range
could result in duplicate values sometimes being used. This
issue could manifest itself whne using certain combinations of
values for auto_increment_increment, auto_increment_offset,
and ndb_autoincrement_prefetch_sz.
This issue has been fixed by modifying this calculation to
ensure that the next value from the cache as computed by NDB
is of the form auto_increment_offset + (N *
auto_increment_increment. This avoids any rounding up by the
MySQL Server of the returned value, which could result in
duplicate entries when the rounded-up value fell outside the
range of values cached by NDB. (Bug #17893872)
* ndb_show_tables --help output contained misleading information
about the --database (-d) option. In addition, the long form
of the option (--database) did not work properly. (Bug
#17703874)
* Using the --help option with ndb_print_file caused the program
to segfault. (Bug #17069285)
* For multithreaded data nodes, some threads do communicate
often, with the result that very old signals can remain at the
top of the signal buffers. When performing a thread trace, the
signal dumper calculated the latest signal ID from what it
found in the signal buffers, which meant that these old
signals could be erroneously counted as the newest ones. Now
the signal ID counter is kept as part of the thread state, and
it is this value that is used when dumping signals for trace
files. (Bug #73842, Bug #19582807)
* Cluster Replication: The fix for Bug #18770469 in the MySQL
Server made changes in the transactional behavior of the
temporary conversion tables used when replicating between
tables with different schemas. These changes as implemented
are not compatible with NDB, and thus the fix for this bug has
been reverted in MySQL Cluster. (Bug #19692387)
References: See also Bug #19704825.
* Cluster API: The fix for Bug #16723708 stopped the
ndb_logevent_get_next() function from casting a log event's
ndb_mgm_event_category to an enum type, but this change
interfered with existing applications, and so the function's
original behavior is now reinstated. A new MGM API function
exhibiting the corrected behavior ndb_logevent_get_next2() has
been added in this release to take the place of the reverted
function, for use in applications that do not require backward
compatibility. In all other respects apart from this, the new
function is identical with its predecessor. (Bug #18354165)
* Cluster API: NDB API scans leaked Ndb_cluster_connection
objects after nextResult() was called when an operation
resulted in an error. This leak locked up the corresponding
connection objects in the DBTC kernel block until the
connection was closed. (Bug #17730825)
* ClusterJ: Retrieval of values from BLOB and TEXT columns by
ClusterJ column accessor methods was not handled correctly.
(Bug #18419468, Bug #19028487)
On Behalf of the MySQL Cluster and the Oracle/MySQL RE Team
Sreedhar S