This section provides information about NDB Cluster software and table file compatibility between different NDB Cluster 8.0 releases with regard to performing upgrades and downgrades as well as compatibility matrices and notes. You are expected already to be familiar with installing and configuring an NDB Cluster prior to attempting an upgrade or downgrade. See Section 22.3, “Configuration of NDB Cluster”.
Only compatibility between MySQL versions with regard to
NDBCLUSTER is taken into account in
this section, and there are likely other issues to be
considered. As with any other MySQL software upgrade
or downgrade, you are strongly encouraged to review the relevant
portions of the MySQL Manual for the MySQL versions from which
and to which you intend to migrate, before attempting an upgrade
or downgrade of the NDB Cluster software. See
Section 2.11, “Upgrading MySQL”.
Known Issues. The following issues are known to occur when upgrading to or between NDB 8.0 releases:
Online downgrades from NDB 8.0.14 to previous releases are not supported. Tables created in NDB 8.0.14 are not backwards compatible with previous releases. This is due to a change in usage of the extra metadata property implemented by
NDBtables to provide full support for the MySQL data dictionary.
Distributed privileges shared between MySQL servers as implemented in prior release series (see Distributed Privileges Using Shared Grant Tables) are not supported in NDB Cluster 8.0. When started, the mysqld supplied with NDB 8.0.16 and later checks for the existence of any grant tables which use the
NDBstorage engine; if it finds any, it creates local copies (“shadow tables”) of these using
InnoDB. This is true for each MySQL server connected to NDB Cluster. After this has been performed on all MySQL servers acting as NDB Cluster SQL nodes, the
NDBgrant tables may be safely removed using the ndb_drop_table utility supplied with the NDB Cluster distribution, like this:
ndb_drop_table -d mysql user db columns_priv tables_priv proxies_priv procs_priv
It is safe to retain the
NDBgrant tables, but they are not used for access control and are effectively ignored.
For more information about the MySQL privileges system used in NDB 8.0, see Section 22.5.16, “Distributed MySQL Privileges with NDB_STORED_USER”, as well as Section 6.2.3, “Grant Tables”.
In NDB 8.0.18, the binary configuration file format has been enhanced to provide support for great numbers of nodes. The new format is not accessible to 8.0.17 and older nodes, although newer management servers can detect older nodes and communicate with them using the appropriate format.
Upgrades to NDB 8.0.18 or later from 8.0.17 and earlier should not be problematic in this regard. In the case of downgrades from NDB 8.0.18 or later to 8.0.17 or earlier, because older management servers cannot read the newer binary configuration file format, some manual intervention is required. When performing such a downgrade, it is necessary to remove any cached binary configuration files prior to starting the management using the older
NDBsoftware version, and to have the plaintext configuration file available for the management server to read. Alternatively, you can start the older management server using the
--initialoption (again, it is necessary to have the
config.iniavailable). If the cluster uses multiple management servers, one of these two things must be done for each management server binary.
Direct downgrades of clusters running more than 48 data nodes, or with data nodes using node IDs greater than 48, to NDB versions 8.0.17 and earlier from NDB 8.0.18 or later are not supported. It is necessary in such cases to reduce the number of data nodes, change the configurations for all data nodes such that they use node IDs less than or equal to 48, or both, as required not to exceed the old maximums.