Dear MySQL Users,

MySQL Cluster Manager 1.4.2 has been released and can be downloaded
from the My Oracle Support (MOS) website. It will also be available
on Oracle Software Delivery Cloud at http://edelivery.oracle.com with
the next monthly update

MySQL Cluster Manager is an optional component of the MySQL Cluster Carrier
Grade Edition, providing a command-line interface that automates common
management tasks, including the following online operations:
- Configuring and starting MySQL Cluster
- Upgrades
- Adding and removing cluster nodes
- Adding and removing site hosts
- Configuration changes
- Backup and restore

MySQL Cluster Manager is a commercial extension to the MySQL family of
products.
More details can be found at http://www.mysql.com/products/cluster/mcm/

A brief summary of changes in MySQL Cluster Manager version 1.4.2 is
listed below:

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

* 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: 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 the
start process --initial to rebuild the mysqld node's data
directory. (Bug #18415446)

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

* Agent: The show status command now reports progress when
the new --progress or --progressbar options is used.

Bugs Fixed

* 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 by
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 logs, 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 mcmd user is always
created on the SQL node despite a failure of the start
cluster command. (Bug #13436550)

On behalf of the Oracle MySQL RE Team,
-Sreedhar S & Hery Ramilison

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql