Chapter 5 MySQL Cluster Manager Limitations and Known Issues

The limitations discussed in this section occur by intention or design in MySQL Cluster Manager 1.3.6. Some of these items may become obsolete in future versions; we will update this section accordingly if and as those changes come about.

change process command.  Currently, the change process command can be used only to exchange an ndbd process for an ndbmtd process, or the reverse. That is, in effect, it can be used only to switch a data node between a single-threaded process and a multi-threaded process. It cannot be used for changing a cluster node's type (for example, you cannot change a data node to an SQL node, management node, or NDB API application node).

Because of this restriction, and due to the fact that multi-threaded data nodes are not supported in MySQL Cluster NDB 6.3 and earlier, the change process command is useful only with clusters running MySQL Cluster NDB 7.0 or newer.

License keys and operating platforms.  License keys are not required to use MySQL Cluster Manager 1.3.6.

Concurrent client sessions unsupported.  Currently there is no negotation or arbitration between multiple mcm clients. While it is possible to use the client from multiple locations, we do not support concurrent client sessions. You should be careful always to allow a command issued in one mcm client session to finish executing before issuing a new command in a different client session. This is true especially when using the -B or --background option with mcm client commands; see Backgrounded commands and error handling.

IPv6 and host names (Windows).  When IPv6 support is enabled on Windows systems, host names other than localhost are resolved using IPv6. When an IPv6-enabled Windows system is used as a MySQL Cluster host under MySQL Cluster Manager, you must reference it using its IPv4 address. Otherwise, mcm will be unable to connect to the agent process on that host.

This applies to host names used with the MySQL Cluster Manager client commands create cluster, create site, add hosts, add package, delete package, stop agents, and add process.

No removal of hosts (for MySQL Cluster Manager 1.3.4 and earlier).  For MySQL Cluster Manager 1.3.4 and earlier, once a host is added to a management site using the add hosts command, it cannot be removed with MySQL Cluster Manager. For MySQL Cluster Manager 1.3.5 and later, a host can be removed from a site with the remove hosts command.

The limitations described in this section relate to functionality in the MySQL Server that is unsupported or reduced, or otherwise differs when using it with MySQL Cluster Manager.

Replication.  Replication is currently not directly supported by MySQL Cluster Manager. See Section 5.3, “MySQL Cluster Manager Limitations Relating to MySQL Cluster”, for more information.

Limited mysqld option modifier support.  MySQL Cluster Manager does not recognize the --loose, --maximum, --enable, and --disable prefixes for mysqld options used as MySQL Cluster Manager configuration attributes (for a description of these modifiers, see Program Option Modifiers). For example, the command set loose-skip-innodb:mysqld=true mycluster; fails with the error No such config variable loose-skip-innodb for process mysqld.

The --skip option modifier is supported in some but not all cases, so that commands such as set skip-innodb:mysqld=true mycluster; and set skip-grant-tables:mysqld=true mycluster; can be used with MySQL Cluster Manager, while set skip-column-names:mysqld=true mycluster; cannot. (Bug #48559, Bug #47779)

Visibility of MySQL Cluster Manager mysqld attributes and MySQL server variables.  Due in part to issues with mappings between my.cnf option names, mysqld command-line option names, and names of MySQL server variables, some MySQL server variables are not visible to MySQL Cluster Manager, or have different names. For example, the storage_engine server variable shown in the output of SHOW VARIABLES in the mysql client maps to the default-storage-engine configuration attribute used in the MySQL Cluster Manager get and set commands.

Dashes and underscores in MySQL option and variable names.  When using the mysql client or other MySQL client applications, many MySQL system options and variables can be named using either dashes or underscores in their names. For example, you can use either ndb_batch_size or ndb-batch-size with the MySQL Server, and the variable is set correctly. This is not the case in MySQL Cluster Manager, where only the forms using underscores are accepted as attribute names. For example, assuming that mycluster is a viable cluster, the command set ndb_batch_size:mysqld=65536 mycluster; works to set the size of ndb_batch_size on all mysqld processes in the cluster, but set ndb-batch-size:mysqld=65536 mycluster; fails.

Dependencies between MySQL Cluster Manager mysqld attributes and MySQL server variables.  MySQL Cluster Manager does not track dependencies between mysqld attributes (MySQL server options and variables). For example, MySQL Server 5.1 and earlier require, when the binlog_format attribute is set, that the log_bin attribute be used as well; if binlog_format is used without log_bin, mysqld fails to start (MySQL Server Bug #42928, fixed in MySQL 5.5 and MySQL Cluster NDB 7.2). If you do this using MySQL Cluster Manager, however, the MySQL Cluster Manager agent reports that the operation was started successfully, and from MySQL Cluster Manager's point of view, this is correct—MySQL Cluster Manager started the mysqld process with the indicated attribute settings, and it is up to the operator to verify that the result was the one expected. In such cases, it is a good idea to check the status of the mysqld process, perhaps using show status --operation, before continuing.

MySQL Cluster Manager mysqld attributes and MySQL user variables.  MySQL user variables are not accessible as MySQL Cluster Manager configuration attributes.

Default MySQL data directory.  Formerly, the default tmpdir for MySQL servers installed under MySQL Cluster Manager was datadir/tmp, which caused issues with the mysql client. This issue was resolved in MySQL Cluster Manager 1.2. MySQL Cluster Manager 1.3 (and later) uses tmp in the MySQL installation directory for this purpose.

This section describes limitations relating to MySQL Cluster functionality that is unsupported or curtailed by MySQL Cluster Manager 1.3.6.

MySQL Cluster Manager and replication.  MySQL Cluster Manager currently does not provide any explicit support for MySQL Cluster Replication. However, you should still be able to perform manual setup of replication of a MySQL Cluster that is managed by MySQL Cluster Manager.

Backup and restore operations.  MySQL Cluster Manager provides integrated backup and restore functionality. You can back up NDB databases and tables using the mcm client backup cluster command, and restore them using the restore cluster client command. MySQL Cluster Manager also supports restoration of distributed privileges.

You can also back up NDB databases and tables using the ndb_mgm client START BACKUP command, and restore them using the ndb_restore program (see ndb_restore — Restore an NDB Cluster Backup); however MySQL Cluster Manager is not aware of backups that it was not employed to create. Both of the programs just mentioned are supplied with the MySQL Cluster distribution; for more information, see Online Backup of NDB Cluster, and ndb_restore — Restore an NDB Cluster Backup.

Rolling restarts.  Currently, all cluster nodes must be running in order to perform a rolling restart using MySQL Cluster Manager. However, MySQL Cluster itself requires only that at least one management server and all data nodes are running (in other words, any mysqld processes and any additional ndb_mgmd processes can be stopped). In such cases, you can perform the rolling restart manually, after stopping the MySQL Cluster Manager agent.

When making changes in configuration attributes only those nodes requiring a restart to make the change take effect are actually restarted. ndbapi nodes are never restarted by MySQL Cluster Manager.

Cluster Imports.  MySQL Cluster Manager will reject an import if it cannot access the process information of the cluster being imported. Therefore, the MySQL Cluster Manager agents must be run by a sufficiently privileged user—normally the same user that runs the cluster.

This section covers MySQL Cluster Manager issues relating to limitations in SQL and other syntax.

Backgrounded commands and error handling.  MySQL Cluster Manager client commands which are run in the background (that is, when they are invoked with the --background or -B option) do not issue any error messages in the client. If you run a command in the background, you must check the agent log or use the show status command to verify whether the backgrounded command was successful.