3. Stop, reconfigure, then restart each cluster SQL node ( mysqld  process) in turn. 

NDB Cluster supports a somewhat flexible order for upgrading nodes. When upgrading an NDB Cluster, you may upgrade API nodes (including SQL nodes) before upgrading the management nodes, data nodes, or both. In other words, you are permitted to upgrade the API and SQL nodes in any order. This is subject to the following provisions: 

•This functionality is intended for use as part of an online upgrade only. A mix of node binaries from different NDB Cluster releases is neither intended nor supported for continuous, long-term use in a production setting. 

•All management nodes must be upgraded before any data nodes are upgraded. This remains true regardless of the order in which you upgrade the cluster’s API and SQL nodes. 

•Features specific to the “new”  version must not be used until all management nodes and data nodes have been upgraded. 

This also applies to any MySQL Server version change that may apply, in addition to the NDB engine version change, so do not forget to take this into account when planning the upgrade. (This is true for online upgrades of NDB Cluster in general.) 

It is not possible for any API node to perform schema operations (such as data definition statements) during a node restart. Due in part to this limitation, schema operations are also not supported during an online upgrade or downgrade. 

Rolling restarts with multiple management servers. When performing a rolling restart of an NDB Cluster with multiple management nodes, you should keep in mind that ndb_mgmd  checks to see if any other management node is running, and, if so, tries to use that node’s configuration data. To keep this from occurring, and to force ndb_mgmd  to re-read its configuration file, perform the following steps: 

1. Stop all NDB Cluster ndb_mgmd  processes. 

2. Update all config.ini  files. 

3. Start a single ndb_mgmd  with --reload , --initial , or both options as desired. 

4. If you started the first ndb_mgmd  with the --initial  option, you must also start any remaining ndb_mgmd  processes using --initial . 

Regardless of any other options used when starting the first ndb_mgmd , you should not start any remaining ndb_mgmd  processes after the first one using --reload . 

5. Complete the rolling restarts of the data nodes and API nodes as normal. 

When performing a rolling restart to update the cluster’s configuration, you can use the config_generation  column of the ndbinfo.nodes  table to keep track of which data nodes have been successfully restarted with the new configuration. See Section 23.5.14.38, “The ndbinfo nodes Table” . 

## 23.5.6 NDB Cluster Single User Mode 

Single user mode  enables the database administrator to restrict access to the database system to a single API node, such as a MySQL server (SQL node) or an instance of ndb_restore . When entering single user mode, connections to all other API nodes are closed gracefully and all running transactions are aborted. No new transactions are permitted to start. 

Once the cluster has entered single user mode, only the designated API node is granted access to the database. 

