25.2.4 What is New in MySQL NDB Cluster 8.0 (original) (raw)

The following sections describe changes in the implementation of MySQL NDB Cluster in NDB Cluster 8.0 through 8.0.42, as compared to earlier release series. NDB Cluster 8.0 is available as a General Availability (GA) release, beginning with NDB 8.0.19. NDB Cluster 7.6 and 7.5 are previous GA releases still supported in production; for information about NDB Cluster 7.6, seeWhat is New in NDB Cluster 7.6. For similar information about NDB Cluster 7.5, seeWhat is New in NDB Cluster 7.5. NDB Cluster 7.4 and 7.3 were previous GA releases which have reached their end of life, and which are no longer supported or maintained. We recommend that new deployments for production use MySQL NDB Cluster 8.0.

Major changes and new features in NDB Cluster 8.0 which are likely to be of interest are shown in the following list:

GRANT NDB_STORED_USER ON *.* TO 'jon'@'localhost';

NDB_STORED_USER always has global scope and must be granted using ON *.*. System reserved accounts such asmysql.session@localhost ormysql.infoschema@localhost cannot be assigned this privilege.
Roles can also be shared between SQL nodes by issuing the appropriate GRANT NDB_STORED_USER statement. Assigning such a role to a user does not cause the user to be shared; the NDB_STORED_USER privilege must be granted to each user explicitly.
A user or role having NDB_STORED_USER, along with its privileges, is shared with all SQL nodes as soon as they join a given NDB Cluster. It is possible to make such changes from any connected SQL node, but recommended practice is to do so from a designated SQL node only, since the order of execution of statements affecting privileges from different SQL nodes cannot be guaranteed to be the same on all SQL nodes.
Prior to NDB 8.0.27, changes to the privileges of a user or role were synchronized immediately with all connected SQL nodes. Beginning with MySQL 8.0.27, an SQL node takes a global read lock when updating privileges, which keeps concurrent changes executed by multiple SQL nodes from causing a deadlock.
Implications for upgrades. Due to changes in the MySQL server's privilege system (see Section 8.2.3, “Grant Tables”), privilege tables using the NDB storage engine do not function correctly in NDB 8.0. It is safe but not necessary to retain such privilege tables created in NDB 7.6 or earlier, but they are no longer used for access control. In NDB 8.0, amysqld acting as an SQL node and detecting such tables in NDB writes a warning to the MySQL server log, and createsInnoDB shadow tables local to itself; such shadow tables are created on each MySQL server connected to the cluster. When performing an upgrade from NDB 7.6 or earlier, the privilege tables usingNDB can be removed safely usingndb_drop_table once all MySQL servers acting as SQL nodes have been upgraded (seeSection 25.3.7, “Upgrading and Downgrading NDB Cluster”).
The ndb_restore utility's--restore-privilege-tables option is deprecated but continues to be honored in NDB 8.0, and can still be used to restore distributed privilege tables present in a backup taken from a previous release of NDB Cluster to a cluster running NDB 8.0. These tables are handled as described in the preceding paragraph.
Shared users and grants are stored in thendb_sql_metadata table, whichndb_restore by default does not restore in NDB 8.0; you can specify the--include-stored-grants option to cause it to do so.
See Section 25.6.13, “Privilege Synchronization and NDB_STORED_USER”, for more information.

CREATE TABLE t (  
    x INT PRIMARY KEY,  
    y INT  
) ENGINE=NDB;

A query such as SELECT * FROM t AS m JOIN t AS n ON m.x >= n.y can now use the engine condition pushdown optimization to push down the condition column y.
When a join cannot be pushed,EXPLAIN should provide the reason or reasons.
See Section 10.2.1.5, “Engine Condition Pushdown Optimization”, for more information.
The NDB API methodsbranch_col_eq_param(),branch_col_ne_param(),branch_col_lt_param(),branch_col_le_param(),branch_col_gt_param(), andbranch_col_ge_param() were added in NDB 8.0.27 as part of this work. TheseNdbInterpretedCode can be used to compare column values with values of parameters.
In addition,NdbScanFilter::cmp_param(), also added in NDB 8.0.27, makes it possible to define comparisons between column values and parameter values for use in performing scans.

For conflicting update and delete operations,NDB$MAX_INS() behaves as[NDB$MAX()](mysql-cluster-replication-conflict-resolution.html#mysql-cluster-replication-ndb-max "NDB$MAX()") does, and NDB$MAX_DEL_WIN_INS() behaves in the same way as[NDB$MAX_DELETE_WIN()](mysql-cluster-replication-conflict-resolution.html#mysql-cluster-replication-ndb-max-delete-win "NDB$MAX_DELETE_WIN()").
This enhancement provides support for configuring conflict detection when handling conflicting replicated write operations, so that a replicatedINSERT with a higher timestamp column value is applied idempotently, while a replicatedINSERT with a lower timestamp column value is rejected.
As with the other conflict resolution functions, rejected operations can optionally be logged in an exceptions table; rejected operations increment a counter (status variablesNdb_conflict_fn_max for“greatest timestamp wins” andNdb_conflict_fn_old for“same timestamp wins”).
For more information, see the descriptions of the new conflict resolution functions, and as well asSection 25.7.12, “NDB Cluster Replication Conflict Resolution”.

MySQL Cluster Manager provides support for NDB Cluster 8.0. MySQL Cluster Manager has an advanced command-line interface that can simplify many complex NDB Cluster management tasks. See MySQL Cluster Manager 8.0.42 User Manual, for more information.