•In NDB 8.0, the default values changed for log_bin  (from 0 to 1) and ndb_log_bin  (from 1 to 0). This means that you must now explicitly set ndb_log_bin  to 1 to enable binary logging. 

•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 NDB  storage 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 NDB  grant 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 NDB  grant 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 23.5.12, “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 greater numbers of nodes than in previous versions. 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 NDB  software 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 --initial  option (again, it is necessary to have the config.ini  available). If the cluster uses multiple management servers, one of these two things must be done for each management server binary. 

Also in connection with support for increased numbers of nodes, due to incompatible changes implemented in NDB 8.0.18 in the data node LCP Sysfile , it is necessary, when performing an online downgrade from NDB 8.0.18 (or later) to any prior release, to restart all data nodes using the -- initial  option. 

Restarting the data nodes with --initial  is also required when upgrading any release prior to NDB 7.6.4 to any NDB 8.0 release. 

•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. 

•If you are downgrading from NDB 8.0 to NDB 7.5 or NDB 7.4, you must set an explicit value for IndexMemory  in the cluster configuration file if none is already present. This is because NDB 8.0 does not use this parameter (which was removed in NDB 7.6) and sets it to 0 by default, whereas it is required in NDB 7.5 and NDB 7.4, in both of which the cluster refuses to start with Invalid configuration received from Management Server...  if IndexMemory  is not set to a nonzero value. 

Setting IndexMemory  is not  required for downgrades from NDB 8.0 to NDB 7.6. 

