This command resets an attribute to its default value.
Attributes can be set on either the process level or instance
level. To reset an attribute on the process level, use a filter
specification having the form
attribute_name:process_name,
where attribute_name is the name of
the attribute to be reset, and
process_name is the name of a MySQL
Cluster process. To reset a configuration attribute on the
instance level, use a filter specification of the form
attribute_name:process_name:process_id,
where process_id is the process ID.

You cannot issue a reset command that resets
all values for a given configuration attribute regardless of
process type; each reset command must specify
a process type or instance of a process. Otherwise, the command
fails, as shown here:

mcm> reset DataMemory mycluster;ERROR 3 (00MGR): Illegal syntax

You also cannot revert all configuration attributes for a given
process type or instance of a process using a single filter
specification; you must always include the name of the attribute
to be reset. Otherwise, the reset command
fails, as shown here:

We can see from the entries in the Level
column that the
DataMemory setting for
both ndbd processes applies on the process
level. A process-level setting cannot be reset on the instance
level, as shown here:

The previous command fails because MySQL Cluster Manager regards this as an
attempt to apply two instance-level configuration changes.
Because the DataMemory
setting is a process-level setting, you must instead reset
DataMemory to its
default value on the process level; you can do this by using the
filter specification DataMemory:ndbd in the
reset command, as shown here:

If you execute the same get command as shown
previously, the result is now empty:

mcm> get DataMemory mycluster;
Empty set (0.74 sec)

This is because the get command
by default does not report default values. To retrieve the
DataMemory values after
resetting them, you must invoke get using the
--include-defaults (short form:
-d) option:

The DataMemory values
are now included in the output, and are marked with the word
Default in the Comments
column.

Now suppose that the mysqld configuration
attribute wait_timeout for the
mysqld process having the ID
4 in the cluster named
mycluster has previously been set to the
value 200 as shown here, and that no other
changes have been to this attribute:

Once you have reset wait_timeout, it no
longer appears in the output of the earlier
get command:

mcm> get wait_timeout:mysqld mycluster;
Empty set (1.42 sec)

This is because the default behavior of the
get command is to display only
those values that have been set either by the MySQL Cluster Manager or by the
user. Since wait_timeout has been allowed to
revert to its default value, you must use the
--include-defaults (short form:
-d) option to retrieve it, as shown here:

Now consider a situation in which process-level and
instance-level settings have been made to a configuration
attribute; in this example, we use
IndexMemory. First,
verify that IndexMemory
is set to its default value for all data node processes (in this
case, there are two of them):

Because the process-level change was specified first, it is
overridden for the ndbd process by the
instance-level change specified second. The output from the
following get command confirms
that this is the case:

If you reset the process-level setting, the instance-level
setting remains, and only the ndbd process
having process ID 2 has its
IndexMemory reset to the
default value; the instance-level setting remains in effect, as
you can see from the following sequence of commands:

If the order of the specifiers in the original command that
set IndexMemory had
been reversed as
IndexMemory:ndbd:3=750M,IndexMemory:ndbd=500M,
the instance-level change would have been overridden by the
process-level change, and the resulting
IndexMemory setting
for both ndbd processes would be
500M. As discussed elsewhere, a
process-level setting made after an instance-level setting
that affects the same process completely removes the
instance-level setting; the instance-level setting is not
preserved, and resetting the attribute on the process level
merely restores the default setting for all processes of that
type. See Section 4.5, “MySQL Cluster Manager Configuration Commands”, for
more information.

Starting from MySQL Cluster Manager 1.3.4, the get and
reset commands fully support multi-entry
replication attributes; for example, if the
replicate_ignore_table attribute has multiple
entries:

Resetting TCP Connection Attributes.
Certain configuration attributes, such as those relating to
TCP connections, apply to connections between processes rather
than to individual processes or individual process types. As
shown elsewhere (see Setting TCP Connection Attributes),
when you set such an attribute on the process level using
MySQL Cluster Manager, this means that the attribute applies to all
connections between the two types of processes specified when
issuing the set command. It is also
possible to set such an attribute on the instance level, in
which case it applies only to a single connection between two
process instances.

Similarly, it is possible to reset such an attribute on either
the process or instance level, depending on the level or levels
at which it was set. In either case, an extended form of the
process specifier is required, just as it is when setting an
attribute that applies to a connection between processes. Assume
that the SendBufferMemory
attribute has previously been set for all connections between
the two ndbd processes and the two
mysqld processes that are found in a MySQL
Cluster named mycluster2, as shown in the
output of this get command:

Suppose that you wish to reset
SendBufferMemory only for
the connection between the ndbd process
having process ID 3 and the
mysqld process having process ID
5. The
SendBufferMemory setting
that applies to this connection is specified on the instance
level, as you can see because the Level
column value corresponding to this connection is empty; this
means that it is possible to reset this value on the instance
level. You can do this using the reset
command shown here:

You can verify that the attribute was reset using the
get command. However, as noted
previously, once the instance-level setting has been removed,
the process-level setting for this attribute again takes effect,
so that the same setting applies to all connections between
ndbd and mysqld processes,
as shown here:

You can verify that the attribute has been reset for all
connection between ndbd processes and
mysqld processes, by using the
get command, as shown here:

mcm> get -d SendBufferMemory mycluster2;
Empty set (1.39 sec)

As noted elsewhere in this manual (see
Section 4.5.1, “The get Command”), the empty result set is to be
expected in this case, even when
get is invoked using the
--include-defaults (or -d)
option, because the MySQL Cluster Manager client does not display attributes
that appear in the [tcp],
[shm], or [sci] sections
of the config.ini configuration file if
they have not been explicitly set by the user.