如何查看NDB的的状态信息how to show ndb status & variables

大家知道在mysql client上可以 SHOW VARIABLES LIKE '%ndb%';   SHOW STATUS LIKE '%ndb%'; 会显示ndb的一些参数，连接状态可以使用ndb_mgm -e show 来查看一些东西，但是诸如TransactionInactiveTimeout，   HeartbeatIntervalDbApi 的特有属性，是在ndb的config.ini当中设置，或者不设置使用其默认值的，mysql client这边如何查看呢？

1）有一个ndbinfo 的Database  里面n多有关于ndb运行状态，特有属性

特别的要改掉ndbinfo_show_hidden这个属性

1. mysql> show global variables like 'ndbinfo_show_hidden';
2. +---------------------+-------+
3. | Variable_name       | Value |
4. +---------------------+-------+
5. | ndbinfo_show_hidden | OFF   |
6. +---------------------+-------+
7. 1 row in set (0.00 sec)
8.  
9. mysql> show session variables like 'ndbinfo_show_hidden';
10. +---------------------+-------+
11. | Variable_name       | Value |
12. +---------------------+-------+
13. | ndbinfo_show_hidden | OFF   |
14. +---------------------+-------+
15. 1 row in set (0.00 sec)
16.  
17. mysql> use ndbinfo;
18. Reading table information for completion of table and column names
19. You can turn off this feature to get a quicker startup with -A
20.  
21. Database changed
22. mysql> show tables;
23. +-------------------+
24. | Tables_in_ndbinfo |
25. +-------------------+
26. | blocks            |
27. | config_params     |
28. | counters          |
29. | logbuffers        |
30. | logspaces         |
31. | memoryusage       |
32. | ndb$columns       |
33. | ndb$counters      |
34. | ndb$logbuffers    |
35. | ndb$logspaces     |
36. | ndb$nodes         |
37. | ndb$pools         |
38. | ndb$resources     |
39. | ndb$tables        |
40. | ndb$test          |
41. | ndb$transporters  |
42. | nodes             |
43. | resources         |
44. | transporters      |
45. +-------------------+
46. 19 rows in set (0.00 sec)
47.  
48. mysql> select version();
49. +------------------------------+
50. | version()                    |
51. +------------------------------+
52. | 5.1.44-ndb-7.1.3-spj-preview |
53. +------------------------------+
54. 1 row in set (0.00 sec)

==================================================================

之后就会有

mysql> show global variables like 'ndbinfo_show_hidden';
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| ndbinfo_show_hidden | OFF   |
+---------------------+-------+
1 row in set (0.00 sec)


mysql> show session variables like 'ndbinfo_show_hidden';
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| ndbinfo_show_hidden | OFF   |
+---------------------+-------+
1 row in set (0.00 sec)


mysql> use ndbinfo; 
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A


Database changed
mysql> show tables; 
+-------------------+
| Tables_in_ndbinfo |
+-------------------+
| blocks            |
| config_params     |
| counters          |
| logbuffers        |
| logspaces         |
| memoryusage       |
| ndb$columns       |
| ndb$counters      |
| ndb$logbuffers    |
| ndb$logspaces     |
| ndb$nodes         |
| ndb$pools         |
| ndb$resources     |
| ndb$tables        |
| ndb$test          |
| ndb$transporters  |
| nodes             |
| resources         |
| transporters      |
+-------------------+
19 rows in set (0.00 sec)


mysql> select version(); 
+------------------------------+
| version()                    |
+------------------------------+
| 5.1.44-ndb-7.1.3-spj-preview |
+------------------------------+
1 row in set (0.00 sec)

2）Quick Reference: MySQL Cluster SQL Statements

from http://docs.oracle.com/cd/E17952_01/refman-5.1-en/mysql-cluster-sql-statements.html

This section discusses several SQL statements that can prove useful in managing and monitoring a MySQL server that is connected to a MySQL Cluster, and in some cases provide information about the cluster itself.

• SHOW ENGINE NDB STATUS, SHOW ENGINE NDBCLUSTER STATUS

  The output of this statement contains information about the server's connection to the cluster, creation and usage of MySQL Cluster objects, and binary logging for MySQL Cluster replication.

  See Section 12.7.5.16, “SHOW ENGINE Syntax”, for a usage example and more detailed information.

•  SHOW ENGINES

  This statement can be used to determine whether or not clustering support is enabled in the MySQL server, and if so, whether it is active.

  See Section 12.7.5.17, “SHOW ENGINES Syntax”, for more detailed information.

  Note

  In MySQL 5.1 and later, this statement does not support a LIKE clause. However, you can use LIKE to filter queries against the INFORMATION_SCHEMA.ENGINES, as discussed in the next item.

•  SELECT * FROM INFORMATION_SCHEMA.ENGINES [WHERE ENGINE LIKE 'NDB%']

  This is the equivalent of SHOW ENGINES, but uses the ENGINES table of the INFORMATION_SCHEMA database (available beginning with MySQL 5.1.5). Unlike the case with the SHOW ENGINES statement, it is possible to filter the results using a LIKE clause, and to select specific columns to obtain information that may be of use in scripts. For example, the following query shows whether the server was built with NDB support and, if so, whether it is enabled:

  mysql> SELECT SUPPORT FROM INFORMATION_SCHEMA.ENGINES
      ->   WHERE ENGINE LIKE 'NDB%';
  +---------+
  | support |
  +---------+
  | ENABLED |
  +---------+
  

  See Section 19.6, “The INFORMATION_SCHEMA ENGINES Table”, for more information.

•  SHOW VARIABLES LIKE 'NDB%'

  This statement provides a list of most server system variables relating to the NDB storage engine, and their values, as shown here:

  mysql> SHOW VARIABLES LIKE 'NDB%';
  +-------------------------------------+-------+
  | Variable_name                       | Value |
  +-------------------------------------+-------+
  | ndb_autoincrement_prefetch_sz       | 32    |
  | ndb_cache_check_time                | 0     |
  | ndb_extra_logging                   | 0     |
  | ndb_force_send                      | ON    |
  | ndb_index_stat_cache_entries        | 32    |
  | ndb_index_stat_enable               | OFF   |
  | ndb_index_stat_update_freq          | 20    |
  | ndb_report_thresh_binlog_epoch_slip | 3     |
  | ndb_report_thresh_binlog_mem_usage  | 10    |
  | ndb_use_copying_alter_table         | OFF   |
  | ndb_use_exact_count                 | ON    |
  | ndb_use_transactions                | ON    |
  +-------------------------------------+-------+
  

  See Section 5.1.3, “Server System Variables”, for more information.

•  SELECT * FROM INFORMATION_SCHEMA.GLOBAL_VARIABLES WHERE VARIABLE_NAME LIKE 'NDB%';

  This statement is the equivalent of the SHOW command described in the previous item, and provides almost identical output, as shown here:

  mysql> SELECT * FROM INFORMATION_SCHEMA.GLOBAL_VARIABLES
      ->   WHERE VARIABLE_NAME LIKE 'NDB%';
  +-------------------------------------+----------------+
  | VARIABLE_NAME                       | VARIABLE_VALUE |
  +-------------------------------------+----------------+
  | NDB_AUTOINCREMENT_PREFETCH_SZ       | 32             |
  | NDB_CACHE_CHECK_TIME                | 0              |
  | NDB_EXTRA_LOGGING                   | 0              |
  | NDB_FORCE_SEND                      | ON             |
  | NDB_INDEX_STAT_CACHE_ENTRIES        | 32             |
  | NDB_INDEX_STAT_ENABLE               | OFF            |
  | NDB_INDEX_STAT_UPDATE_FREQ          | 20             |
  | NDB_REPORT_THRESH_BINLOG_EPOCH_SLIP | 3              |
  | NDB_REPORT_THRESH_BINLOG_MEM_USAGE  | 10             |
  | NDB_USE_COPYING_ALTER_TABLE         | OFF            |
  | NDB_USE_EXACT_COUNT                 | ON             |
  | NDB_USE_TRANSACTIONS                | ON             |
  +-------------------------------------+----------------+
  

  Unlike the case with the SHOW command, it is possible to select individual columns. For example:

  mysql> SELECT VARIABLE_VALUE 
      ->   FROM INFORMATION_SCHEMA.GLOBAL_VARIABLES
      ->   WHERE VARIABLE_NAME = 'ndb_force_send';
  +----------------+
  | VARIABLE_VALUE |
  +----------------+
  | ON             |
  +----------------+
  

  See Section 19.10, “The INFORMATION_SCHEMA GLOBAL_VARIABLES and SESSION_VARIABLES Tables”, andSection 5.1.3, “Server System Variables”, for more information.

•  SHOW STATUS LIKE 'NDB%'

  This statement shows at a glance whether or not the MySQL server is acting as a cluster SQL node, and if so, it provides the MySQL server's cluster node ID, the host name and port for the cluster management server to which it is connected, and the number of data nodes in the cluster, as shown here:

  mysql> SHOW STATUS LIKE 'NDB%';
  +--------------------------+---------------+
  | Variable_name            | Value         |
  +--------------------------+---------------+
  | Ndb_cluster_node_id      | 10            |
  | Ndb_config_from_host     | 192.168.0.103 |
  | Ndb_config_from_port     | 1186          |
  | Ndb_number_of_data_nodes | 4             |
  +--------------------------+---------------+
  

  If the MySQL server was built with clustering support, but it is not connected to a cluster, all rows in the output of this statement contain a zero or an empty string:

  mysql> SHOW STATUS LIKE 'NDB%';
  +--------------------------+-------+
  | Variable_name            | Value |
  +--------------------------+-------+
  | Ndb_cluster_node_id      | 0     |
  | Ndb_config_from_host     |       |
  | Ndb_config_from_port     | 0     |
  | Ndb_number_of_data_nodes | 0     |
  +--------------------------+-------+
  

  See also Section 12.7.5.37, “SHOW STATUS Syntax”.

•  SELECT * FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME LIKE 'NDB%';

  Beginning with MySQL 5.1.12, this statement provides similar output to the SHOW command discussed in the previous item. However, unlike the case with SHOW STATUS, it is possible using the SELECT to extract values in SQL for use in scripts for monitoring and automation purposes.

  See Section 19.9, “The INFORMATION_SCHEMA GLOBAL_STATUS and SESSION_STATUS Tables”, for more information.

Beginning with MySQL Cluster NDB 7.1.1, you can also query the tables in the ndbinfo information database for real-time data about many MySQL Cluster operations. See Section 16.5.9, “The ndbinfo MySQL Cluster Information Database”.

3） SHOW ENGINE {NDB | NDBCLUSTER} STATUS

Older (and now deprecated) synonyms are SHOW INNODB STATUS for SHOW ENGINE INNODB STATUS and SHOW MUTEX STATUS for SHOW ENGINE INNODB MUTEX. SHOW INNODB STATUS and SHOW MUTEX STATUS are removed in MySQL 5.5.

In MySQL 5.0, SHOW ENGINE INNODB MUTEX is invoked as SHOW MUTEX STATUS. The latter statement displays similar information but in a somewhat different output format.

SHOW ENGINE BDB LOGS formerly displayed status information about BDB log files. As of MySQL 5.1.12, the BDB storage engine is not supported, and this statement produces a warning.

SHOW ENGINE INNODB STATUS displays extensive information from the standard InnoDB Monitor about the state of the InnoDB storage engine. For information about the standard monitor and other InnoDB Monitors that provide information about InnoDB processing, see Section 13.6.13.2, “SHOW ENGINE INNODB STATUS and the InnoDB Monitors”.

SHOW ENGINE INNODB MUTEX displays InnoDB mutex statistics. From MySQL 5.1.2 to 5.1.14, the statement displays the following output fields:

• Type

  Always InnoDB.

• Name

  The mutex name and the source file where it is implemented. Example:&pool->mutex:mem0pool.c

  The mutex name indicates its purpose. For example, the log_sys mutex is used by the InnoDB logging subsystem and indicates how intensive logging activity is. The buf_pool mutex protects the InnoDB buffer pool.

• Status

  The mutex status. The fields contains several values:

  • count indicates how many times the mutex was requested.

  • spin_waits indicates how many times the spinlock had to run.

  • spin_rounds indicates the number of spinlock rounds. (spin_roundsdivided by spin_waits provides the average round count.)

  • os_waits indicates the number of operating system waits. This occurs when the spinlock did not work (the mutex was not locked during the spinlock and it was necessary to yield to the operating system and wait).

  • os_yields indicates the number of times a the thread trying to lock a mutex gave up its timeslice and yielded to the operating system (on the presumption that permitting other threads to run will free the mutex so that it can be locked).

  • os_wait_times indicates the amount of time (in ms) spent in operating system waits, if the timed_mutexes system variable is 1 (ON). Iftimed_mutexes is 0 (OFF), timing is disabled, so os_wait_times is 0.timed_mutexes is off by default.

From MySQL 5.1.15 on, the statement displays the following output fields:

• Type

  Always InnoDB.

• Name

  The source file where the mutex is implemented, and the line number in the file where the mutex is created. The line number may change depending on your version of MySQL.

• Status

  This field displays the same values as previously described (count, spin_waits, spin_rounds, os_waits,os_yields, os_wait_times), but only if UNIV_DEBUG was defined at MySQL compilation time (for example, ininclude/univ.i in the InnoDB part of the MySQL source tree). If UNIV_DEBUG was not defined, the statement displays only the os_waits value. In the latter case (without UNIV_DEBUG), the information on which the output is based is insufficient to distinguish regular mutexes and mutexes that protect rw-locks (which permit multiple readers or a single writer). Consequently, the output may appear to contain multiple rows for the same mutex.

Information from this statement can be used to diagnose system problems. For example, large values ofspin_waits and spin_rounds may indicate scalability problems.

If the server has the NDBCLUSTER storage engine enabled, SHOW ENGINE NDB STATUS displays cluster status information such as the number of connected data nodes, the cluster connectstring, and cluster binlog epochs, as well as counts of various Cluster API objects created by the MySQL Server when connected to the cluster. Sample output from this statement is shown here:

mysql> SHOW ENGINE NDB STATUS;
+------------+-----------------------+--------------------------------------------------+
| Type       | Name                  | Status                                           |
+------------+-----------------------+--------------------------------------------------+
| ndbcluster | connection            | cluster_node_id=7,
  connected_host=192.168.0.103, connected_port=1186, number_of_data_nodes=4,
  number_of_ready_data_nodes=3, connect_count=0                                         |
| ndbcluster | NdbTransaction        | created=6, free=0, sizeof=212                    |
| ndbcluster | NdbOperation          | created=8, free=8, sizeof=660                    |
| ndbcluster | NdbIndexScanOperation | created=1, free=1, sizeof=744                    |
| ndbcluster | NdbIndexOperation     | created=0, free=0, sizeof=664                    |
| ndbcluster | NdbRecAttr            | created=1285, free=1285, sizeof=60               |
| ndbcluster | NdbApiSignal          | created=16, free=16, sizeof=136                  |
| ndbcluster | NdbLabel              | created=0, free=0, sizeof=196                    |
| ndbcluster | NdbBranch             | created=0, free=0, sizeof=24                     |
| ndbcluster | NdbSubroutine         | created=0, free=0, sizeof=68                     |
| ndbcluster | NdbCall               | created=0, free=0, sizeof=16                     |
| ndbcluster | NdbBlob               | created=1, free=1, sizeof=264                    |
| ndbcluster | NdbReceiver           | created=4, free=0, sizeof=68                     |
| ndbcluster | binlog                | latest_epoch=155467, latest_trans_epoch=148126,
  latest_received_binlog_epoch=0, latest_handled_binlog_epoch=0,
  latest_applied_binlog_epoch=0                                                         |
+------------+-----------------------+--------------------------------------------------+

The rows with connection and binlog in the Name column were added to the output of this statement in MySQL 5.1. The Status column in each of these rows provides information about the MySQL server's connection to the cluster and about the cluster binary log's status, respectively. The Status information is in the form of comma-delimited set of name/value pairs.

The connection row's Status column contains the name/value pairs described in the following table.

Name	Value
cluster_node_id	The node ID of the MySQL server in the cluster
connected_host	The host name or IP address of the cluster management server to which the MySQL server is connected
connected_port	The port used by the MySQL server to connect to the management server (connected_host)
number_of_data_nodes	The number of data nodes configured for the cluster (that is, the number of [ndbd]sections in the cluster config.ini file)
number_of_ready_data_nodes	The number of data nodes in the cluster that are actually running
connect_count	The number of times this mysqld has connected or reconnected to cluster data nodes

The binlog row's Status column contains information relating to MySQL Cluster Replication. The name/value pairs it contains are described in the following table.

Name	Value
latest_epoch	The most recent epoch most recently run on this MySQL server (that is, the sequence number of the most recent transaction run on the server)
latest_trans_epoch	The most recent epoch processed by the cluster's data nodes
latest_received_binlog_epoch	The most recent epoch received by the binlog thread
latest_handled_binlog_epoch	The most recent epoch processed by the binlog thread (for writing to the binlog)
latest_applied_binlog_epoch	The most recent epoch actually written to the binlog

See Section 16.6, “MySQL Cluster Replication”, for more information.

The remaining rows from the output of SHOW ENGINE NDB STATUS which are most likely to prove useful in monitoring the cluster are listed here by Name:

• NdbTransaction: The number and size of NdbTransaction objects that have been created. AnNdbTransaction is created each time a table schema operation (such as CREATE TABLE or ALTER TABLE) is performed on an NDB table.

• NdbOperation: The number and size of NdbOperation objects that have been created.

• NdbIndexScanOperation: The number and size of NdbIndexScanOperation objects that have been created.

• NdbIndexOperation: The number and size of NdbIndexOperation objects that have been created.

• NdbRecAttr: The number and size of NdbRecAttr objects that have been created. In general, one of these is created each time a data manipulation statement is performed by an SQL node.

• NdbBlob: The number and size of NdbBlob objects that have been created. An NdbBlob is created for each new operation involving a BLOB column in an NDB table.

• NdbReceiver: The number and size of any NdbReceiver object that have been created. The number in thecreated column is the same as the number of data nodes in the cluster to which the MySQL server has connected.

Note

SHOW ENGINE NDB STATUS returns an empty result if no operations involving NDB tables have been performed during the current session by the MySQL client accessing the SQL node on which this statement is run.

4) Commands in the MySQL Cluster Management Client

In addition to the central configuration file, a cluster may also be controlled through a command-line interface available through the management client ndb_mgm. This is the primary administrative interface to a running cluster.

Commands for the event logs are given in Section 5.5, “Event Reports Generated in MySQL Cluster”; commands for creating backups and restoring from them are provided in Section 5.3, “Online Backup of MySQL Cluster”.

The management client has the following basic commands. In the listing that follows, node_id denotes either a database node ID or the keyword ALL, which indicates that the command should be applied to all of the cluster's data nodes.

•  HELP

  Displays information on all available commands.

•  SHOW

  Displays information on the cluster's status. Possible node status values include UNKNOWN, NO_CONTACT,NOT_STARTED, STARTING, STARTED, SHUTTING_DOWN, and RESTARTING.

  Beginning with MySQL Cluster NDB 6.2.8 and MySQL Cluster NDB 6.3.6, the output from this command indicates when the cluster is in single user mode (status SINGLE USER MODE).

  Prior to MySQL Cluster NDB 7.0.26 and MySQL Cluster NDB 7.1.5, in a cluster having multiple management nodes, this command displayed information only for data nodes that were actually connected to the current management server; in addition, management servers could not find each other until all nodes had been started. Beginning with these versions, such issues are fixed (see Bug #12352191), and management nodes can be additionally be reported with status RESUME or CONNECTED.

•  node_id START

  Brings online the data node identified by node_id (or all data nodes).

  ALL START works on all data nodes only, and does not affect management nodes.

  Important

  To use this command to bring a data node online, the data node must have been started using ndbd --nostartor ndbd -n.

•  node_id STOP [-a] [-f]

  Stops the data or management node identified by node_id. Note that ALL STOP works to stop all data nodes only, and does not affect management nodes.

  A node affected by this command disconnects from the cluster, and its associated ndbd or ndb_mgmd process terminates.

  The -a option causes the node to be stopped immediately, without waiting for the completion of any pending transactions.

  Normally, STOP fails if the result would cause an incomplete cluster. The -f option, added in MySQL Cluster NDB 7.0.19 and MySQL Cluster NDB 7.1.8, forces the node to shut down without checking for this. If this option is used and the result is an incomplete cluster, the cluster immediately shuts down.

  Warning

  Use of the -a option also disables the safety check otherwise performed when STOP is invoked to insure that stopping the node does not cause an incomplete cluster. In other words, you should exercise extreme care when using the -a option with the STOP command, due to the fact that this option makes it possible for the cluster to undergo a forced shutdown because it no longer has a complete copy of all data stored in NDB.

•  node_id RESTART [-n] [-i] [-a] [-f]

  Restarts the data node identified by node_id (or all data nodes).

  Using the -i option with RESTART causes the data node to perform an initial restart; that is, the node's file system is deleted and recreated. The effect is the same as that obtained from stopping the data node process and then starting it again using ndbd --initial from the system shell. Note that backup files and Disk Data files are not removed when this option is used.

  Using the -n option causes the data node process to be restarted, but the data node is not actually brought online until the appropriate START command is issued. The effect of this option is the same as that obtained from stopping the data node and then starting it again using ndbd --nostart or ndbd -n from the system shell.

  Using the -a causes all current transactions relying on this node to be aborted. No GCP check is done when the node rejoins the cluster.

  Normally, RESTART fails if taking the node offline would result in an incomplete cluster. The -f option, added in MySQL Cluster NDB 7.0.19 and MySQL Cluster NDB 7.1.8, forces the node to restart without checking for this. If this option is used and the result is an incomplete cluster, the entire cluster is restarted.

•  node_id STATUS

  Displays status information for the data node identified by node_id (or for all data nodes).

  Beginning with MySQL Cluster NDB 6.2.8 and MySQL Cluster NDB 6.3.6, the output from this command indicates when the cluster is in single user mode.

•  node_id REPORT report-type

  Displays a report of type report-type for the data node identified by node_id, or for all data nodes using ALL.

  Currently, there are two accepted values for report-type:

  • BackupStatus provides a status report on a cluster backup in progress

  • MemoryUsage displays how much data memory and index memory is being used by each data node as shown in this example:

    ndb_mgm> ALL REPORT MEMORY
    Node 1: Data usage is 5%(177 32K pages of total 3200)
    Node 1: Index usage is 0%(108 8K pages of total 12832)
    Node 2: Data usage is 5%(177 32K pages of total 3200)
    Node 2: Index usage is 0%(108 8K pages of total 12832)
    

    In MySQL Cluster NDB 7.1.1 and later, this information is also available from the ndbinfo.memoryusage table.

  report-type is case-insensitive and “fuzzy”; for MemoryUsage, you can use MEMORY (as shown in the prior example), memory, or even simply MEM (or mem). You can abbreviate BackupStatus in a similar fashion.

  The REPORT command was introduced in MySQL Cluster NDB 6.2.3 and MySQL Cluster NDB 6.3.0.

•  ENTER SINGLE USER MODE node_id

  Enters single user mode, whereby only the MySQL server identified by the node ID node_id is permitted to access the database.

  Currently, it is not possible for data nodes to join a MySQL Cluster while it is running in single user mode. (Bug #20395)

•  EXIT SINGLE USER MODE

  Exits single user mode, enabling all SQL nodes (that is, all running mysqld processes) to access the database.

  Note

  It is possible to use EXIT SINGLE USER MODE even when not in single user mode, although the command has no effect in this case.

•  QUIT, EXIT

  Terminates the management client.

  This command does not affect any nodes connected to the cluster.

•  SHUTDOWN

  Shuts down all cluster data nodes and management nodes. To exit the management client after this has been done, use EXIT or QUIT.

  This command does not shut down any SQL nodes or API nodes that are connected to the cluster.

•  CREATE NODEGROUP nodeid[, nodeid, ...]

  Creates a new MySQL Cluster node group and causes data nodes to join it.

  This command is used after adding new data nodes online to a MySQL Cluster, and causes them to join a new node group and thus to begin participating fully in the cluster. The command takes as its sole parameter a comma-separated list of node IDs—these are the IDs of the nodes just added and started that are to join the new node group. The number of nodes must be the same as the number of nodes in each node group that is already part of the cluster (each MySQL Cluster node group must have the same number of nodes). In other words, if the MySQL Cluster has 2 node groups of 2 data nodes each, then the new node group must also have 2 data nodes.

  The node group ID of the new node group created by this command is determined automatically, and always the next highest unused node group ID in the cluster; it is not possible to set it manually.

  This command was introduced in MySQL Cluster NDB 6.4.0. For more information, see Section 5.12, “Adding MySQL Cluster Data Nodes Online”.

•  DROP NODEGROUP nodegroup_id

  Drops the MySQL Cluster node group with the given nodegroup_id.

  This command can be used to drop a node group from a MySQL Cluster. DROP NODEGROUP takes as its sole argument the node group ID of the node group to be dropped.

  DROP NODEGROUP acts only to remove the data nodes in the effected node group from that node group. It does not stop data nodes, assign them to a different node group, or remove them from the cluster's configuration. A data node that does not belong to a node group is indicated in the output of the management client SHOW command with no nodegroup in place of the node group ID, like this (indicated using bold text):

  id=3    @10.100.2.67  (5.1.61-ndb-7.1.21, no nodegroup)
  

  Prior to MySQL Cluster NDB 7.0.4, the SHOW output was not updated correctly following DROP NODEGROUP. (Bug #43413)

  DROP NODEGROUP works only when all data nodes in the node group to be dropped are completely empty of any table data and table definitions. Since there is currently no way using ndb_mgm or the mysql client to remove all data from a specific data node or node group, this means that the command succeeds only in the two following cases:

  1. After issuing CREATE NODEGROUP in the ndb_mgm client, but before issuing any ALTER ONLINE TABLE ... REORGANIZE PARTITION statements in the mysql client.

  2. After dropping all NDBCLUSTER tables using DROP TABLE.

     TRUNCATE TABLE does not work for this purpose because this removes only the table data; the data nodes continue to store an NDBCLUSTER table's definition until a DROP TABLE statement is issued that causes the table metadata to be dropped.

  DROP NODEGROUP was introduced in MySQL Cluster NDB 6.4.0. For more information, see Section 5.12, “Adding MySQL Cluster Data Nodes Online”.