Dear MySQL Users,
MySQL Cluster 7.4.2 (Milestone Release) is a public milestone
release for MySQL Cluster 7.4.
MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:
- In-Memory storage - Real-time performance (with optional
checkpointing to disk)
- Transparent Auto-Sharding - Read & write scalability
- Active-Active/Multi-Master geographic replication
- 99.999% High Availability with no single point of failure
and on-line maintenance
- NoSQL and SQL APIs (including C++, Java, http, Memcached
and JavaScript/Node.js)
MySQL Cluster 7.4 makes significant advances in performance;
operational efficiency (such as enhanced reporting and faster restarts
and upgrades) and conflict detection and resolution for active-active
replication between MySQL Clusters.
MySQL Cluster 7.4.2 DMR can be downloaded from the "Development
Releases" tab at
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.4/en/index.html
MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.
As with any other pre-production release, caution should be taken when
installing on production level systems or systems with critical data.
More information on the Development Milestone Release process can be
found at
http://dev.mysql.com/doc/mysql-development-cycle/en/development-milestone-releases.html
More details can be found at
http://www.mysql.com/products/cluster/
Enjoy !
==============================================================================
Changes in MySQL Cluster NDB 7.4.2 (5.6.21-ndb-7.4.2 2014-11-05)
MySQL Cluster NDB 7.4.2 is a new release of MySQL Cluster,
based on MySQL Server 5.6 and including features under
development for version 7.4 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.4. MySQL Cluster NDB 7.4
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.4, see
MySQL Cluster Development in MySQL Cluster NDB 7.4
(http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-development-5-6-ndb-7-4.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).
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-definition.html).
(Bug#17257842)
Bugs Fixed
* Online downgrades to MySQL Cluster NDB 7.3 failed when a
MySQL Cluster NDB 7.4 master attempted to request a local
checkpoint with 32 fragments from a data node already
running NDB 7.3, which supports only 2 fragments for
LCPs. Now in such cases, the NDB 7.4 master determines
how many fragments the data node can handle before making
the request. (Bug#19600834)
* The server side of an NDB transporter disconnected an
incoming client connection very quickly during the
handshake phase if the node at the server end was not yet
ready to receive connections from the other node. This
led to problems when the client immediately attempted
once again to connect to the server socket, only to be
disconnected again, and so on in a repeating loop, until
it suceeded. Since each client connection attempt left
behind a socket in TIME_WAIT, the number of sockets in
TIME_WAIT increased rapidly, leading in turn to problems
with the node on the server side of the transporter.
Further analysis of the problem and code showed that the
root of the problem lay in the handshake portion of the
transporter connection protocol. To keep the issue
described previously from occurring, the node at the
server end now sends back a WAIT message instead of
disconnecting the socket when the node is not yet ready
to accept a handshake. This means that the client end
should no longer need to create a new socket for the next
retry, but can instead begin immediately with a new
handshake hello message. (Bug#17257842)
* Corrupted messages to data nodes sometimes went
undetected, causing a bad signal to be delivered to a
block which aborted the data node. This failure in
combination with disconnecting nodes could in turn cause
the entire cluster to shut down.
To keep this from happening, additional checks are now
made when unpacking signals received over TCP, including
checks for byte order, compression flag (which must not
be used), and the length of the next message in the
receive buffer (if there is one).
Whenever two consecutive unpacked messages fail the
checks just described, the current message is assumed to
be corrupted. In this case, the transporter is marked as
having bad data and no more unpacking of messages occurs
until the transporter is reconnected. In addition, an
entry is written to the cluster log containing the error
as well as a hex dump of the corrupted message.
(Bug#73843, Bug#19582925)
* During restore operations, an attribute's maximum length
was used when reading variable-length attributes from the
receive buffer instead of the attribute's actual length.
(Bug#73312, Bug#19236945)
* 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.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql
