Changes in MySQL Cluster Manager 1.4.2 (2017-03-07)

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

• Functionality Added or Changed

• Bugs Fixed

Functionality Added or Changed

• Packaging: MySQL Cluster Manager is now also shipped in RPM packages for installation on Oracle Linux 7 and Red Hat Enterprise Linux 7. (Bug #25368708)

• Agent: To allow easy detection of an incomplete agent backup, an empty file named INCOMPLETE is created in the folder in which the backup is created when the backup agents command begins, and is deleted after the backup is finished. The continuous existence of the file after the backup process is over indicates that the backup is incomplete. (Bug #25126866)

• Agent: A new update process command updates a cluster process' status when it is no longer reflected correctly in the output of the show status --process. It imports the process into the control of the mcmd agent again. See description of the update process command for details. (Bug #25098588, WL #10337)

• Agent: MySQL Cluster Manager can now recover automatically a failed mysqld node, as long as the data directory of the node is empty when recovery is attempted; if that is not the case, after cleaning up the data directory manually, users can now manually run start process --initial to rebuild the mysqld node's data directory. (Bug #18415446)

• Agent: The show status command now reports progress when the new --progress or --progressbar option is used. (WL #9839)

• Agent: A new command, update process, imports a process back into the control of mcmd after it has lost track of the process's status due to different reasons (for example, it has been restarted manually outside of MySQL Cluster Manager). For more details, see the description for the command. (WL #10337)

Bugs Fixed

• Agent: mcmd sometimes quit unexpectedly when running on SLES 11.4 with ReiserFS due to sporadic occurrences of checksum errors with the MySQL Cluster Manager data repository. (Bug #25596300)

• Agent: When a custom FileSystemPath value was used for a data node, the list backups and restore cluster commands failed, as the backup directory could not be found. (Bug #25549903)

• Agent: In some situations, a certain mcmd agent took too long to process event messages that a synchronization timeout occurred among the agents. This was because the agent went into a mutex contention for file access, which this fix removes. (Bug #25462861)

• Agent: The collect logs command reported success even if file transfers were incomplete. This fix adds checks for file transfer completion and reports any errors. (Bug #25436057)

• Agent: An ndbmtd node sometimes (for example, at a rolling restart of the cluster) sent out a large amount of event messages, and it might take too long for an mcmd agent to process them that the agent lagged behind on its readiness for the next command, resulting in a synchronization timeout among the mcmd agents. This fix drastically reduced the amount of event messages sent out about an ndbmtd node, thus reducing the chance of a synchronization timeout under the situation. (Bug #25358050)

• Agent: A management node failure might trigger mcmd to quit unexpectedly on Windows platforms. (Bug #25336594)

• Agent: Multiple errors thrown by the backup agents, rotate log, and change log-level commands could potentially overwrite each other, causing a lost of error information. (Bug #25134452)

• Agent: The collect logs command hung when TCP connections could not be established between the agent that initiated the command and the other agents. This fix makes the command timeout after the situation persists for more than 30s. Also, a new mcmd option, --copy-port, has been added, by which users can specify the TCP port number to be used for log copying. (Bug #25064313)

• Agent: The .mcm file created by the import config --dryrun command sometimes have certain configuration settings missing from it. (Bug #24962848)

• Agent: A restore cluster command would fail if MySQL Cluster Manager did not have write access to the BackupDataDir of each data node. The unnecessary requirement has now been removed. (Bug #24763936)

• Agent: If a stop cluster or a stop process command had failed, a restart on some of the processes might fail with the complaint from mcmd that those processes were already stopped, even if they were actually running. That also made it impossible to reconfigure those processes when StopOnError was true. This happened because the failed stop command had left those processes' metadata in an incorrect state. With this fix, the process restart is allowed despite the value of StopOnError. (Bug #24712504)

• Agent: Hostnames referenced in the error messages returned by mcmd were always in lower case. With this fix, the hostname is always referred to as it is; moreover, mcmd now always refers to a hostname or the IP address used in creating the cluster. (Bug #21375132)

• Agent: A restore cluster command hung, when an mcmd agent failed and the other agents kept waiting to receive messages from it. With the fix, the other agents detect the failure and return an error to the user. (Bug #16907088)

• Agent: When a cluster was being started, if a data node failed shortly after it was started and mcmd was still in the process of starting an SQL node, even if the SQL node was started successfully at the end, mcmd might forever lose connection to the SQL node. It happened when the user mcmd required for the mcmd agent did not get created on the SQL node. With this fix, the user mcmd is always created on the SQL node despite a failure of the start cluster command. (Bug #13436550)