MySQL :: Details of the MySQL Cluster Manager 1.4.0 release

We just announced availability of MySQL Cluster Manager 1.4.0! In this post we’ll highlight some details of the MCM 1.4.0 release.

Based on MySQL 5.6

MySQL Cluster Manager is part of the commercial MySQL Cluster offering from Oracle. MCM 1.4.0 is now based on the tried and tested MySQL 5.6 release. Earlier releases of MCM were based on MySQL 5.5. Another noteworthy point is we have updated the version of glib to a more recent 2.44.

MySQL Cluster 7.4.8 bundled

As with any MCM release, we bundle the latest commercial MySQL Cluster release. For MCM 1.4.0 this was MySQL Cluster 7.4.8.

Retrying failed upgrades

Most importantly we’ve relaxed the criteria for when to allow a upgrade cluster command. There are also two new options available, –retry and –nodeid.
With –retry you can rerun an upgrade, even for completed nodes should you need to. Issuing “upgrade cluster –retry –package=x.y.z mycluster” will rerun the upgrade, for all nodes, from the beginning. Using the –nodeid option you can specify the list of nodes for which to retry the upgrade. This is useful in case an upgrade failed for whatever reason, such as a mysqld that did not start properly, or the mysql_upgrade script execution failed.

Wildcards on get command

With MCM 1.4.0 you can now use wildcards in the get command. There are lots of knobs and dials available in MySQL and MySQL Cluster, so you’re excused for not remembering or knowing the name of all of them.
The wildcards are perfect for the case when you can’t really remember the full name of the config attribute. Using the wildcard character ‘*’ (asterisk), you can match none, one, or more characters or patterns of the config attribute. Please note that the wildcards only apply for get, not for the set command.

Example 1: “It was something with max and indexes“:


mcm> get -d Max*Indexes:: mycluster;
+--------------------------+-------+----------+---------+----------+---------+---------+---------+
| Name                     | Value | Process1 | NodeId1 | Process2 | NodeId2 | Level   | Comment |
+--------------------------+-------+----------+---------+----------+---------+---------+---------+
| MaxNoOfIndexes           | 128   | ndbmtd   | 1       |          |         | Default |         |
| MaxNoOfOrderedIndexes    | 128   | ndbmtd   | 1       |          |         | Default |         |
| MaxNoOfUniqueHashIndexes | 64    | ndbmtd   | 1       |          |         | Default |         |
| MaxNoOfIndexes           | 128   | ndbmtd   | 2       |          |         | Default |         |
| MaxNoOfOrderedIndexes    | 128   | ndbmtd   | 2       |          |         | Default |         |
| MaxNoOfUniqueHashIndexes | 64    | ndbmtd   | 2       |          |         | Default |         |
+--------------------------+-------+----------+---------+----------+---------+---------+---------+
6 rows in set (0.11 sec)

1

2

3

4

5

6

7

8

9

10

11

12

13

14

mcm> get -d Max*Indexes:: mycluster;

+--------------------------+-------+----------+---------+----------+---------+---------+---------+

+--------------------------+-------+----------+---------+----------+---------+---------+---------+

+--------------------------+-------+----------+---------+----------+---------+---------+---------+

6 rows in set (0.11 sec)

Example 2: “It was something with wait and time”:


mcm> get -d *wait*time*:: mycluster;
+--------------------------+----------+----------+---------+----------+---------+---------+---------+
| Name                     | Value    | Process1 | NodeId1 | Process2 | NodeId2 | Level   | Comment |
+--------------------------+----------+----------+---------+----------+---------+---------+---------+
| innodb_lock_wait_timeout | 50       | mysqld   | 50      |          |         | Default |         |
| lock_wait_timeout        | 31536000 | mysqld   | 50      |          |         | Default |         |
| wait_timeout             | 28800    | mysqld   | 50      |          |         | Default |         |
| innodb_lock_wait_timeout | 50       | mysqld   | 51      |          |         | Default |         |
| lock_wait_timeout        | 31536000 | mysqld   | 51      |          |         | Default |         |
| wait_timeout             | 28800    | mysqld   | 51      |          |         | Default |         |
+--------------------------+----------+----------+---------+----------+---------+---------+---------+
6 rows in set (0.01 sec)

1

2

3

4

5

6

7

8

9

10

11

12

13

14

mcm> get -d *wait*time*:: mycluster;

+--------------------------+----------+----------+---------+----------+---------+---------+---------+

+--------------------------+----------+----------+---------+----------+---------+---------+---------+

+--------------------------+----------+----------+---------+----------+---------+---------+---------+

6 rows in set (0.01 sec)

Quite helpful, if we may!

Autotuning MySQL Cluster

MCM 1.4.0 has a new autotune command that will automatically tune certain cluster config attributes according to the selected use-case, writeload, and certain other existing settings.
The available tuning templates, and the tuning rules applied, are the same as in the MySQL Cluster auto-installer (MCC) that ships with MySQL Cluster. Further details and examples are available in the autotune doc entry.

Bugfixes

We’ve also fixed bugs in this release. For a more detailed list, please have a look at the

MCM 1.4.0 Release Notes.

Want to know more?

You can read more about MCM on the documentation page, and there is also a recently refreshed MCM whitepaper. MCM binaries are available for download from either My Oracle Support or eDelivery.