This section documents all changes and bug fixes that have been applied in MySQL Cluster Manager 1.4.1 since the release of MySQL Cluster Manager version 1.4.0.
Microsoft Windows: A 64-bit Windows installer package for MySQL Cluster Manager is now available.
-
Agent: Quotes used in specifying an mcmd option were interpreted literally as parts of the option value. With this fix, mcmd now handles the quotes properly for the following options by stripping the quotes before interpreting the option values:
(Bug #24529142)
Agent: When an mcmd agent failed to shutdown a mysqld node, it kept on retrying until the process timed out, at which point the error code from mysqld was returned to the client. With this fix, the error is returned immediately after the first shutdown attempt has failed. (Bug #24418005)
Agent: After a
start process --addedcommand was executed, if ashow status --operationalcommand was then run, in theCommandcolumn of the output, the ID for only one of the added nodes was shown even if multiple nodes had been added and started. With this fix, nodeids are no longer shown in the command output in that case, to avoid any possible confusions. (Bug #24372861)Agent: The
restore clustercommand now supports a new option,--promote-attributes, which allows attributes to be promoted when MySQL Cluster Manager restores data from a backup. (Bug #24295481)Agent: The
collect logscommand now also collects trace files, to provide more information in the event of a cluster failure. (Bug #23746394)Agent: Information that is unrelated to debugging is no longer included into the agent log when
--log-levelis set todebug, but is included when--log-levelis set toinfo. (Bug #23716969)Agent: The capability for MySQL Cluster Manager to set the cluster parameter
ndbinfo_table_prefixhas been removed, as setting it might cause a timeout when mcmd tries to start a mysqld node. (Bug #23632067)Agent: The
import clustercommand now supports the import of cluster nodes that have been started with options specified on the command line using underscores (_) instead of dashes (-) in the option names (for example,--ndb_connectstringinstead of--ndb-connectstring). (Bug #23535372)Agent: The
--initialoption can now be used with thestart clustercommand for starting clusters in the “created” status. (Bug #23138442)Agent: The timer in mcmd is now monotonic, so interval measures are no longer affected by clock changes on the host. (Bug #22699245)
Agent: The version number for the mcmd agent and the name of the host it is running on are now always recorded in the agent log (
mcmd.log) at startups or log rotations, irrespective of the--log-levelsetting. (Bug #22616530)Agent: The
backup clustercommand now creates a logical backup for the metadata of the NDB tables in a MySQL Cluster, allowing more flexibility for cluster reconfiguration during a restore. See the description forbackup clusterfor more details. (Bug #21200829)Agent: The
--backupidoption can now be used with thelist backupscommand to specify the ID of the backup to be listed.Client: Execution of the .mcm file created by the
import config --dryruncommand failed when a relative file path was given for a file-path attribute to be imported for a mysqld node. The mcm client now accepts relative file paths for those attributes, except for thesocketvalue, and for any paths for a directory value (for example,plugin_dir). (Bug #18650848)Client: Creating a single-host site with
localhostas the argument for--hostsnow results in a site that cannot be scaled up by theadd hostscommand; a warning for that is given by the mcm client at the creation of the site. See the description for thecreate sitecommand for details. (Bug #18389510)MySQL Cluster Manager now supports MySQL Cluster 7.5. At the same time, support for MySQL Cluster 7.2 has been deprecated. (Bug #24940329)
Agent: When the
backup agentscommand failed to copy some files, it finished without erroring out, but caused the subsequent mcmd agent restart to fail. This fix adds proper error-handling function to thebackup agentscommand. (Bug #25057056)Agent: When a
start clusterorstop clustercommand was run, if it took more than two minutes for any data node to be started or stopped, the mcmd agent threw a timeout for the command, and sometimes did that more than once, even though the data node was still in a normal process of being started or stopped. It was because the timeout extension needed was never granted within two minutes. With this fix, a timeout extension is granted at a much earlier time, and the amount of the extension is calculated based on the cluster'sDataMemorysize. (Bug #24749459)Agent: When mcmd failed to create the users it needs on a mysqld node, it just kept retrying until a timeout was reached, and without notifying the mcm client. With this fix, a failure is declared immediately to the client in the situation, and there are no more retries. (Bug #24511041)
Agent: After a failure by mcmd to configure a cluster, the progress message from the process caused the next attempt to configure the cluster to fail. With this fix, the progress message from the last attempt only causes a warning to be issued to the agent log, and is then ignored. (Bug #24499097)
Agent: After a failed execution of the
import configcommand using an older version of MySQL Cluster Manager, if MySQL Cluster Manager was then upgraded, restarting would fail afterward for some of the mcmd agents. (Bug #24464302)Agent: Attempts to upgrade MySQL Cluster Manager to version 1.4.0 by starting the 1.4.0 executables on pre-1.4 data failed, as the automatic upgrades for backup configurations were not successful. (Bug #24433400)
Agent: mcmd exited unexpectedly after failing to parse correctly a message of an unexpected format from a mysqld node. With this fix, sanity check is performed on the received message first, in order to avoid parsing the wrong information out of it. (Bug #24430610)
Agent: When attempting to set a global system variable on a mysqld node, the mcmd agent always returned a success message, even if it failed to contact the mysqld node actually. (Bug #24417856)
Agent: When running the
list backupscommand, if one of the mcmd agents ran into permission errors on some of the backups' file paths, the returned results for the command became incomplete. With this fix, complete results are returned in those situations. (Bug #24414682)Agent: When the mcm client and the mcmd agent it connected to were on the same host whose loopback address was not 127.0.0.1, if the host's name or loopback address was not explicitly contained in the host list in the
create sitecommand, attempts to restart the cluster later would fail with the complaint that the host name for the agent could not be resolved in the host list. With this fix, a warning is given in the situation when thecreate sitecommand is issued, asking the user to include the proper host name. (Bug #24411504)Agent: mcmd sometimes failed to report errors for its executions of SQL statements to the mcmd log. This fix tries to ensures that those errors are captured. (Bug #24375344)
Agent: When an
add packagecommand failed due to an error in loading the cluster configuration, mcmd exited unexpectedly on Windows platforms, and falsely reported that the package was added successfully on Unix-like platforms. (Bug #24361901)Agent: On Windows platforms, the value for the system variable
wait_timeoutfor mysqld nodes cannot be made larger than “2147483” using thesetcommand. (Bug #24332880)Agent: When mcmd failed to write to the configuration file
config.iniormy.cnf, mcmd either quit unexpectedly (for most Unix-like platforms), or returned a success message without actually writing to the file (on Solaris). (Bug #23632067)Agent: When a configuration parameter was imported from a mysqld node using the
import configcommand, the value got truncated when it was a quoted value containing a hash sign and was followed by a comment when listed inside the configuration file. (Bug #23591849)Agent: On Windows platforms, the
import clustercommand failed when a 32-bit mcmd was working a 64-bit MySQL Cluster, or vice versa. (Bug #23503256)Agent: The
import config --dryruncommand producedsetcommands of wrong syntax for instance-level TCP configuration settings specified inside theconfig.inifile. (Bug #23341146)Agent: When
NoOfReplicaswas “4” for a cluster and only one forth of all the data nodes were available,mcmdreported that the cluster was “non-operational” when theshow status --clustercommand was run. (Bug #23330032)Agent: mcmd ignored status update from an ndbapi (or unmanaged mysqld) node when it reported an LSN lower than one already reported by some other agent. This was due to an unnecessary check on the reported LSNs, which has been removed by this fix. (Bug #23320387)
Agent: When working with MySQL Cluster 7.5, resetting the Datadir parameter for a mysqld node using a
resetcommand caused an error when the default data directory had contents inside. (Bug #23283577)Agent: If distributed privileges for mysqld nodes were used and the
rootpassword has been set on the cluster's mysqld nodes, after a new mysqld process was added, MySQL Cluster Manager failed to connect to it, asmcmdtried in vain to log on to the new mysqld node asrootwith an empty password. With this fix,mcmdthen attempts in that situation to log on to the node as the usermcmd. Also, even if therootaccount is not secured, when distributed privileges are used,mcmdnow attempts first to connect to a new mysqld node asmcmcdbefore it tries to create themcmduser on the new node. (Bug #23274982, Bug #81391)Agent: The command
start process --addedfailed with the error “Unable to create nodegroup ...” when the parameterNoOfReplicaswas set to “3” or “4.” (Bug #23257723)Agent: Some ndbmtd processes were being excluded from rolling restarts when the parameter
NoOfReplicaswas set to “3” or “4.” (Bug #23251630)Agent: With the parameter
NoOfReplicasset to “3” or “4,” even when there was still one mirror node left in a nodegroup for a ndbmtd process, thestop processcommand issued for the ndbmtd node was rejected by mcmd. (Bug #23250053)Agent: When a quorum of majority of mcmd agents no longer existed (due to, for example, a network failure), an mcmd agent reported wrong statuses of failed processes even when those processes were local to its own host and were accessible by the agent. (Bug #23222658)
Agent: When network connection to a host with a data node running was lost and then reestablished, the
show statuscommand reported falsely that the data node was running again even though it had actually stopped. This fix makes sure the current status of the data node is properly reflected. (Bug #23220981)Agent: When there was a failure in setting the value of the parameter
LogDestination, mcmd, when returning an error, also issued sometimes a warning that an earlier runtime error had been overwritten. This is now prevented by putting in proper checking and handling for any existing error as a new error is being thrown. (Bug #23211849)Agent: If a warning was returned by mcmd after it executed a
SET GLOBALstatement to a mysqld node, the same warning was issued to the agent log (mcmd.log) again and again each time a newSET GLOBALstatement was executed. (Bug #23211783)Agent: When the parameter
ArbitrationRankwas being set for a mysqld node, the data nodes and management nodes were not restarted, so they had no knowledge that the arbitration rank for the mysqld node has been changed. (Bug #23148368)Agent: In the case where there was only one ndb_mgmd node in a cluster, during a rolling restart, after the ndb_mgmd node was just restarted and a first data node was stopped, a second data node might fail before it got restarted, complaining that there was no arbitrator for the cluster. It was because the management node was still in the process of asserting itself as an arbitrator. With this fix, the restarting of data nodes only begin after they have all seen an arbitrator established. (Bug #23148061)
Agent: A new ndbd or ndbmtd node could not be added to a cluster if
BackupDataDirspecified a non-default location for cluster backups, and there were backups existing at that location. (Bug #23123364)Agent: When already existing nodes were added again to a cluster without being started and the cluster was stopped, a subsequent
start cluster --initialcommand failed. This was becausemcmdattempted to recreate the already existing node groups, which this fix prevents. (Bug #23024367)Agent: While the
my.cnfconfiguration files for added mysqld processes generated bymcmdused group suffixes for group titles in the files (for example[mysqld.50]), the mysqld nodes were started without using the--defaults-group-suffixoption, causing the generated configurations to be unread by the mysqld node. With this fix, the group suffixes are no longer used. (Bug #22931198)Agent: On Windows platforms, an
mcmdagent quit unexpectedly after it was unable to open a process handler to a PID. This fix makesmcmdable to handle the situation and not quit. (Bug #22886512)Agent: During the time when an
upgrade clustercommand is being performed, if a mysqld node that had not yet been upgraded failed somehow, it was mistakenly restarted with the newer instead of the older binary package. With this fix, the node is restarted with the original binary package it was running on. (Bug #22880634)Agent: Under some conditions, setting a configuration attribute for a cluster using the
setcommand mademcmdquit unexpectedly, as more than one thread in MySQL Cluster Manager tried to change the cluster configurations together within a very short period of time, with one thread running into a checksum error for the repository directory and causing the agent to quit. This fix adds error checks, retries, and also exponential backoffs to handle the situation, in order to allow proper execution of thesetcommand. (Bug #22865068)Agent: A
restore clustercommand failed because one of the management nodes in the cluster was in the “starting” status, which should not prevent a cluster from being restored. (Bug #22755257)Agent: When the
start process --addedcommand was used to start data nodes that were newly added, the command failed if there was an ndbapi node that was in the “connected” status, with the complaint that the ndbapi node was “already running.” (Bug #22726592)-
Agent: If an earlier attempt to stop a mysqld node failed and left the node in a status of “stopping,” a subsequent
stop clustercommand failed with a timeout. With this fix, thestop clustercommand actually reattempts twice the shutdown of the “stopping” process, and throws a proper error if the attempts fail. The timeout period for each attempt is also reduced to 5 seconds. (Bug #22682222, Bug #24735542)References: See also: Bug #19805950.
Agent: When performing a
create clustercommand for a large cluster with many processes, mcmd tried to resolve the host name and check the validity of the package name for every single process, which could take a long time and cause thecreate clustercommand to fail with a timeout. mcmd now avoids repeated lookups for the same host name or package name, so the timeouts are prevented. (Bug #22671177)Agent: When a backup was actually completed after an
abort backupcommand had just been issued through the mcmd agent, the agent failed to respond to the backup completion, resulting in a timeout for theabort backupcommand. With this fix, theabort backupcommand will error out under the situation. (Bug #22655696)Agent: When setting a value for the
log-errorattribute for a mysqld node using thesetcommand, mcmd failed to, as expected, append the extension.errto the supplied file name when it did not have an extension. (Bug #22588267)Agent: The mysql client hung as a
statuscommand was issued through it to a mysqld node, due to some communication packages remaining unhandled bymcmd. (Bug #22539167)Agent: The
autotune --dryruncommand did not write to the.mcmscript file the TCP connection attributes (for example,SendBufferMemoryandReceiveBufferMemory) it would set for the cluster when the--dryrunoption was not used. (Bug #22517603)Agent: With two clusters running separately on two different hosts in the same site, the
autotune --dryruncommand for a cluster failed with an internal error, complaining that a dump file [for the other cluster running on the other host] could not be opened because it did not exist on the host—which was to be expected. (Bug #22465053, Bug #79586)Agent: If a cluster log rotation happened while MySQL Cluster Manager was starting the cluster, an mcmd agent failure would occur. This fix makes sure log rotation is properly detected and handled by mcmd. (Bug #22296243)
Agent: For MySQL Cluster 7.4.8 and later, the
import configcommand imported the deprecatedPortNumberattribute under the [tcp] section of the cluster configuration file as “0.”. The attribute is now skipped during a configuration import. (Bug #22274785)Agent: A
create clustercommand failed with an error when one of the mcmd agents was down, even if that agent was not needed for the process. (Bug #22245706)Agent: When the utility mysql_install_db was run by the mcmd agent at the creation of a mysqld node, it was not run asynchronously, resulting sometimes in unnecessary delay for other mcmd processes. With this fix, the utility is now run asynchronously. (Bug #22238508)
Agent: After a new host has been added to a cluster without a package being added for it,
mcmdreturned an error message to anygetandsetcommand, saying that the parameter to be get or set did not exist. With this fix, a proper error message is returned. (Bug #21894353)Agent: On Windows platform, setting the
datadiroption for a mysqld node in the Windows file path format caused themcmdagent to stop unexpectedly after it failed to restart the mysqld node. It was due to a mishandling of the Windows format file path, which has now been fixed. (Bug #19209870)Agent: A rolling restart of the cluster performed by mcmd timed out while waiting for GCP and LCP takeover events to complete among the data nodes. With this fix, the timeout is avoided by having mcmd check for the status of the takeover events and wait until the involved data nodes are ready before trying to stop them. (Bug #14230789)
Client: Spaces in quoted option values for MySQL Cluster Manager were lost (for example, with “--prompt='mcm1.4.1> ',” the prompt for the mcm client became “mcm1.4.1>” [with no space at the end]). (Bug #24528495)
Client: When the mcm client was being started with the
--debugoption, if the mysql client could not be found at the expected location, the mcm client failed with a segmentation fault. (Bug #24522244)Client: The success messages returned by the
autotune --dryrunandimport config --dryruncommands referred users to the agent log file for the proposed settings to be applied to the cluster, but the settings were not actually in the file. The success messages now give the path to the.mcmscript file that contains the settings. (Bug #22280689)Client: After the mcmd agent on a certain host failed, the mcm client continued to report the statuses of the processes on the host to “running” while the mcmd agent log and the ndb_mgmd queries already showed their statuses to be “unknown.”. (Bug #22174415)