This section provides information about MySQL server options, server and status variables that are specific to NDB Cluster. For general information on using these, and for other options and variables not specific to NDB Cluster, see Section 5.1, “The MySQL Server”.
For NDB Cluster configuration parameters used in the cluster
configuration file (usually named config.ini),
see Section 21.4, “Configuration of NDB Cluster”.
This section provides descriptions of mysqld server options relating to NDB Cluster. For information about mysqld options not specific to NDB Cluster, and for general information about the use of options with mysqld, see Section 5.1.6, “Server Command Options”.
For information about command-line options used with other NDB Cluster processes, see Section 21.5, “NDB Cluster Programs”.
-
Command-Line Format --ndbcluster[=value]Disabled by skip-ndbclusterType Boolean Default Value OFFThe
NDBCLUSTERstorage engine is necessary for using NDB Cluster. If a mysqld binary includes support for theNDBCLUSTERstorage engine, the engine is disabled by default. Use the--ndbclusteroption to enable it. Use--skip-ndbclusterto explicitly disable the engine.It is not necessary or desirable to use this option together with
--initialize. Beginning with NDB 7.5.4,--ndbclusteris ignored (and theNDBstorage engine is not enabled) if--initializeis also used. (Bug #81689, Bug #23518923) --ndb-allow-copying-alter-table=[ON|OFF]Command-Line Format --ndb-allow-copying-alter-table[={OFF|ON}]Introduced 5.7.10-ndb-7.5.0 System Variable ndb_allow_copying_alter_tableScope Global, Session Dynamic Yes Type Boolean Default Value ONLet
ALTER TABLEand other DDL statements use copying operations onNDBtables. Set toOFFto keep this from happening; doing so may improve performance of critical applications.-
Command-Line Format --ndb-batch-sizeSystem Variable ndb_batch_sizeScope Global, Session Dynamic Yes Type Integer Default Value 32768Minimum Value 0Maximum Value (≥ 5.7.37-ndb-7.6.22) 2147483648Maximum Value (≥ 5.7.37-ndb-7.5.26) 2147483648Maximum Value (≤ 5.7.37-ndb-7.5.25) 31536000Maximum Value (≤ 5.7.37-ndb-7.6.21) 31536000Maximum Value 31536000Unit bytes This sets the size in bytes that is used for NDB transaction batches.
--ndb-cluster-connection-pool=#Command-Line Format --ndb-cluster-connection-poolSystem Variable ndb_cluster_connection_poolSystem Variable ndb_cluster_connection_poolScope Global Scope Global Dynamic No Dynamic No Type Integer Default Value 1Minimum Value 1Maximum Value 63By setting this option to a value greater than 1 (the default), a mysqld process can use multiple connections to the cluster, effectively mimicking several SQL nodes. Each connection requires its own
[api]or[mysqld]section in the cluster configuration (config.ini) file, and counts against the maximum number of API connections supported by the cluster.Suppose that you have 2 cluster host computers, each running an SQL node whose mysqld process was started with
--ndb-cluster-connection-pool=4; this means that the cluster must have 8 API slots available for these connections (instead of 2). All of these connections are set up when the SQL node connects to the cluster, and are allocated to threads in a round-robin fashion.This option is useful only when running mysqld on host machines having multiple CPUs, multiple cores, or both. For best results, the value should be smaller than the total number of cores available on the host machine. Setting it to a value greater than this is likely to degrade performance severely.
ImportantBecause each SQL node using connection pooling occupies multiple API node slots—each slot having its own node ID in the cluster—you must not use a node ID as part of the cluster connection string when starting any mysqld process that employs connection pooling.
Setting a node ID in the connection string when using the
--ndb-cluster-connection-pooloption causes node ID allocation errors when the SQL node attempts to connect to the cluster.--ndb-cluster-connection-pool-nodeids=listCommand-Line Format --ndb-cluster-connection-pool-nodeidsIntroduced 5.7.10-ndb-7.5.0 System Variable (≥ 5.7.10-ndb-7.5.0) ndb_cluster_connection_pool_nodeidsScope (≥ 5.7.10-ndb-7.5.0) Global Dynamic (≥ 5.7.10-ndb-7.5.0) No Type Set Default Value Specifies a comma-separated list of node IDs for connections to the cluster used by an SQL node. The number of nodes in this list must be the same as the value set for the
--ndb-cluster-connection-pooloption.--ndb-cluster-connection-pool-nodeidswas added in NDB 7.5.0.--ndb-blob-read-batch-bytes=bytesCommand-Line Format --ndb-blob-read-batch-bytesSystem Variable ndb_blob_read_batch_bytesScope Global, Session Dynamic Yes Type Integer Default Value 65536Minimum Value 0Maximum Value 4294967295This option can be used to set the size (in bytes) for batching of
BLOBdata reads in NDB Cluster applications. When this batch size is exceeded by the amount ofBLOBdata to be read within the current transaction, any pendingBLOBread operations are immediately executed.The maximum value for this option is 4294967295; the default is 65536. Setting it to 0 has the effect of disabling
BLOBread batching.NoteIn NDB API applications, you can control
BLOBwrite batching with thesetMaxPendingBlobReadBytes()andgetMaxPendingBlobReadBytes()methods.--ndb-blob-write-batch-bytes=bytesCommand-Line Format --ndb-blob-write-batch-bytesSystem Variable ndb_blob_write_batch_bytesScope Global, Session Dynamic Yes Type Integer Default Value 65536Minimum Value 0Maximum Value 4294967295Unit bytes This option can be used to set the size (in bytes) for batching of
BLOBdata writes in NDB Cluster applications. When this batch size is exceeded by the amount ofBLOBdata to be written within the current transaction, any pendingBLOBwrite operations are immediately executed.The maximum value for this option is 4294967295; the default is 65536. Setting it to 0 has the effect of disabling
BLOBwrite batching.NoteIn NDB API applications, you can control
BLOBwrite batching with thesetMaxPendingBlobWriteBytes()andgetMaxPendingBlobWriteBytes()methods.--ndb-connectstring=connection_stringCommand-Line Format --ndb-connectstringType String When using the
NDBCLUSTERstorage engine, this option specifies the management server that distributes cluster configuration data. See Section 21.4.3.3, “NDB Cluster Connection Strings”, for syntax.--ndb-default-column-format=[FIXED|DYNAMIC]Command-Line Format --ndb-default-column-format={FIXED|DYNAMIC}Introduced 5.7.11-ndb-7.5.1 System Variable ndb_default_column_formatScope Global Dynamic Yes Type Enumeration Default Value (≥ 5.7.16-ndb-7.5.4) FIXEDDefault Value (≥ 5.7.11-ndb-7.5.1, ≤ 5.7.13-ndb-7.5.3) DYNAMICValid Values FIXEDDYNAMICIn NDB 7.5.1 and later, sets the default
COLUMN_FORMATandROW_FORMATfor new tables (see Section 13.1.18, “CREATE TABLE Statement”).In NDB 7.5.1, the default for this option was
DYNAMIC; in NDB 7.5.4, the default was changed toFIXEDto maintain backwards compatibility with older release series (Bug #24487363).--ndb-deferred-constraints=[0|1]Command-Line Format --ndb-deferred-constraintsSystem Variable ndb_deferred_constraintsScope Global, Session Dynamic Yes Type Integer Default Value 0Minimum Value 0Maximum Value 1Controls whether or not constraint checks on unique indexes are deferred until commit time, where such checks are supported.
0is the default.This option is not normally needed for operation of NDB Cluster or NDB Cluster Replication, and is intended primarily for use in testing.
--ndb-distribution=[KEYHASH|LINHASH]Command-Line Format --ndb-distribution={KEYHASH|LINHASH}System Variable ndb_distributionScope Global Dynamic Yes Type Enumeration Default Value KEYHASHValid Values LINHASHKEYHASHControls the default distribution method for
NDBtables. Can be set to either ofKEYHASH(key hashing) orLINHASH(linear hashing).KEYHASHis the default.-
Command-Line Format --ndb-log-apply-status[={OFF|ON}]System Variable ndb_log_apply_statusScope Global Dynamic No Type Boolean Default Value OFFCauses a replica mysqld to log any updates received from its immediate source to the
mysql.ndb_apply_statustable in its own binary log using its own server ID rather than the server ID of the source. In a circular or chain replication setting, this allows such updates to propagate to themysql.ndb_apply_statustables of any MySQL servers configured as replicas of the current mysqld.In a chain replication setup, using this option allows downstream (replica) clusters to be aware of their positions relative to all of their upstream contributors (sources).
In a circular replication setup, this option causes changes to
ndb_apply_statustables to complete the entire circuit, eventually propagating back to the originating NDB Cluster. This also allows a cluster acting as a source to see when its changes (epochs) have been applied to the other clusters in the circle.This option has no effect unless the MySQL server is started with the
--ndbclusteroption. --ndb-log-empty-epochs=[ON|OFF]Command-Line Format --ndb-log-empty-epochs[={OFF|ON}]System Variable ndb_log_empty_epochsScope Global Dynamic Yes Type Boolean Default Value OFFCauses epochs during which there were no changes to be written to the
ndb_apply_statusandndb_binlog_indextables, even whenlog_slave_updatesis enabled.By default this option is disabled. Disabling
--ndb-log-empty-epochscauses epoch transactions with no changes not to be written to the binary log, although a row is still written even for an empty epoch inndb_binlog_index.Because
--ndb-log-empty-epochs=1causes the size of thendb_binlog_indextable to increase independently of the size of the binary log, users should be prepared to manage the growth of this table, even if they expect the cluster to be idle a large part of the time.--ndb-log-empty-update=[ON|OFF]Command-Line Format --ndb-log-empty-update[={OFF|ON}]System Variable ndb_log_empty_updateScope Global Dynamic Yes Type Boolean Default Value OFFCauses updates that produced no changes to be written to the
ndb_apply_statusandndb_binlog_indextables, when whenlog_slave_updatesis enabled.By default this option is disabled (
OFF). Disabling--ndb-log-empty-updatecauses updates with no changes not to be written to the binary log.--ndb-log-exclusive-reads=[0|1]Command-Line Format --ndb-log-exclusive-reads[={OFF|ON}]System Variable ndb_log_exclusive_readsScope Global, Session Dynamic Yes Type Boolean Default Value 0Starting the server with this option causes primary key reads to be logged with exclusive locks, which allows for NDB Cluster Replication conflict detection and resolution based on read conflicts. You can also enable and disable these locks at runtime by setting the value of the
ndb_log_exclusive_readssystem variable to 1 or 0, respectively. 0 (disable locking) is the default.For more information, see Read conflict detection and resolution.
-
Command-Line Format --ndb-log-fail-terminateIntroduced 5.7.29-ndb-7.6.14 System Variable ndb_log_fail_terminateScope Global Dynamic No Type Boolean Default Value FALSEWhen this option is specified, and complete logging of all found row events is not possible, the mysqld process is terminated.
-
Command-Line Format --ndb-log-orig[={OFF|ON}]System Variable ndb_log_origScope Global Dynamic No Type Boolean Default Value OFFLog the originating server ID and epoch in the
ndb_binlog_indextable.NoteThis makes it possible for a given epoch to have multiple rows in
ndb_binlog_index, one for each originating epoch.For more information, see Section 21.7.4, “NDB Cluster Replication Schema and Tables”.
-
Command-Line Format --ndb-log-transaction-id[={OFF|ON}]System Variable ndb_log_transaction_idScope Global Dynamic No Type Boolean Default Value OFFCauses a replica mysqld to write the NDB transaction ID in each row of the binary log. Such logging requires the use of the Version 2 event format for the binary log; thus, the
log_bin_use_v1_row_eventssystem variable must be disabled to use this option.--ndb-log-transaction-idis required to enable NDB Cluster Replication conflict detection and resolution using theNDB$EPOCH_TRANS()function (see NDB$EPOCH_TRANS()).For more information, see Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
-
Command-Line Format --ndb-log-update-as-write[={OFF|ON}]System Variable ndb_log_update_as_writeScope Global Dynamic Yes Type Boolean Default Value ONWhether updates on the source are written to the binary log as updates (
OFF) or writes (ON). When this option is enabled, and both--ndb-log-updated-onlyand--ndb-log-update-minimalare disabled, operations of different types are loǵged as described in the following list:INSERT: Logged as aWRITE_ROWevent with no before image; the after image is logged with all columns.UPDATE: Logged as aWRITE_ROWevent with no before image; the after image is logged with all columns.DELETE: Logged as aDELETE_ROWevent with all columns logged in the before image; the after image is not logged.
This option can be used for NDB Replication conflict resolution in combination with the other two NDB logging options mentioned previously; see ndb_replication Table, for more information.
-
Command-Line Format --ndb-log-updated-only[={OFF|ON}]System Variable ndb_log_updated_onlyScope Global Dynamic Yes Type Boolean Default Value ONWhether mysqld writes updates only (
ON) or complete rows (OFF) to the binary log. When this option is enabled, and both--ndb-log-update-as-writeand--ndb-log-update-minimalare disabled, operations of different types are loǵged as described in the following listINSERT: Logged as aWRITE_ROWevent with no before image; the after image is logged with all columns.UPDATE: Logged as anUPDATE_ROWevent with primary key columns and updated columns present in both the before and after images.DELETE: Logged as aDELETE_ROWevent with primary key columns incuded in the before image; the after image is not logged.
This option can be used for NDB Replication conflict resolution in combination with the other two NDB logging options mentioned previously; see ndb_replication Table, for more information about how these options interact with one another.
-
Command-Line Format --ndb-log-update-minimal[={OFF|ON}]Introduced 5.7.18-ndb-7.6.3 System Variable ndb_log_update_minimalScope Global Dynamic Yes Type Boolean Default Value OFFLog updates in a minimal fashion, by writing only the primary key values in the before image, and only the changed columns in the after image. This may cause compatibility problems if replicating to storage engines other than
NDB. When this option is enabled, and both--ndb-log-updated-onlyand--ndb-log-update-as-writeare disabled, operations of different types are loǵged as described in the following list:INSERT: Logged as aWRITE_ROWevent with no before image; the after image is logged with all columns.UPDATE: Logged as anUPDATE_ROWevent with primary key columns in the before image; all columns except primary key columns are logged in the after image.DELETE: Logged as aDELETE_ROWevent with all columns in the before image; the after image is not logged.
This option can be used for NDB Replication conflict resolution in combination with the other two NDB logging options mentioned previously; see ndb_replication Table, for more information.
-
Command-Line Format --ndb-mgmd-host=host_name[:port_num]Type String Default Value localhost:1186Can be used to set the host and port number of a single management server for the program to connect to. If the program requires node IDs or references to multiple management servers (or both) in its connection information, use the
--ndb-connectstringoption instead. -
Command-Line Format --ndb-nodeid=#Status Variable Ndb_cluster_node_idScope Global Dynamic No Type Integer Default Value N/AMinimum Value 1Maximum Value 255Maximum Value 63Set this MySQL server's node ID in an NDB Cluster.
The
--ndb-nodeidoption overrides any node ID set with--ndb-connectstring, regardless of the order in which the two options are used.In addition, if
--ndb-nodeidis used, then either a matching node ID must be found in a[mysqld]or[api]section ofconfig.ini, or there must be an “open”[mysqld]or[api]section in the file (that is, a section without aNodeIdorIdparameter specified). This is also true if the node ID is specified as part of the connection string.Regardless of how the node ID is determined, its is shown as the value of the global status variable
Ndb_cluster_node_idin the output ofSHOW STATUS, and ascluster_node_idin theconnectionrow of the output ofSHOW ENGINE NDBCLUSTER STATUS.For more information about node IDs for NDB Cluster SQL nodes, see Section 21.4.3.7, “Defining SQL and Other API Nodes in an NDB Cluster”.
--ndb-optimization-delay=millisecondsCommand-Line Format --ndb-optimization-delay=#System Variable ndb_optimization_delayScope Global Dynamic Yes Type Integer Default Value 10Minimum Value 0Maximum Value 100000Unit milliseconds Set the number of milliseconds to wait between sets of rows by
OPTIMIZE TABLEstatements onNDBtables. The default is 10.--ndb-optimized-node-selectionCommand-Line Format --ndb-optimized-node-selectionSystem Variable ndb_optimized_node_selectionScope Global Dynamic Yes Type Integer Default Value 3Minimum Value 0Maximum Value 3Enable optimizations for selection of nodes for transactions. Enabled by default; use
--skip-ndb-optimized-node-selectionto disable.--ndb-transid-mysql-connection-map=stateCommand-Line Format --ndb-transid-mysql-connection-map[=state]Type Enumeration Default Value ONValid Values ONOFFFORCEEnables or disables the plugin that handles the
ndb_transid_mysql_connection_maptable in theINFORMATION_SCHEMAdatabase. Takes one of the valuesON,OFF, orFORCE.ON(the default) enables the plugin.OFFdisables the plugin, which makesndb_transid_mysql_connection_mapinaccessible.FORCEkeeps the MySQL Server from starting if the plugin fails to load and start.You can see whether the
ndb_transid_mysql_connection_maptable plugin is running by checking the output ofSHOW PLUGINS.-
Command-Line Format --ndb-wait-connected=#System Variable ndb_wait_connectedScope Global Dynamic No Type Integer Default Value 30Minimum Value 0Maximum Value 31536000Unit seconds This option sets the period of time that the MySQL server waits for connections to NDB Cluster management and data nodes to be established before accepting MySQL client connections. The time is specified in seconds. The default value is
30. -
Command-Line Format --ndb-wait-setup=#System Variable ndb_wait_setupScope Global Dynamic No Type Integer Default Value 30Default Value 30Default Value 15Default Value 15Minimum Value 0Maximum Value 31536000Unit seconds This variable shows the period of time that the MySQL server waits for the
NDBstorage engine to complete setup before timing out and treatingNDBas unavailable. The time is specified in seconds. The default value is30. -
Command-Line Format --skip-ndbclusterDisable the
NDBCLUSTERstorage engine. This is the default for binaries that were built withNDBCLUSTERstorage engine support; the server allocates memory and other resources for this storage engine only if the--ndbclusteroption is given explicitly. See Section 21.4.1, “Quick Test Setup of NDB Cluster”, for an example.
This section provides detailed information about MySQL server
system variables that are specific to NDB Cluster and the
NDB storage engine. For system
variables not specific to NDB Cluster, see
Section 5.1.7, “Server System Variables”. For general information
on using system variables, see
Section 5.1.8, “Using System Variables”.
-
Command-Line Format --ndb-autoincrement-prefetch-sz=#System Variable ndb_autoincrement_prefetch_szScope Global, Session Dynamic Yes Type Integer Default Value 1Minimum Value 1Maximum Value 65536Determines the probability of gaps in an autoincremented column. Set it to
1to minimize this. Setting it to a high value for optimization makes inserts faster, but decreases the likelihood that consecutive autoincrement numbers are used in a batch of inserts.This variable affects only the number of
AUTO_INCREMENTIDs that are fetched between statements; within a given statement, at least 32 IDs are obtained at a time.ImportantThis variable does not affect inserts performed using
INSERT ... SELECT. -
Command-Line Format --ndb-cache-check-time=#Deprecated 5.7.20 System Variable ndb_cache_check_timeScope Global Dynamic Yes Type Integer Default Value 0Minimum Value 0Maximum Value 31536000Unit milliseconds The number of milliseconds that elapse between checks of NDB Cluster SQL nodes by the MySQL query cache. Setting this to 0 (the default and minimum value) means that the query cache checks for validation on every query.
The recommended maximum value for this variable is 1000, which means that the check is performed once per second. A larger value means that the check is performed and possibly invalidated due to updates on different SQL nodes less often. It is generally not desirable to set this to a value greater than 2000.
NoteThe query cache is deprecated as of MySQL 5.7.20, and is removed in MySQL 8.0. Deprecation includes
ndb_cache_check_time. -
Command-Line Format --ndb-clear-apply-status[={OFF|ON}]System Variable ndb_clear_apply_statusScope Global Dynamic Yes Type Boolean Default Value ONBy the default, executing
RESET SLAVEcauses an NDB Cluster replica to purge all rows from itsndb_apply_statustable. You can disable this by settingndb_clear_apply_status=OFF. -
Command-Line Format --ndb-data-node-neighbour=#Introduced 5.7.12-ndb-7.5.2 System Variable ndb_data_node_neighbourScope Global Dynamic Yes Type Integer Default Value 0Minimum Value 0Maximum Value 255Sets the ID of a “nearest” data node—that is, a preferred nonlocal data node is chosen to execute the transaction, rather than one running on the same host as the SQL or API node. This used to ensure that when a fully replicated table is accessed, we access it on this data node, to ensure that the local copy of the table is always used whenever possible. This can also be used for providing hints for transactions.
This can improve data access times in the case of a node that is physically closer than and thus has higher network throughput than others on the same host.
See Section 13.1.18.9, “Setting NDB Comment Options”, for further information.
Added in NDB 7.5.2.
NoteAn equivalent method
set_data_node_neighbour()is provided for use in NDB API applications. -
Command-Line Format --ndb-default-column-format={FIXED|DYNAMIC}Introduced 5.7.11-ndb-7.5.1 System Variable ndb_default_column_formatScope Global Dynamic Yes Type Enumeration Default Value (≥ 5.7.16-ndb-7.5.4) FIXEDDefault Value (≥ 5.7.11-ndb-7.5.1, ≤ 5.7.13-ndb-7.5.3) DYNAMICValid Values FIXEDDYNAMICIn NDB 7.5.1 and later, sets the default
COLUMN_FORMATandROW_FORMATfor new tables (see Section 13.1.18, “CREATE TABLE Statement”).In NDB 7.5.1, the default for this variable was
DYNAMIC; in NDB 7.5.4, the default was changed toFIXEDto maintain backwards compatibility with older release series (Bug #24487363). -
Command-Line Format --ndb-deferred-constraints=#System Variable ndb_deferred_constraintsScope Global, Session Dynamic Yes Type Integer Default Value 0Minimum Value 0Maximum Value 1Controls whether or not constraint checks are deferred, where these are supported.
0is the default.This variable is not normally needed for operation of NDB Cluster or NDB Cluster Replication, and is intended primarily for use in testing.
-
Command-Line Format --ndb-distribution={KEYHASH|LINHASH}System Variable ndb_distributionScope Global Dynamic Yes Type Enumeration Default Value KEYHASHValid Values LINHASHKEYHASHControls the default distribution method for
NDBtables. Can be set to either ofKEYHASH(key hashing) orLINHASH(linear hashing).KEYHASHis the default. -
Command-Line Format --ndb-eventbuffer-free-percent=#System Variable ndb_eventbuffer_free_percentScope Global Dynamic Yes Type Integer Default Value 20Minimum Value 1Maximum Value 99Sets the percentage of the maximum memory allocated to the event buffer (ndb_eventbuffer_max_alloc) that should be available in event buffer after reaching the maximum, before starting to buffer again.
-
Command-Line Format --ndb-eventbuffer-max-alloc=#System Variable ndb_eventbuffer_max_allocScope Global Dynamic Yes Type Integer Default Value 0Minimum Value 0Maximum Value (≥ 5.7.35-ndb-7.6.19) 9223372036854775807Maximum Value (≥ 5.7.35-ndb-7.5.23) 9223372036854775807Maximum Value (≤ 5.7.34-ndb-7.5.22) 4294967295Maximum Value (≤ 5.7.34-ndb-7.6.18) 4294967295Maximum Value 4294967295Sets the maximum amount memory (in bytes) that can be allocated for buffering events by the NDB API. 0 means that no limit is imposed, and is the default.
-
Command-Line Format ndb_extra_logging=#System Variable ndb_extra_loggingScope Global Dynamic Yes Type Integer Default Value 1Minimum Value 0Maximum Value 1This variable enables recording in the MySQL error log of information specific to the
NDBstorage engine.When this variable is set to 0, the only information specific to
NDBthat is written to the MySQL error log relates to transaction handling. If it set to a value greater than 0 but less than 10,NDBtable schema and connection events are also logged, as well as whether or not conflict resolution is in use, and otherNDBerrors and information. If the value is set to 10 or more, information aboutNDBinternals, such as the progress of data distribution among cluster nodes, is also written to the MySQL error log. The default is 1. -
Command-Line Format --ndb-force-send[={OFF|ON}]System Variable ndb_force_sendScope Global, Session Dynamic Yes Type Boolean Default Value ONForces sending of buffers to
NDBimmediately, without waiting for other threads. Defaults toON. -
Command-Line Format --ndb-fully-replicated[={OFF|ON}]Introduced 5.7.12-ndb-7.5.2 System Variable ndb_fully_replicatedScope Global, Session Dynamic Yes Type Boolean Default Value OFFDetermines whether new
NDBtables are fully replicated. This setting can be overridden for an individual table usingCOMMENT="NDB_TABLE=FULLY_REPLICATED=..."in aCREATE TABLEorALTER TABLEstatement; see Section 13.1.18.9, “Setting NDB Comment Options”, for syntax and other information.Added in NDB 7.5.2.
-
Command-Line Format --ndb-index-stat-enable[={OFF|ON}]System Variable ndb_index_stat_enableScope Global, Session Dynamic Yes Type Boolean Default Value ONUse
NDBindex statistics in query optimization. The default isON. -
Command-Line Format --ndb-index-stat-option=valueSystem Variable ndb_index_stat_optionScope Global, Session Dynamic Yes Type String Default Value loop_checkon=1000ms,loop_idle=1000ms,loop_busy=100ms, update_batch=1,read_batch=4,idle_batch=32,check_batch=32, check_delay=1m,delete_batch=8,clean_delay=0,error_batch=4, error_delay=1m,evict_batch=8,evict_delay=1m,cache_limit=32M, cache_lowpct=90This variable is used for providing tuning options for NDB index statistics generation. The list consist of comma-separated name-value pairs of option names and values, and this list must not contain any space characters.
Options not used when setting
ndb_index_stat_optionare not changed from their default values. For example, you can setndb_index_stat_option = 'loop_idle=1000ms,cache_limit=32M'.Time values can be optionally suffixed with
h(hours),m(minutes), ors(seconds). Millisecond values can optionally be specified usingms; millisecond values cannot be specified usingh,m, ors.) Integer values can be suffixed withK,M, orG.The names of the options that can be set using this variable are shown in the table that follows. The table also provides brief descriptions of the options, their default values, and (where applicable) their minimum and maximum values.
Table 21.18 ndb_index_stat_option options and values
Name Description Default/Units Minimum/Maximum loop_enable1000 ms 0/4G loop_idleTime to sleep when idle 1000 ms 0/4G loop_busyTime to sleep when more work is waiting 100 ms 0/4G update_batch1 0/4G read_batch4 1/4G idle_batch32 1/4G check_batch8 1/4G check_delayHow often to check for new statistics 10 m 1/4G delete_batch8 0/4G clean_delay1 m 0/4G error_batch4 1/4G error_delay1 m 1/4G evict_batch8 1/4G evict_delayClean LRU cache, from read time 1 m 0/4G cache_limitMaximum amount of memory in bytes used for cached index statistics by this mysqld; clean up the cache when this is exceeded. 32 M 0/4G cache_lowpct90 0/100 zero_totalSetting this to 1 resets all accumulating counters in ndb_index_stat_statusto 0. This option value is also reset to 0 when this is done.0 0/1 -
System Variable ndb_join_pushdownScope Global, Session Dynamic Yes Type Boolean Default Value ONThis variable controls whether joins on
NDBtables are pushed down to the NDB kernel (data nodes). Previously, a join was handled using multiple accesses ofNDBby the SQL node; however, whenndb_join_pushdownis enabled, a pushable join is sent in its entirety to the data nodes, where it can be distributed among the data nodes and executed in parallel on multiple copies of the data, with a single, merged result being returned to mysqld. This can reduce greatly the number of round trips between an SQL node and the data nodes required to handle such a join.By default,
ndb_join_pushdownis enabled.Conditions for NDB pushdown joins. In order for a join to be pushable, it must meet the following conditions:
Only columns can be compared, and all columns to be joined must use exactly the same data type.
This means that expressions such as
t1.a = t2.a +cannot be pushed down, and that (for example) a join on anconstantINTcolumn and aBIGINTcolumn also cannot be pushed down.Explicit locking is not supported; however, the
NDBstorage engine's characteristic implicit row-based locking is enforced.This means that a join using
FOR UPDATEcannot be pushed down.In order for a join to be pushed down, child tables in the join must be accessed using one of the
ref,eq_ref, orconstaccess methods, or some combination of these methods.Outer joined child tables can only be pushed using
eq_ref.If the root of the pushed join is an
eq_reforconst, only child tables joined byeq_refcan be appended. (A table joined byrefis likely to become the root of another pushed join.)If the query optimizer decides on
Using join cachefor a candidate child table, that table cannot be pushed as a child. However, it may be the root of another set of pushed tables.Joins referencing tables explicitly partitioned by
[LINEAR] HASH,LIST, orRANGEcurrently cannot be pushed down.
You can see whether a given join can be pushed down by checking it with
EXPLAIN; when the join can be pushed down, you can see references to thepushed joinin theExtracolumn of the output, as shown in this example:mysql> EXPLAIN -> SELECT e.first_name, e.last_name, t.title, d.dept_name -> FROM employees e -> JOIN dept_emp de ON e.emp_no=de.emp_no -> JOIN departments d ON d.dept_no=de.dept_no -> JOIN titles t ON e.emp_no=t.emp_no\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: d type: ALL possible_keys: PRIMARY key: NULL key_len: NULL ref: NULL rows: 9 Extra: Parent of 4 pushed join@1 *************************** 2. row *************************** id: 1 select_type: SIMPLE table: de type: ref possible_keys: PRIMARY,emp_no,dept_no key: dept_no key_len: 4 ref: employees.d.dept_no rows: 5305 Extra: Child of 'd' in pushed join@1 *************************** 3. row *************************** id: 1 select_type: SIMPLE table: e type: eq_ref possible_keys: PRIMARY key: PRIMARY key_len: 4 ref: employees.de.emp_no rows: 1 Extra: Child of 'de' in pushed join@1 *************************** 4. row *************************** id: 1 select_type: SIMPLE table: t type: ref possible_keys: PRIMARY,emp_no key: emp_no key_len: 4 ref: employees.de.emp_no rows: 19 Extra: Child of 'e' in pushed join@1 4 rows in set (0.00 sec)NoteIf inner joined child tables are joined by
ref, and the result is ordered or grouped by a sorted index, this index cannot provide sorted rows, which forces writing to a sorted tempfile.Two additional sources of information about pushed join performance are available:
The status variables
Ndb_pushed_queries_defined,Ndb_pushed_queries_dropped,Ndb_pushed_queries_executed, andNdb_pushed_reads.The counters in the
ndbinfo.counterstable that belong to theDBSPJkernel block.
-
Command-Line Format --ndb-log-apply-status[={OFF|ON}]System Variable ndb_log_apply_statusScope Global Dynamic No Type Boolean Default Value OFFA read-only variable which shows whether the server was started with the
--ndb-log-apply-statusoption. -
Command-Line Format --ndb-log-bin[={OFF|ON}]System Variable ndb_log_binScope Global, Session Dynamic No Type Boolean Default Value ONCauses updates to
NDBtables to be written to the binary log. Setting this variable has no effect if binary logging is not already enabled for the server usinglog_bin.ndb_log_bindefaults to 1 (ON); normally, there is never any need to change this value in a production environment. -
Command-Line Format --ndb-log-binlog-index[={OFF|ON}]System Variable ndb_log_binlog_indexScope Global Dynamic Yes Type Boolean Default Value ONCauses a mapping of epochs to positions in the binary log to be inserted into the
ndb_binlog_indextable. Setting this variable has no effect if binary logging is not already enabled for the server usinglog_bin. (In addition,ndb_log_binmust not be disabled.)ndb_log_binlog_indexdefaults to1(ON); normally, there is never any need to change this value in a production environment. -
Command-Line Format --ndb-log-empty-epochs[={OFF|ON}]System Variable ndb_log_empty_epochsScope Global Dynamic Yes Type Boolean Default Value OFFWhen this variable is set to 0, epoch transactions with no changes are not written to the binary log, although a row is still written even for an empty epoch in
ndb_binlog_index. -
Command-Line Format --ndb-log-empty-update[={OFF|ON}]System Variable ndb_log_empty_updateScope Global Dynamic Yes Type Boolean Default Value OFFWhen this variable is set to
ON(1), update transactions with no changes are written to the binary log, even whenlog_slave_updatesis enabled. -
Command-Line Format --ndb-log-exclusive-reads[={OFF|ON}]System Variable ndb_log_exclusive_readsScope Global, Session Dynamic Yes Type Boolean Default Value 0This variable determines whether primary key reads are logged with exclusive locks, which allows for NDB Cluster Replication conflict detection and resolution based on read conflicts. To enable these locks, set the value of
ndb_log_exclusive_readsto 1. 0, which disables such locking, is the default.For more information, see Read conflict detection and resolution.
-
Command-Line Format --ndb-log-orig[={OFF|ON}]System Variable ndb_log_origScope Global Dynamic No Type Boolean Default Value OFFShows whether the originating server ID and epoch are logged in the
ndb_binlog_indextable. Set using the--ndb-log-origserver option. -
System Variable ndb_log_transaction_idScope Global Dynamic No Type Boolean Default Value OFFThis read-only, Boolean system variable shows whether a replica mysqld writes NDB transaction IDs in the binary log (required to use “active-active” NDB Cluster Replication with
NDB$EPOCH_TRANS()conflict detection). To change the setting, use the--ndb-log-transaction-idoption.ndb_log_transaction_idis not supported in mainline MySQL Server 5.7.For more information, see Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
-
Command-Line Format --ndb-optimized-node-selection=#System Variable ndb_optimized_node_selectionScope Global Dynamic No Type Integer Default Value 3Minimum Value 0Maximum Value 3There are two forms of optimized node selection, described here:
The SQL node uses promixity to determine the transaction coordinator; that is, the “closest” data node to the SQL node is chosen as the transaction coordinator. For this purpose, a data node having a shared memory connection with the SQL node is considered to be “closest” to the SQL node; the next closest (in order of decreasing proximity) are: TCP connection to
localhost, followed by TCP connection from a host other thanlocalhost.The SQL thread uses distribution awareness to select the data node. That is, the data node housing the cluster partition accessed by the first statement of a given transaction is used as the transaction coordinator for the entire transaction. (This is effective only if the first statement of the transaction accesses no more than one cluster partition.)
This option takes one of the integer values
0,1,2, or3.3is the default. These values affect node selection as follows:0: Node selection is not optimized. Each data node is employed as the transaction coordinator 8 times before the SQL thread proceeds to the next data node.1: Proximity to the SQL node is used to determine the transaction coordinator.2: Distribution awareness is used to select the transaction coordinator. However, if the first statement of the transaction accesses more than one cluster partition, the SQL node reverts to the round-robin behavior seen when this option is set to0.3: If distribution awareness can be employed to determine the transaction coordinator, then it is used; otherwise proximity is used to select the transaction coordinator. (This is the default behavior.)
Proximity is determined as follows:
Start with the value set for the
Groupparameter (default 55).For an API node sharing the same host with other API nodes, decrement the value by 1. Assuming the default value for
Group, the effective value for data nodes on same host as the API node is 54, and for remote data nodes 55.(NDB 7.5.2 and later:) Setting
ndb_data_node_neighbourfurther decreases the effectiveGroupvalue by 50, causing this node to be regarded as the nearest node. This is needed only when all data nodes are on hosts other than that hosts the API node and it is desirable to dedicate one of them to the API node. In normal cases, the default adjustment described previously is sufficient.
Frequent changes in
ndb_data_node_neighbourare not advisable, since this changes the state of the cluster connection and thus may disrupt the selection algorithm for new transactions from each thread until it stablilizes. -
Command-Line Format --ndb-read-backup[={OFF|ON}]Introduced 5.7.12-ndb-7.5.2 System Variable ndb_read_backupScope Global Dynamic Yes Type Boolean Default Value OFFEnable read from any fragment replica for any
NDBtable subsequently created; doing so greatly improves the table read performance at a relatively small cost to writes.If the SQL node and the data node use the same host name or IP address, this fact is detected automatically, so that the preference is to send reads to the same host. If these nodes are on the same host but use different IP addresses, you can tell the SQL node to use the correct data node by setting the value of
ndb_data_node_neighbouron the SQL node to the node ID of the data node.To enable or disable read from any fragment replica for an individual table, you can set the
NDB_TABLEoptionREAD_BACKUPfor the table accordingly, in aCREATE TABLEorALTER TABLEstatement; see Section 13.1.18.9, “Setting NDB Comment Options”, for more information.Added in NDB 7.5.2.
ndb_recv_thread_activation_thresholdCommand-Line Format --ndb-recv-thread-activation-threshold=#System Variable ndb_recv_thread_activation_thresholdScope Global Dynamic Yes Type Integer Default Value 8Minimum Value 0 (MIN_ACTIVATION_THRESHOLD)Maximum Value 16 (MAX_ACTIVATION_THRESHOLD)When this number of concurrently active threads is reached, the receive thread takes over polling of the cluster connection.
This variable is global in scope. It can also be set at startup.
-
Command-Line Format --ndb-recv-thread-cpu-mask=maskSystem Variable ndb_recv_thread_cpu_maskScope Global Dynamic Yes Type Bitmap Default Value [empty]CPU mask for locking receiver threads to specific CPUs. This is specified as a hexadecimal bitmask. For example,
0x33means that one CPU is used per receiver thread. An empty string is the default; settingndb_recv_thread_cpu_maskto this value removes any receiver thread locks previously set.This variable is global in scope. It can also be set at startup.
ndb_report_thresh_binlog_epoch_slipCommand-Line Format --ndb-report-thresh-binlog-epoch-slip=#System Variable ndb_report_thresh_binlog_epoch_slipScope Global Dynamic Yes Type Integer Default Value (≥ 5.7.16-ndb-7.5.4) 10Default Value (≤ 5.7.13-ndb-7.5.3) 3Minimum Value 0Maximum Value 256In NDB 7.5.4 and later, this represents the threshold for the number of epochs completely buffered in the event buffer, but not yet consumed by the binlog injector thread. When this degree of slippage (lag) is exceeded, an event buffer status message is reported, with
BUFFERED_EPOCHS_OVER_THRESHOLDsupplied as the reason (see Section 21.6.2.3, “Event Buffer Reporting in the Cluster Log”). Slip is increased when an epoch is received from data nodes and buffered completely in the event buffer; it is decreased when an epoch is consumed by the binlog injector thread, it is reduced. Empty epochs are buffered and queued, and so included in this calculation only when this is enabled using theNdb::setEventBufferQueueEmptyEpoch()method from the NDB API.Prior to NDB 7.5.4, the value of this vairable served as a threshold for the number of epochs to be behind before reporting binary log status. In these previous releases, a value of
3—the default—means that if the difference between which epoch has been received from the storage nodes and which epoch has been applied to the binary log is 3 or more, a status message is then sent to the cluster log.ndb_report_thresh_binlog_mem_usageCommand-Line Format --ndb-report-thresh-binlog-mem-usage=#System Variable ndb_report_thresh_binlog_mem_usageScope Global Dynamic Yes Type Integer Default Value 10Minimum Value 0Maximum Value 10This is a threshold on the percentage of free memory remaining before reporting binary log status. For example, a value of
10(the default) means that if the amount of available memory for receiving binary log data from the data nodes falls below 10%, a status message is sent to the cluster log.-
Introduced 5.7.23-ndb-7.6.8 System Variable ndb_row_checksumScope Global, Session Dynamic Yes Type Integer Default Value 1Minimum Value 0Maximum Value 1Traditionally,
NDBhas created tables with row checksums, which checks for hardware issues at the expense of performance. Settingndb_row_checksumto 0 means that row checksums are not used for new or altered tables, which has a significant impact on performance for all types of queries. This variable is set to 1 by default, to provide backward-compatible behavior. ndb_show_foreign_key_mock_tablesCommand-Line Format --ndb-show-foreign-key-mock-tables[={OFF|ON}]System Variable ndb_show_foreign_key_mock_tablesScope Global Dynamic Yes Type Boolean Default Value OFFShow the mock tables used by
NDBto supportforeign_key_checks=0. When this is enabled, extra warnings are shown when creating and dropping the tables. The real (internal) name of the table can be seen in the output ofSHOW CREATE TABLE.-
Command-Line Format --ndb-slave-conflict-role=valueSystem Variable ndb_slave_conflict_roleScope Global Dynamic Yes Type Enumeration Default Value NONEValid Values NONEPRIMARYSECONDARYPASSDetermine the role of this SQL node (and NDB Cluster) in a circular (“active-active”) replication setup.
ndb_slave_conflict_rolecan take any one of the valuesPRIMARY,SECONDARY,PASS, orNULL(the default). The replica SQL thread must be stopped before you can changendb_slave_conflict_role. In addition, it is not possible to change directly betweenPASSand either ofPRIMARYorSECONDARYdirectly; in such cases, you must ensure that the SQL thread is stopped, then executeSET @@GLOBAL.ndb_slave_conflict_role = 'NONE'first.For more information, see Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
-
System Variable ndb_table_no_loggingScope Session Dynamic Yes Type Boolean Default Value OFFWhen this variable is set to
ONor1, it causes all tables created or altered usingENGINE NDBto be nonlogging; that is, no data changes for this table are written to the redo log or checkpointed to disk, just as if the table had been created or altered using theNOLOGGINGoption forCREATE TABLEorALTER TABLE.For more information about nonlogging
NDBtables, see NDB_TABLE Options.ndb_table_no_logginghas no effect on the creation ofNDBtable schema files; to suppress these, usendb_table_temporaryinstead. -
System Variable ndb_table_temporaryScope Session Dynamic Yes Type Boolean Default Value OFFWhen set to
ONor1, this variable causesNDBtables not to be written to disk: This means that no table schema files are created, and that the tables are not logged.NoteSetting this variable currently has no effect. This is a known issue; see Bug #34036.
-
System Variable ndb_use_copying_alter_tableScope Global, Session Dynamic No Forces
NDBto use copying of tables in the event of problems with onlineALTER TABLEoperations. The default value isOFF. -
System Variable ndb_use_exact_countScope Global, Session Dynamic Yes Type Boolean Default Value OFFForces
NDBto use a count of records duringSELECT COUNT(*)query planning to speed up this type of query. The default value isOFF, which allows for faster queries overall. -
Command-Line Format --ndb-use-transactions[={OFF|ON}]System Variable ndb_use_transactionsScope Global, Session Dynamic Yes Type Boolean Default Value ONYou can disable
NDBtransaction support by setting this variable's value toOFF. This is generally not recommended, although it may be useful to disable transaction support within a given client session when that session is used to import one or more dump files with large transactions; this allows a multi-row insert to be executed in parts, rather than as a single transaction. In such cases, once the import has been completed, you should either reset the variable value for this session toON, or simply terminate the session. -
System Variable ndb_versionScope Global Dynamic No Type String Default Value NDBengine version, as a composite integer. -
System Variable ndb_version_stringScope Global Dynamic No Type String Default Value NDBengine version inndb-format.x.y.z -
Command-Line Format --server-id-bits=#System Variable server_id_bitsScope Global Dynamic No Type Integer Default Value 32Minimum Value 7Maximum Value 32This variable indicates the number of least significant bits within the 32-bit
server_idwhich actually identify the server. Indicating that the server is actually identified by fewer than 32 bits makes it possible for some of the remaining bits to be used for other purposes, such as storing user data generated by applications using the NDB API's Event API within theAnyValueof anOperationOptionsstructure (NDB Cluster uses theAnyValueto store the server ID).When extracting the effective server ID from
server_idfor purposes such as detection of replication loops, the server ignores the remaining bits. Theserver_id_bitsvariable is used to mask out any irrelevant bits ofserver_idin the I/O and SQL threads when deciding whether an event should be ignored based on the server ID.This data can be read from the binary log by mysqlbinlog, provided that it is run with its own
server_id_bitsvariable set to 32 (the default).If the value of
server_idgreater than or equal to 2 to the power ofserver_id_bits; otherwise, mysqld refuses to start.This system variable is supported only by NDB Cluster. It is not supported in the standard MySQL 5.7 Server.
-
Command-Line Format --slave-allow-batching[={OFF|ON}]System Variable slave_allow_batchingScope Global Dynamic Yes Type Boolean Default Value OFFWhether or not batched updates are enabled on NDB Cluster replicas.
Allowing batched updates on the replica greatly improves performance, particularly when replicating
TEXT,BLOB, andJSONcolumns. For this reason, you should always enableslave_allow_batchingwhen using NDB replication. Beginning with NDB 7.6.23, a warning is issued whenever this variable is set toOFF.Setting this variable has an effect only when using replication with the
NDBstorage engine; in MySQL Server 5.7, it is present but does nothing. For more information, see Section 21.7.6, “Starting NDB Cluster Replication (Single Replication Channel)”. -
System Variable transaction_allow_batchingScope Session Dynamic Yes Type Boolean Default Value OFFWhen set to
1orON, this variable enables batching of statements within the same transaction. To use this variable,autocommitmust first be disabled by setting it to0orOFF; otherwise, settingtransaction_allow_batchinghas no effect.It is safe to use this variable with transactions that performs writes only, as having it enabled can lead to reads from the “before” image. You should ensure that any pending transactions are committed (using an explicit
COMMITif desired) before issuing aSELECT.Importanttransaction_allow_batchingshould not be used whenever there is the possibility that the effects of a given statement depend on the outcome of a previous statement within the same transaction.This variable is currently supported for NDB Cluster only.
The system variables in the following list all relate to the
ndbinfo information database.
-
System Variable ndbinfo_databaseScope Global Dynamic No Type String Default Value ndbinfoShows the name used for the
NDBinformation database; the default isndbinfo. This is a read-only variable whose value is determined at compile time. -
Command-Line Format --ndbinfo-max-bytes=#System Variable ndbinfo_max_bytesScope Global, Session Dynamic Yes Type Integer Default Value 0Minimum Value 0Maximum Value 65535Used in testing and debugging only.
-
Command-Line Format --ndbinfo-max-rows=#System Variable ndbinfo_max_rowsScope Global, Session Dynamic Yes Type Integer Default Value 10Minimum Value 1Maximum Value 256Used in testing and debugging only.
-
System Variable ndbinfo_offlineScope Global Dynamic Yes Type Boolean Default Value OFFPlace the
ndbinfodatabase into offline mode, in which tables and views can be opened even when they do not actually exist, or when they exist but have different definitions inNDB. No rows are returned from such tables (or views). -
Command-Line Format --ndbinfo-show-hidden[={OFF|ON}]System Variable ndbinfo_show_hiddenScope Global, Session Dynamic Yes Type Boolean Default Value OFFValid Values ONOFFWhether or not the
ndbinfodatabase's underlying internal tables are shown in the mysql client. The default isOFF.NoteWhen
ndbinfo_show_hiddenis enabled, the internal tables are shown in thendbinfodatabase only; they are not visible inTABLESor otherINFORMATION_SCHEMAtables, regardless of the variable's setting. -
System Variable ndbinfo_table_prefixScope Global Dynamic No Type String Default Value ndb$The prefix used in naming the ndbinfo database's base tables (normally hidden, unless exposed by setting
ndbinfo_show_hidden). This is a read-only variable whose default value isndb$; the prefix itself is determined at compile time. -
System Variable ndbinfo_versionScope Global Dynamic No Type String Default Value Shows the version of the
ndbinfoengine in use; read-only.
This section provides detailed information about MySQL server
status variables that relate to NDB Cluster and the
NDB storage engine. For status
variables not specific to NDB Cluster, and for general information
on using status variables, see
Section 5.1.9, “Server Status Variables”.
The MySQL server can ask the
NDBCLUSTERstorage engine if it knows about a table with a given name. This is called discovery.Handler_discoverindicates the number of times that tables have been discovered using this mechanism.Ndb_api_adaptive_send_deferred_countNumber of adaptive send calls that were not actually sent.
For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_adaptive_send_deferred_count_sessionNumber of adaptive send calls that were not actually sent.
For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_adaptive_send_deferred_count_slaveNumber of adaptive send calls that were not actually sent by this replica.
For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_adaptive_send_forced_countNumber of adaptive send calls using forced-send sent by this MySQL Server (SQL node).
For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_adaptive_send_forced_count_sessionNumber of adaptive send calls using forced-send sent in this client session.
For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_adaptive_send_forced_count_slaveNumber of adaptive send calls using forced-send sent by this replica.
For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_adaptive_send_unforced_countNumber of adaptive send calls without forced-send sent by this MySQL server (SQL node).
For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_adaptive_send_unforced_count_sessionNumber of adaptive send calls without forced-send sent in this client session.
For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_adaptive_send_unforced_count_slaveNumber of adaptive send calls without forced-send sent by this replica.
For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_bytes_sent_count_sessionAmount of data (in bytes) sent to the data nodes in this client session.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_bytes_sent_count_slaveAmount of data (in bytes) sent to the data nodes by this replica.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Amount of data (in bytes) sent to the data nodes by this MySQL Server (SQL node).
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_bytes_received_count_sessionAmount of data (in bytes) received from the data nodes in this client session.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_bytes_received_count_slaveAmount of data (in bytes) received from the data nodes by this replica.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Amount of data (in bytes) received from the data nodes by this MySQL Server (SQL node).
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_event_data_count_injectorThe number of row change events received by the NDB binlog injector thread.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of row change events received by this MySQL Server (SQL node).
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_event_nondata_count_injectorThe number of events received, other than row change events, by the NDB binary log injector thread.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of events received, other than row change events, by this MySQL Server (SQL node).
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_event_bytes_count_injectorThe number of bytes of events received by the NDB binlog injector thread.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of bytes of events received by this MySQL Server (SQL node).
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of operations in this client session based on or using primary keys. This includes operations on blob tables, implicit unlock operations, and auto-increment operations, as well as user-visible primary key operations.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of operations by this replica based on or using primary keys. This includes operations on blob tables, implicit unlock operations, and auto-increment operations, as well as user-visible primary key operations.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of operations by this MySQL Server (SQL node) based on or using primary keys. This includes operations on blob tables, implicit unlock operations, and auto-increment operations, as well as user-visible primary key operations.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_pruned_scan_count_sessionThe number of scans in this client session that have been pruned to a single partition.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_pruned_scan_count_slaveThe number of scans by this replica that have been pruned to a single partition.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of scans by this MySQL Server (SQL node) that have been pruned to a single partition.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_range_scan_count_sessionThe number of range scans that have been started in this client session.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_range_scan_count_slaveThe number of range scans that have been started by this replica.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of range scans that have been started by this MySQL Server (SQL node).
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_read_row_count_sessionThe total number of rows that have been read in this client session. This includes all rows read by any primary key, unique key, or scan operation made in this client session.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The total number of rows that have been read by this replica. This includes all rows read by any primary key, unique key, or scan operation made by this replica.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The total number of rows that have been read by this MySQL Server (SQL node). This includes all rows read by any primary key, unique key, or scan operation made by this MySQL Server (SQL node).
You should be aware that this value may not be completely accurate with regard to rows read by
SELECTCOUNT(*)queries, due to the fact that, in this case, the MySQL server actually reads pseudo-rows in the form[and sums the rows per fragment for all fragments in the table to derive an estimated count for all rows.table fragment ID]:[number of rows in fragment]Ndb_api_read_row_countuses this estimate and not the actual number of rows in the table.Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_scan_batch_count_sessionThe number of batches of rows received in this client session. 1 batch is defined as 1 set of scan results from a single fragment.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_scan_batch_count_slaveThe number of batches of rows received by this replica. 1 batch is defined as 1 set of scan results from a single fragment.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of batches of rows received by this MySQL Server (SQL node). 1 batch is defined as 1 set of scan results from a single fragment.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_table_scan_count_sessionThe number of table scans that have been started in this client session, including scans of internal tables,.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_table_scan_count_slaveThe number of table scans that have been started by this replica, including scans of internal tables,.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of table scans that have been started by this MySQL Server (SQL node), including scans of internal tables,.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_trans_abort_count_sessionThe number of transactions aborted in this client session.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_trans_abort_count_slaveThe number of transactions aborted by this replica.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of transactions aborted by this MySQL Server (SQL node).
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_trans_close_count_sessionThe number of transactions closed in this client session. This value may be greater than the sum of
Ndb_api_trans_commit_count_sessionandNdb_api_trans_abort_count_session, since some transactions may have been rolled back.Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_trans_close_count_slaveThe number of transactions closed by this replica. This value may be greater than the sum of
Ndb_api_trans_commit_count_slaveandNdb_api_trans_abort_count_slave, since some transactions may have been rolled back.Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of transactions closed by this MySQL Server (SQL node). This value may be greater than the sum of
Ndb_api_trans_commit_countandNdb_api_trans_abort_count, since some transactions may have been rolled back.Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_trans_commit_count_sessionThe number of transactions committed in this client session.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_trans_commit_count_slaveThe number of transactions committed by this replica.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of transactions committed by this MySQL Server (SQL node).
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_trans_local_read_row_count_sessionThe total number of rows that have been read in this client session. This includes all rows read by any primary key, unique key, or scan operation made in this client session.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_trans_local_read_row_count_slaveThe total number of rows that have been read by this replica. This includes all rows read by any primary key, unique key, or scan operation made by this replica.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_trans_local_read_row_countThe total number of rows that have been read by this MySQL Server (SQL node). This includes all rows read by any primary key, unique key, or scan operation made by this MySQL Server (SQL node).
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_trans_start_count_sessionThe number of transactions started in this client session.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_trans_start_count_slaveThe number of transactions started by this replica.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of transactions started by this MySQL Server (SQL node).
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of operations in this client session based on or using unique keys.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of operations by this replica based on or using unique keys.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
The number of operations by this MySQL Server (SQL node) based on or using unique keys.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_wait_exec_complete_count_sessionThe number of times a thread has been blocked in this client session while waiting for execution of an operation to complete. This includes all
execute()calls as well as implicit executes for blob and auto-increment operations not visible to clients.Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_wait_exec_complete_count_slaveThe number of times a thread has been blocked by this replica while waiting for execution of an operation to complete. This includes all
execute()calls as well as implicit executes for blob and auto-increment operations not visible to clients.Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_wait_exec_complete_countThe number of times a thread has been blocked by this MySQL Server (SQL node) while waiting for execution of an operation to complete. This includes all
execute()calls as well as implicit executes for blob and auto-increment operations not visible to clients.Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_wait_meta_request_count_sessionThe number of times a thread has been blocked in this client session waiting for a metadata-based signal, such as is expected for DDL requests, new epochs, and seizure of transaction records.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_wait_meta_request_count_slaveThe number of times a thread has been blocked by this replica waiting for a metadata-based signal, such as is expected for DDL requests, new epochs, and seizure of transaction records.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_wait_meta_request_countThe number of times a thread has been blocked by this MySQL Server (SQL node) waiting for a metadata-based signal, such as is expected for DDL requests, new epochs, and seizure of transaction records.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_wait_nanos_count_sessionTotal time (in nanoseconds) spent in this client session waiting for any type of signal from the data nodes.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_wait_nanos_count_slaveTotal time (in nanoseconds) spent by this replica waiting for any type of signal from the data nodes.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Total time (in nanoseconds) spent by this MySQL Server (SQL node) waiting for any type of signal from the data nodes.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_wait_scan_result_count_sessionThe number of times a thread has been blocked in this client session while waiting for a scan-based signal, such as when waiting for more results from a scan, or when waiting for a scan to close.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it relates to the current session only, and is not affected by any other clients of this mysqld.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_wait_scan_result_count_slaveThe number of times a thread has been blocked by this replica while waiting for a scan-based signal, such as when waiting for more results from a scan, or when waiting for a scan to close.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope. If this MySQL server does not act as a replica, or does not use NDB tables, this value is always 0.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
Ndb_api_wait_scan_result_countThe number of times a thread has been blocked by this MySQL Server (SQL node) while waiting for a scan-based signal, such as when waiting for more results from a scan, or when waiting for a scan to close.
Although this variable can be read using either
SHOW GLOBAL STATUSorSHOW SESSION STATUS, it is effectively global in scope.For more information, see Section 21.6.14, “NDB API Statistics Counters and Variables”.
If the server is acting as an NDB Cluster node, then the value of this variable its node ID in the cluster.
If the server is not part of an NDB Cluster, then the value of this variable is 0.
If the server is part of an NDB Cluster, the value of this variable is the host name or IP address of the Cluster management server from which it gets its configuration data.
If the server is not part of an NDB Cluster, then the value of this variable is an empty string.
If the server is part of an NDB Cluster, the value of this variable is the number of the port through which it is connected to the Cluster management server from which it gets its configuration data.
If the server is not part of an NDB Cluster, then the value of this variable is 0.
Used in NDB Cluster Replication conflict resolution, this variable shows the number of rows found to be in conflict using
NDB$EPOCH()conflict resolution on a given mysqld since the last time it was restarted.For more information, see Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
Used in NDB Cluster Replication conflict resolution, this variable shows the number of rows found to be in conflict using
NDB$EPOCH_TRANS()conflict resolution on a given mysqld since the last time it was restarted.For more information, see Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
Shows the number of rows found to be in conflict in NDB Cluster Replication conflict resolution, when using
NDB$EPOCH2(), on the source designated as the primary since the last time it was restarted.For more information, see NDB$EPOCH2().
Used in NDB Cluster Replication conflict resolution, this variable shows the number of rows found to be in conflict using
NDB$EPOCH_TRANS2()conflict resolution on a given mysqld since the last time it was restarted.For more information, see NDB$EPOCH2_TRANS().
Used in NDB Cluster Replication conflict resolution, this variable shows the number of times that a row was not applied on the current SQL node due to “greatest timestamp wins” conflict resolution since the last time that this mysqld was started.
For more information, see Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
Shows the number of times that a row was rejected on the current SQL node due to NDB Cluster Replication conflict resolution using
NDB$MAX_DELETE_WIN(), since the last time that this mysqld was started.For more information, see Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
Used in NDB Cluster Replication conflict resolution, this variable shows the number of times that a row was not applied as the result of “same timestamp wins” conflict resolution on a given mysqld since the last time it was restarted.
For more information, see Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
Ndb_conflict_last_conflict_epochThe most recent epoch in which a conflict was detected on this replica. You can compare this value with
Ndb_slave_max_replicated_epoch; ifNdb_slave_max_replicated_epochis greater thanNdb_conflict_last_conflict_epoch, no conflicts have yet been detected.See Section 21.7.11, “NDB Cluster Replication Conflict Resolution”, for more information.
Ndb_conflict_reflected_op_discard_countWhen using NDB Cluster Replication conflict resolution, this is the number of reflected operations that were not applied on the secondary, due to encountering an error during execution.
See Section 21.7.11, “NDB Cluster Replication Conflict Resolution”, for more information.
Ndb_conflict_reflected_op_prepare_countWhen using conflict resolution with NDB Cluster Replication, this status variable contains the number of reflected operations that have been defined (that is, prepared for execution on the secondary).
See Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
When using conflict resolution with NDB Cluster Replication, this gives the number of refresh operations that have been prepared for execution on the secondary.
See Section 21.7.11, “NDB Cluster Replication Conflict Resolution”, for more information.
Ndb_conflict_last_stable_epochNumber of rows found to be in conflict by a transactional conflict function
See Section 21.7.11, “NDB Cluster Replication Conflict Resolution”, for more information.
Ndb_conflict_trans_row_conflict_countUsed in NDB Cluster Replication conflict resolution, this status variable shows the number of rows found to be directly in-conflict by a transactional conflict function on a given mysqld since the last time it was restarted.
Currently, the only transactional conflict detection function supported by NDB Cluster is NDB$EPOCH_TRANS(), so this status variable is effectively the same as
Ndb_conflict_fn_epoch_trans.For more information, see Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
Ndb_conflict_trans_row_reject_countUsed in NDB Cluster Replication conflict resolution, this status variable shows the total number of rows realigned due to being determined as conflicting by a transactional conflict detection function. This includes not only
Ndb_conflict_trans_row_conflict_count, but any rows in or dependent on conflicting transactions.For more information, see Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
Ndb_conflict_trans_reject_countUsed in NDB Cluster Replication conflict resolution, this status variable shows the number of transactions found to be in conflict by a transactional conflict detection function.
For more information, see Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
Ndb_conflict_trans_detect_iter_countUsed in NDB Cluster Replication conflict resolution, this shows the number of internal iterations required to commit an epoch transaction. Should be (slightly) greater than or equal to
Ndb_conflict_trans_conflict_commit_count.For more information, see Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
Ndb_conflict_trans_conflict_commit_countUsed in NDB Cluster Replication conflict resolution, this shows the number of epoch transactions committed after they required transactional conflict handling.
For more information, see Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
When using delete-delete conflict detection, this is the number of delete-delete conflicts detected, where a delete operation is applied, but the indicated row does not exist.
Provides the number of round trips to the
NDBkernel made by operations.The epoch most recently committed by
NDB.The epoch most recently committed by this
NDBclient.If the server is part of an NDB Cluster, the value of this variable is the number of data nodes in the cluster.
If the server is not part of an NDB Cluster, then the value of this variable is 0.
The total number of joins pushed down to the NDB kernel for distributed handling on the data nodes.
NoteJoins tested using
EXPLAINthat can be pushed down contribute to this number.The number of joins that were pushed down to the NDB kernel but that could not be handled there.
The number of joins successfully pushed down to
NDBand executed there.The number of rows returned to mysqld from the NDB kernel by joins that were pushed down.
This variable holds a count of the number of scans executed by
NDBCLUSTERsince the NDB Cluster was last started whereNDBCLUSTERwas able to use partition pruning.Using this variable together with
Ndb_scan_countcan be helpful in schema design to maximize the ability of the server to prune scans to a single table partition, thereby involving only a single data node.This variable holds a count of the total number of scans executed by
NDBCLUSTERsince the NDB Cluster was last started.Ndb_slave_max_replicated_epochThe most recently committed epoch on this replica. You can compare this value with
Ndb_conflict_last_conflict_epoch; ifNdb_slave_max_replicated_epochis the greater of the two, no conflicts have yet been detected.For more information, see Section 21.7.11, “NDB Cluster Replication Conflict Resolution”.
If this MySQL Server is connected to an NDB cluster, this read-only variable shows the cluster system name. Otherwise, the value is an empty string.