Dear MySQL Users,
MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:
- In-memory persistent storage - Real-time performance
- 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.9, 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.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.
More details can be found at
http://www.mysql.com/products/cluster/
Enjoy !
Changes in MySQL Cluster NDB 7.4.9 (5.6.28-ndb-7.4.9) (2016-01-18 )
MySQL Cluster NDB 7.4.9 is a new release of MySQL Cluster
7.4, based on MySQL Server 5.6 and including features in
version 7.4 of the NDB storage engine, as well as fixing
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.htm l).
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.28 (see Changes in MySQL 5.6.28
(2015-12-07)
(http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-28.html)).
Functionality Added or Changed
* Important Change: Previously, the NDB scheduler always
optimized for speed against throughput in a predetermined
manner (this was hard coded); this balance can now be set
using the SchedulerResponsiveness data node configuration
parameter. This parameter accepts an integer in the range
of 0-10 inclusive, with 5 as the default. Higher values
provide better response times relative to throughput.
Lower values provide increased throughput, but impose
longer response times. (Bug #78531, Bug #21889312)
* Added the tc_time_track_stats table to the ndbinfo
information database. This table provides time-tracking
information relating to transactions, key operations, and
scan operations performed by NDB. (Bug #78533, Bug
#21889652)
* Cluster Replication: Normally, RESET SLAVE causes all
entries to be deleted from the mysql.ndb_apply_status
table. This release adds the ndb_clear_apply_status
system variable, which makes it possible to override this
behavior. This variable is ON by default; setting it to
OFF keeps RESET SLAVE from purging the ndb_apply_status
table. (Bug #12630403)
Bugs Fixed
* Important Change: Users can now set the number and length
of connection timeouts allowed by most NDB programs with
the --connect-retries and --connect-retry-delay command
line options introduced for the programs in this release.
For ndb_mgm, --connect-retries supersedes the existing
--try-reconnect option. (Bug #57576, Bug #11764714)
* When executing a schema operation such as CREATE TABLE on
a MySQL Cluster with multiple SQL nodes, it was possible
for the SQL node on which the operation was performed to
time out while waiting for an acknowledgement from the
others. This could occur when different SQL nodes had
different settings for --ndb-log-updated-only,
--ndb-log-update-as-write, or other mysqld options
effecting binary logging by NDB.
This happened due to the fact that, in order to
distribute schema changes between them, all SQL nodes
subscribe to changes in the ndb_schema system table, and
that all SQL nodes are made aware of each others
subscriptions by subscribing to TE_SUBSCRIBE and
TE_UNSUBSCRIBE events. The names of events to subscribe
to are constructed from the table names, adding REPL$ or
REPLF$ as a prefix. REPLF$ is used when full binary
logging is specified for the table. The issue described
previously arose because different values for the options
mentioned could lead to different events being subscribed
to by different SQL nodes, meaning that all SQL nodes
were not necessarily aware of each other, so that the
code that handled waiting for schema distribution to
complete did not work as designed.
