Dear MySQL Users,
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.5.11, 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.
MySQL Cluster 7.5 is also available from our repository for Linux
platforms, go here for details:
http://dev.mysql.com/downloads/repo/
The release notes are available from
http://dev.mysql.com/doc/relnotes/mysql-cluster/7.5/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 NDB Cluster 7.5.11 (5.7.23-ndb-7.5.11) (2018-07-27,
General Availability)
MySQL NDB Cluster 7.5.11 is a new release of MySQL NDB
Cluster 7.5, based on MySQL Server 5.7 and including features
in version 7.5 of the NDB
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
storage engine, as well as fixing recently discovered bugs in
previous NDB Cluster releases.
Obtaining MySQL NDB Cluster 7.5. MySQL NDB Cluster 7.5
source code and binaries can be obtained from
http://dev.mysql.com/downloads/cluster/.
For an overview of changes made in MySQL NDB Cluster 7.5, see
What is New in NDB Cluster 7.5
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is-new-7-5.html).
This release also incorporates all bug fixes and changes made
in previous NDB Cluster releases, as well as all bug fixes
and feature changes which were added in mainline MySQL 5.7
through MySQL 5.7.23 (see Changes in MySQL 5.7.23 (2018-07-27,
General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-23.html)).
Bugs Fixed
* ndbinfo Information Database: It was possible following a
restart for (sometimes incomplete) fallback data to be
used in populating the ndbinfo.processes
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndbinfo-processes.html)
table, which could lead to rows in
this table with empty process_name values. Such fallback
data is no longer used for this purpose. (Bug #27985339)
* MySQL NDB ClusterJ: ClusterJ could not be built from
source using JDK 9. (Bug #27977985)
* NDB attempted to drop subscriptions which had already
been dropped, leading to a data node shutdown with Error
2341. (Bug #27622643)
* An NDB
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
online backup consists of data, which is fuzzy, and a
redo and undo log. To restore to a consistent state it is
necessary to ensure that the log contains all of the
changes spanning the capture of the fuzzy data portion
and beyond to a consistent snapshot point. This is
achieved by waiting for a GCI boundary to be passed after
the capture of data is complete, but before stopping
change logging and recording the stop GCI in the backup's
metadata.
At restore time, the log is replayed up to the stop GCI,
restoring the system to the state it had at the
consistent stop GCI. A problem arose when, under load, it
was possible to select a GCI boundary which occurred too
early and did not span all the data captured. This could
lead to inconsistencies when restoring the backup; these
could be be noticed as broken constraints or corrupted
BLOB (http://dev.mysql.com/doc/refman/5.7/en/blob.html)
entries.
Now the stop GCI is chosen is so that it spans the entire
duration of the fuzzy data capture process, so that the
backup log always contains all data within a given stop
GCI. (Bug #27497461)
References: See also: Bug #27566346.
* For NDB tables, when a foreign key was added or dropped
as a part of a DDL statement, the foreign key metatdata
for all parent tables referenced should be reloaded in
the handler on all SQL nodes connected to the cluster,
but this was done only on the mysqld on which the
statement was executed. Due to this, any subsequent
queries relying on foreign key metadata from the
corresponding parent tables could return inconsistent
results. (Bug #27439587)
References: See also: Bug #82989, Bug #24666177.
* The internal function BitmaskImpl::setRange() set one bit
fewer than specified. (Bug #90648, Bug #27931995)
* It was not possible to create an NDB
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
table using PARTITION_BALANCE set to
FOR_RA_BY_LDM_X_2, FOR_RA_BY_LDM_X_3, or
FOR_RA_BY_LDM_X_4. (Bug #89811, Bug #27602352)
References: This issue is a regression of: Bug #81759,
Bug #23544301.
* When the internal function
ha_ndbcluster::copy_fk_for_offline_alter() checked
dependent objects on a table from which it was supposed
to drop a foreign key, it did not perform any filtering
for foreign keys, making it possible for it to attempt
retrieval of an index or trigger instead, leading to a
spurious Error 723 (No such table).
* During the execution of CREATE TABLE ... IF NOT EXISTS
(http://dev.mysql.com/doc/refman/5.7/en/create-table.html),
the internal open_table() function calls
ha_ndbcluster::get_default_num_partitions() implicitly
whenever open_table() finds out that the requested table
already exists. In certain cases,
get_default_num_partitions() was called without the
associated thd_ndb object being initialized, leading to
failure of the statement with MySQL error 157 Could not
connect to storage engine. Now
get_default_num_partitions() always checks for the
existence of this thd_ndb object, and initializes it if
necessary.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql