MySQL Forums
Forum List  »  Announcements

MySQL Cluster Manager 1.4.2 has been released
Posted by: Jocelyn Ramilison
Date: March 06, 2017 09:10PM

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

Options: ReplyQuote


Subject
Views
Written By
Posted
MySQL Cluster Manager 1.4.2 has been released
2433
March 06, 2017 09:10PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.