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 --added
command was executed, if ashow status --operational
command was then run, in theCommand
column 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 cluster
command 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 logs
command 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-level
is set todebug
, but is included when--log-level
is set toinfo
. (Bug #23716969)Agent: The capability for MySQL Cluster Manager to set the cluster parameter
ndbinfo_table_prefix
has been removed, as setting it might cause a timeout when mcmd tries to start a mysqld node. (Bug #23632067)Agent: The
import cluster
command 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_connectstring
instead of--ndb-connectstring
). (Bug #23535372)Agent: The
--initial
option can now be used with thestart cluster
command 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-level
setting. (Bug #22616530)Agent: The
backup cluster
command 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 cluster
for more details. (Bug #21200829)Agent: The
--backupid
option can now be used with thelist backups
command to specify the ID of the backup to be listed.Client: Execution of the .mcm file created by the
import config --dryrun
command 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 thesocket
value, and for any paths for a directory value (for example,plugin_dir
). (Bug #18650848)Client: Creating a single-host site with
localhost
as the argument for--hosts
now results in a site that cannot be scaled up by theadd hosts
command; a warning for that is given by the mcm client at the creation of the site. See the description for thecreate site
command 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 agents
command 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 agents
command. (Bug #25057056)Agent: When a
start cluster
orstop cluster
command 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'sDataMemory
size. (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 config
command 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 backups
command, 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 site
command, 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 site
command 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 package
command 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_timeout
for mysqld nodes cannot be made larger than “2147483” using theset
command. (Bug #24332880)Agent: When mcmd failed to write to the configuration file
config.ini
ormy.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 config
command, 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 cluster
command failed when a 32-bit mcmd was working a 64-bit MySQL Cluster, or vice versa. (Bug #23503256)Agent: The
import config --dryrun
command producedset
commands of wrong syntax for instance-level TCP configuration settings specified inside theconfig.ini
file. (Bug #23341146)Agent: When
NoOfReplicas
was “4” for a cluster and only one forth of all the data nodes were available,mcmd
reported that the cluster was “non-operational” when theshow status --cluster
command 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
reset
command caused an error when the default data directory had contents inside. (Bug #23283577)Agent: If distributed privileges for mysqld nodes were used and the
root
password has been set on the cluster's mysqld nodes, after a new mysqld process was added, MySQL Cluster Manager failed to connect to it, asmcmd
tried in vain to log on to the new mysqld node asroot
with an empty password. With this fix,mcmd
then attempts in that situation to log on to the node as the usermcmd
. Also, even if theroot
account is not secured, when distributed privileges are used,mcmd
now attempts first to connect to a new mysqld node asmcmcd
before it tries to create themcmd
user on the new node. (Bug #23274982, Bug #81391)Agent: The command
start process --added
failed with the error “Unable to create nodegroup ...” when the parameterNoOfReplicas
was set to “3” or “4.” (Bug #23257723)Agent: Some ndbmtd processes were being excluded from rolling restarts when the parameter
NoOfReplicas
was set to “3” or “4.” (Bug #23251630)Agent: With the parameter
NoOfReplicas
set to “3” or “4,” even when there was still one mirror node left in a nodegroup for a ndbmtd process, thestop process
command 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 status
command 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 GLOBAL
statement to a mysqld node, the same warning was issued to the agent log (mcmd.log
) again and again each time a newSET GLOBAL
statement was executed. (Bug #23211783)Agent: When the parameter
ArbitrationRank
was 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
BackupDataDir
specified 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 --initial
command failed. This was becausemcmd
attempted to recreate the already existing node groups, which this fix prevents. (Bug #23024367)Agent: While the
my.cnf
configuration files for added mysqld processes generated bymcmd
used group suffixes for group titles in the files (for example[mysqld.50]
), the mysqld nodes were started without using the--defaults-group-suffix
option, 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
mcmd
agent quit unexpectedly after it was unable to open a process handler to a PID. This fix makesmcmd
able to handle the situation and not quit. (Bug #22886512)Agent: During the time when an
upgrade cluster
command 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
set
command mademcmd
quit 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 theset
command. (Bug #22865068)Agent: A
restore cluster
command 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 --added
command 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 cluster
command failed with a timeout. With this fix, thestop cluster
command 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 cluster
command 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 cluster
command 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 backup
command had just been issued through the mcmd agent, the agent failed to respond to the backup completion, resulting in a timeout for theabort backup
command. With this fix, theabort backup
command will error out under the situation. (Bug #22655696)Agent: When setting a value for the
log-error
attribute for a mysqld node using theset
command, mcmd failed to, as expected, append the extension.err
to the supplied file name when it did not have an extension. (Bug #22588267)Agent: The mysql client hung as a
status
command was issued through it to a mysqld node, due to some communication packages remaining unhandled bymcmd
. (Bug #22539167)Agent: The
autotune --dryrun
command did not write to the.mcm
script file the TCP connection attributes (for example,SendBufferMemory
andReceiveBufferMemory
) it would set for the cluster when the--dryrun
option was not used. (Bug #22517603)Agent: With two clusters running separately on two different hosts in the same site, the
autotune --dryrun
command 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 config
command imported the deprecatedPortNumber
attribute 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 cluster
command 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,
mcmd
returned an error message to anyget
andset
command, 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
datadir
option for a mysqld node in the Windows file path format caused themcmd
agent 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
--debug
option, 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 --dryrun
andimport config --dryrun
commands 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.mcm
script 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)