Quantcast
Channel: MySQL Forums - Announcements
Viewing all articles
Browse latest Browse all 1041

MySQL Cluster 7.5.21 has been released (no replies)

$
0
0
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.21 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.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.21 (5.7.33-ndb-7.5.21) (2021-01-19, General Availability)

   MySQL NDB Cluster 7.5.21 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
   (https://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
   https://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
(https://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.33 (see Changes in MySQL 5.7.33 (2021-01-18, General Availability)
(https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-33.html)).

     * Deprecation and Removal Notes

     * Bugs Fixed

Deprecation and Removal Notes


     * NDB Client Programs: Effective with this release, the
       MySQL NDB Cluster Auto-Installer (ndb_setup.py) has been
       has been removed from the NDB Cluster binary and source
       distributions, and is no longer supported. (Bug
       #32084831)
       References: See also: Bug #31888835.

     * ndbmemcache: ndbmemcache, which was deprecated in the
       previous release of NDB Cluster, has now been removed
       from NDB Cluster, and is no longer supported. (Bug
       #32106576)

Bugs Fixed


     * NDB Replication: After issuing RESET SLAVE ALL
       (https://dev.mysql.com/doc/refman/5.7/en/reset-slave.html),
       NDB
       (https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
       failed to detect that the replica had restarted. (Bug
       #31515760)

     * While retrieving sorted results from a pushed-down join
       using ORDER BY with the index access method (and without
       filesort), an SQL node sometimes unexpectedly terminated.
       (Bug #32203548)

     * Logging of redo log initialization showed log part
       indexes rather than log part numbers. (Bug #32200635)

     * Using the maximum size of an index key supported by index
       statistics (3056 bytes) caused buffer issues in data
       nodes. (Bug #32094904)
       References: See also: Bug #25038373.

     * As with writing redo log records, when the file currently
       used for writing global checkpoint records becomes full,
       writing switches to the next file. This switch is not
       supposed to occur until the new file is actually ready to
       receive the records, but no check was made to ensure that
       this was the case. This could lead to an unplanned data
       node shutdown restoring data from a backup using
       ndb_restore. (Bug #31585833)

     * ndb_restore encountered intermittent errors while
       replaying backup logs which deleted blob values; this was
       due to deletion of blob parts when a main table row
       containing blob one or more values was deleted. This is
       fixed by modifying ndb_restore to use the asynchronous
       API for blob deletes, which does not trigger blob part
       deletes when a blob main table row is deleted (unlike the
       synchronous API), so that a delete log event for the main
       table deletes only the row from the main table. (Bug
       #31546136)

     * When a table creation schema transaction is prepared, the
       table is in TS_CREATING state, and is changed to
       TS_ACTIVE state when the schema transaction commits on
       the DBDIH
(https://dev.mysql.com/doc/ndb-internals/en/ndb-internals-kernel-blocks-dbdih.html)
       block. In the case where the node acting as DBDIH coordinator
       fails while the schema transaction is committing, another node
       starts taking over for the coordinator. The following actions are
       taken when handling this node failure:

          + DBDICT
(https://dev.mysql.com/doc/ndb-internals/en/ndb-internals-kernel-blocks-dbdict.html)
            rolls the table creation schema transaction forward and
            commits, resulting in the table involved changing to
            TS_ACTIVE state.

          + DBDIH starts removing the failed node from tables by
            moving active table replicas on the failed node from
            a list of stored fragment replicas to another list.

       These actions are performed asynchronously many times,
       and when interleaving may cause a race condition. As a
       result, the replica list in which the replica of a failed
       failed node resides becomes nondeterministic and may
       differ between the recovering node (that is, the new
       coordinator) and other DIH participant nodes. This
       difference violated a requirement for knowing which list
       the failed node's replicas can be found during the
       recovery of the failed node recovery on the other
       participants.
       To fix this, moving active table replicas now covers not
       only tables in TS_ACTIVE state, but those in TS_CREATING
       (prepared) state as well, since the prepared schema
       transaction is always rolled forward.
       In addition, the state of a table creation schema
       transaction which is being aborted is now changed from
       TS_CREATING or TS_IDLE to TS_DROPPING, to avoid any race
       condition there. (Bug #30521812)

On Behalf of MySQL Release Engineering Team,
Piotr Obrzut 

Viewing all articles
Browse latest Browse all 1041

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>