Spec-Zone .ru
спецификации, руководства, описания, API
|
The [mysqld]
and [api]
sections in the config.ini
file define the behavior of the MySQL servers (SQL nodes) and other
applications (API nodes) used to access cluster data. None of the parameters shown is required. If no computer
or host name is provided, any host can use this SQL or API node.
Generally speaking, a [mysqld]
section is used to indicate a MySQL server providing
an SQL interface to the cluster, and an [api]
section is used for applications
other than mysqld processes accessing cluster data, but the two
designations are actually synonymous; you can, for instance, list parameters for a MySQL server acting as an SQL
node in an [api]
section.
For a discussion of MySQL server options for MySQL Cluster, see Section 17.3.4.2, "MySQL Server Options for MySQL Cluster"; for information about MySQL server system variables relating to MySQL Cluster, see Section 17.3.4.3, "MySQL Cluster System Variables".
Effective Version | Type/Units | Default | Range/Values |
---|---|---|---|
NDB 7.3.0 | unsigned | [none] | 1 - 255 |
Restart Type: IS |
The Id
is an integer value used to identify the node in all cluster
internal messages. The permitted range of values is 1 to 255 inclusive. This value must be unique
for each node in the cluster, regardless of the type of node.
Data node IDs must be less than 49, regardless of the MySQL Cluster version used. If you plan to deploy a large number of data nodes, it is a good idea to limit the node IDs for API nodes (and management nodes) to values greater than 48.
NodeId
is the preferred parameter name to use when identifying API nodes. (Id
continues to be supported for backward compatibility, but is now deprecated and generates a warning
when used. It is also subject to future removal.)
Effective Version | Type/Units | Default | Range/Values |
---|---|---|---|
NDB 7.3.0 | unsigned | [none] | 1 - 255 |
Restart Type: IS |
The NodeId
is an integer value used to identify the node in all cluster
internal messages. The permitted range of values is 1 to 255 inclusive. This value must be unique
for each node in the cluster, regardless of the type of node.
Data node IDs must be less than 49, regardless of the MySQL Cluster version used. If you plan to deploy a large number of data nodes, it is a good idea to limit the node IDs for API nodes (and management nodes) to values greater than 48.
NodeId
is the preferred parameter name to use when identifying management nodes. An alias, Id
, was used for this purpose in very old versions of MySQL Cluster,
and continues to be supported for backward compatibility; it is now deprecated and generates a
warning when used, and is subject to removal in a future release of MySQL Cluster.
This refers to the Id
set for one of the computers (hosts) defined in a
[computer]
section of the configuration file.
Effective Version | Type/Units | Default | Range/Values |
---|---|---|---|
NDB 7.3.0 | name or IP address | [none] | ... |
Restart Type: S |
Specifying this parameter defines the hostname of the computer on which the SQL node (API node) is
to reside. To specify a hostname, either this parameter or ExecuteOnComputer
is required.
If no HostName
or ExecuteOnComputer
is
specified in a given [mysql]
or [api]
section of the config.ini
file, then an SQL or API node may connect
using the corresponding "slot" from any host
which can establish a network connection to the management server host machine. This differs from the default behavior for data nodes, where localhost
is assumed for HostName
unless
otherwise specified.
This parameter defines which nodes can act as arbitrators. Both MGM nodes and SQL nodes can be
arbitrators. A value of 0 means that the given node is never used as an arbitrator, a value of 1
gives the node high priority as an arbitrator, and a value of 2 gives it low priority. A normal
configuration uses the management server as arbitrator, setting its ArbitrationRank
to 1 (the default for management nodes) and those for all SQL nodes to 0 (the default for SQL
nodes).
By setting ArbitrationRank
to 0 on all management and SQL nodes, you
can disable arbitration completely. You can also control arbitration by overriding this parameter;
to do so, set the Arbitration
parameter in the [ndbd
default]
section of the config.ini
global configuration
file.
Setting this parameter to any other value than 0 (the default) means that responses by the arbitrator to arbitration requests will be delayed by the stated number of milliseconds. It is usually not necessary to change this value.
For queries that are translated into full table scans or range scans on indexes, it is important for
best performance to fetch records in properly sized batches. It is possible to set the proper size
both in terms of number of records (BatchSize
) and in terms of bytes (BatchByteSize
). The actual batch size is limited by both
parameters.
The speed at which queries are performed can vary by more than 40% depending upon how this parameter is set. In future releases, MySQL Server will make educated guesses on how to set parameters relating to batch size, based on the query type.
This parameter is measured in bytes and by default is equal to 16KB.
This parameter is measured in number of records and is by default set to 256. The maximum size is 992.
Use this parameter to set the scheduling policy and priority of heartbeat threads for management and API nodes. The syntax for setting this parameter is shown here:
HeartbeatThreadPriority =policy
[,priority
]policy
: {FIFO | RR}
When setting this parameter, you must specify a policy. This is one of FIFO
(first in, first in) or RR
(round
robin). This followed optionally by the priority (an integer).
The batch size is the size of each batch sent from each data node. Most scans are performed in parallel to protect the MySQL Server from receiving too much data from many nodes in parallel; this parameter sets a limit to the total batch size over all nodes.
The default value of this parameter is set to 256KB. Its maximum size is 16MB.
This parameter is available beginning with MySQL Cluster NDB 6.4.0. It is used to determine the total amount of memory to allocate on this node for shared send buffer memory among all configured transporters.
If this parameter is set, its minimum permitted value is 256KB; the maxmimum is 4294967039. For more
detailed information about the behavior and use of TotalSendBufferMemory
and configuring send buffer memory parameters
in MySQL Cluster, see Section
17.3.2.12, "Configuring MySQL Cluster Send Buffer Parameters".
Effective Version | Type/Units | Default | Range/Values |
---|---|---|---|
NDB 7.3.0 | boolean | false | true, false |
Restart Type: N |
This parameter is false
by default. This forces disconnected API nodes
(including MySQL Servers acting as SQL nodes) to use a new connection to the cluster rather than
attempting to re-use an existing one, as re-use of connections can cause problems when using
dynamically-allocated node IDs. (Bug #45921)
This parameter can be overridden using the NDB API. For more information, see Ndb_cluster_connection::set_auto_reconnect()
Ndb_cluster_connection::get_auto_reconnect()
DefaultOperationRedoProblemAction
Effective Version | Type/Units | Default | Range/Values |
---|---|---|---|
NDB 7.3.0 | enumeration | QUEUE | ABORT, QUEUE |
Restart Type: S |
This parameter (along with RedoOverCommitLimit
and RedoOverCommitCounter
) controls the data node's handling of
operations when too much time is taken flushing redo logs to disk. This occurs when a given redo log
flush takes longer than RedoOverCommitLimit
seconds, more than RedoOverCommitCounter
times, causing any pending transactions to
be aborted.
When this happens, the node can respond in either of two ways, according to the value of DefaultOperationRedoProblemAction
, listed here:
ABORT
: Any pending operations from aborted
transactions are also aborted.
QUEUE
: Pending operations from transactions
that were aborted are queued up to be re-tried.
Effective Version | Type/Units | Default | Range/Values |
---|---|---|---|
NDB 7.3.0 | LDM threads | 3840 | 0 - 3840 |
Restart Type: N |
MySQL Cluster NDB 7.2.7 and later use a larger default table hash map size (3840) than in previous
releases (240). Beginning with MySQL Cluster NDB 7.2.11, the size of the table hash maps used by NDB
is configurable using this parameter; previously this value
was hard-coded. DefaultHashMapSize
can take any of three possible
values (0, 240, 3840). These values and their effects are described in the following table.
Value | Description / Effect |
---|---|
0 |
Use the lowest value set, if any, for this parameter among all data nodes and API nodes in the cluster; if it is not set on any data or API node, use the default value. |
240 |
Original hash map size, used by default in all MySQL Cluster releases prior to MySQL Cluster NDB 7.2.7. |
3840 |
Larger hash map size as used by default in MySQL Cluster NDB 7.2.7 andlater |
The primary intended use for this parameter is to facilitate upgrades and especially downgrades
between MySQL Cluster NDB 7.2.7 and later MySQL Cluster versions, in which the larger hash map size
(3840) is the default, and earlier releases (in which the default was 240), due to the fact that
this change is not otherwise backward compatible (Bug #14800539). By setting this parameter to 240
prior to performing an upgrade from an older version where this value is in use, you can cause the
cluster to continue using the smaller size for table hash maps, in which case the tables remain
compatible with earlier versions following the upgrade. DefaultHashMapSize
can be set for individual data nodes, API nodes,
or both, but setting it once only, in the [ndbd default]
section of the
config.ini
file, is the recommended practice.
After increasing this parameter, to have existing tables to take advantage of the new size, you can
run ALTER TABLE ...
REORGANIZE PARTITION
on them, after which they can use the larger hash map size. This
is in addition to performing a rolling restart, which makes the larger hash maps available to new
tables, but does not enable existing tables to use them.
Decreasing this parameter online after any tables have been created or modified with DefaultHashMapSize
equal to 3840 is not currently supported.
You can obtain some information from a MySQL server running as a Cluster SQL node using SHOW STATUS
in the mysql
client, as shown here:
mysql> SHOW STATUS LIKE 'ndb%';
+-----------------------------+---------------+| Variable_name | Value |+-----------------------------+---------------+| Ndb_cluster_node_id | 5 || Ndb_config_from_host | 192.168.0.112 || Ndb_config_from_port | 1186 || Ndb_number_of_storage_nodes | 4 |+-----------------------------+---------------+4 rows in set (0.02 sec)
For information about these Cluster system status variables, see Section 5.1.6, "Server Status Variables".
To add new SQL or API nodes to the configuration of a running MySQL Cluster, it is necessary to
perform a rolling restart of all cluster nodes after adding new [mysqld]
or
[api]
sections to the config.ini
file (or files,
if you are using more than one management server). This must be done before the new SQL or API nodes can
connect to the cluster.
It is not necessary to perform any restart of the cluster if new SQL or API nodes can employ previously unused API slots in the cluster configuration to connect to the cluster.