MySQL Cluster Manager 1.3 Release Notes  /  Changes in MySQL Cluster Manager 1.3.1 (2014-04-30)

Changes in MySQL Cluster Manager 1.3.1 (2014-04-30)

This section documents all changes and bug fixes that have been applied in MySQL Cluster Manager 1.3.1 since the release of MySQL Cluster Manager version 1.3.0.

Functionality Added or Changed

  • Important Change; Client: Added the import config command. This command simplifies the process of importing a previously autonomous MySQL Cluster into MySQL Cluster Manager by importing automatically most of the cluster's configuration data into the cluster definition that has been created as part of the import process, eliminating the need for reading of configuration files and SHOW VARIABLES output and issuing of most set commands needed to prepare a cluster for import.

    This command also supports a --dryrun option (short form: -y) for testing purposes.

    You should note that any nonstandard ports used by ndb_mgmd or mysqld processes in the existing MySQL Cluster must be configured manually (using set) for the corresponding processes in the target cluster before trying to use import cluster to import the wild cluster's data.

    For more information, see The import config Command, and Importing MySQL Clusters into MySQL Cluster Manager.

  • Client: The --import option for create cluster now enables assignment of node ID values less than 49 for ndb_mgmd, mysqld, and ndbapi processes. The create cluster command used without this option continues to enforce the rule that processes that are not data node processes must have node IDs greater than 48. (Bug #18181039)

Bugs Fixed

  • Agent: When executing backup cluster --waitstarted and abort backup in succession, it was possible in some circumstances for the agent to use the wrong backup ID internally. (Bug #18027413)

  • Client: After performing an initial start of a cluster, the cluster is no longer aware of any backup IDs that have previously been used. If you take a new backup of the cluster afterwards without specifying a backup ID, the cluster tries to use 1 as the ID for the first such backup, even if you restored the cluster from a backup having 1 as its ID, which results in an error. This is expected behavior, for which there are at least 2 workarounds:

    1. Move or rename the backup files following the restoration.

    2. Execute the backup cluster command using the --backupid option, to specify a backup ID that is not already in use.

    Issues arose in such cases because the error message returned was not sufficiently descriptive, and it could be difficult to determine the true nature of the problem without reading the management server and cluster log files. Now the error message returned by the mcm client makes it clear that the backup failed due to collision with an existing backup ID. (Bug #18465705)

  • Client: Executing the create site command using the names of one more hosts on which the MySQL Cluster Manager Agent was not running returned ERROR 1002 (00MGR): Agent on host <UNKNOWN>: (delivery status does not match current view) is unavailable. Now in such cases, the name of each host lacking an agent is included as part of the error message. (Bug #18200900)

  • Client: Attempting to set any of the mysqld configuration attributes relating to the thread pool plugin (see Thread Pool Installation)—including thread_pool_algorithm, thread_pool_high_priority_connection, thread_pool_max_unused_threads, thread_pool_prio_kickup_timer, thread_pool_size, and thread_pool_stall_limit—failed with the error No such configuration parameter ... for process mysqld. (Bug #18127968)