MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Hery Ramilison Date:March 7 2017 3:10am
Subject:MySQL Cluster Manager 1.4.2 has been released
View as plain text  
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
Thread
MySQL Cluster Manager 1.4.2 has been releasedHery Ramilison7 Mar