The following sections describe changes in the implementation of MySQL NDB Cluster in NDB Cluster 8.3.0, as compared to earlier release series. NDB Cluster 8.1 is available as an Innovation release for preview and testing of new features currently under development. For production, please use NDB 8.0; for more information, see MySQL NDB Cluster 8.0. NDB Cluster 7.6 and 7.5 are previous GA releases still supported in production; for information about NDB Cluster 7.6, see What is New in NDB Cluster 7.6. For similar information about NDB Cluster 7.5, see What 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.3 which are likely to be of interest are shown in the following list:
TLS for cluster node communications. NDB Cluster 8.3 and later provides support for network communications secured by Transport Layer Security (TLS) and Internet Public Key Infrastructure (PKI) to authenticate and encrypt connections between NDB nodes, and between the NDB management server and its clients; TLS is applied to the NDB Transporter Protocol, and to the NDB Management Protocol.
This feature uses TLS mutual authentication, in which a node's own certificate file contains the chain of trust which the node uses to validate the certificates of its peers. When TLS is enabled on the cluster, data and management nodes use TLS to perform the following tasks:
NDBclients and servers at the network level, preventing unprivileged access as a client or server
Encrypt data transfer, avoiding data eavesdropping, modification, and man-in-the-middle attacks
Connections that use the MySQL client protocol employ MySQL user authentication, and may use TLS (including optional mutual TLS) as described elsewhere in this Manual; see Section 8.3, “Using Encrypted Connections”, for more information.
NDBimplements a new tool ndb_sign_keys which can be used to create and manage CA, certificate files, and keys. You can generate a set of keys and certificates for all nodes in a cluster with a given configuration file using ndb_sign_keys
Using ndb_sign_keys, a node certificate can be bound to a particular hostname, made to expire on a given date, and be associated with a given node type, so that clients are distinct from servers, and management servers from data nodes. (Every NDB TLS certificate can be used for MGM client connections.) Private keys are created in place, so that copying of files containing private keys is minimized. Both private keys and certificates are labeled as either active or pending; ndb_sign_keys also provides help with rotating keys to allow for pending keys to replace active keys before the active keys expire.
Testing of node TLS connections can be done from the system shell using ndb_mgm client with
--test-tls, or within the ndb_mgm client using the
TLS INFOcommand. You can obtain information about certificates used by cluster nodes by checking the
To enforce a requirement for TLS, set the client option
my.cnfon each cluster host, then set
[mgm default]section of the cluster
config.inifile, and set
[ndbd default]section of the configuration file as well. Then perform a rolling restart of the cluster, restarting the management server with
Use of TLS connections is also supported in NDB Cluster API applications in NDB 8.3 and later. For information about MGM API support, see TLS Functions. The NDB API
get_tls_certificate_path()methods for setting up TLS connections by clients.
For more information, see Section 25.6.15, “TLS Link Encryption for NDB Cluster”, as well as Section 25.5.28, “ndb_sign_keys — Create, Sign, and Manage TLS Keys and Certificates for NDB Cluster”.
NDB API primary key updates. Previously, when using any other mechanism than
NdbRecordin an attempt to update a primary key value, the NDB API returned error 4202 Set value on tuple key attribute is not allowed, even setting a value identical to the existing one. In NDB 8.1, checking when performing updates by other means is now handed off to the data nodes, as it is already when using
NdbRecordto perform the update.
This means that you can now perform primary key updates using
NdbInterpretedCode::write_attr(), and other methods of
NdbInterpretedCodewhich set column values (including the
sub_val(), and so on). This also applies to the
Improved warnings. Made the following improvements in warning output:
The maximum time allowed without any progress is now also printed in addition to local checkpoint (LCP) elapsed time.
When an LCP reaches
WAIT_END_LCPstate, table IDs and fragment IDs are undefined and so no longer relevant; for this reason, we no longer attempt to print them at that point.
Removed duplicated information printed when the maximum limit was reached (the same information was shown as both warning and crash information).
In addition, we no longer print the message Validating excluded objects to the SQL node's error log every
ndb_metadata_check_interval(default 60) seconds when
log_error_verbosityis greater than or equal to 3 (INFO level), due ot the fact that such messages tended to flood the error log, making it difficult to examine, and using excess disk space, while not providing any additional benefit to the user.
Pushdown joins between queries featuring very large and possibly overlapping
NOT IN()lists are now handled in a correct and safe manner.
ndbclusterplugin log messages now use
SYSTEMas the log level and
NDBas the subsystem for logging. This means that informational messages from the
ndbclusterplugin are always printed; their verbosity can be controlled by using
Binary log injector memory allocation. In previous versions of NDB Cluster, when the
NDBbinary log injector was engaged in handling schema changes and tracking the state of the binary log, the choice of arena for allocation of memory for these purposes was forced by changing thread local pointers, thus attempting to try and catch all allocations performed during epoch processing. At the end of the epoch, those pointers were reset, arena memory was released, and the arena structures discarded; this released the memory, but also required setting it up again for the next epoch. The thread local pointer changes also introduced the risk of memory being allocated wrongly when activating functionality in different subsystems. MySQL NDB Cluster 8.3 makes the following improvements to this functionality:
Changes to thread local pointers are removed, and replaced by explicit arguments to provide the arena used for allocation during the epoch.
Re-use of the arena for next epoch, thus avoiding the need to set it up repeatedly.
These changes are internal only but should provide a noticeable improvememnt by saving on memory release and re-allocation over successive epochs.
MySQL Cluster Manager has an advanced command-line interface that can simplify many complex NDB Cluster management tasks. See MySQL Cluster Manager 8.3.0 User Manual, for more information.