This section provides detailed information about MySQL server
system variables that are specific to MySQL Cluster and the
NDB storage engine. For system
variables not specific to MySQL Cluster, see
Section 5.1.4, “Server System Variables”. For general
information on using system variables, see
Section 5.1.5, “Using System Variables”.
| Removed | 5.6.1 | ||
| System Variable Name | have_ndbcluster | ||
| Variable Scope | Global | ||
| Dynamic Variable | No | ||
| Permitted Values | |||
| Type | boolean | ||
YES if mysqld supports
NDBCLUSTER tables.
DISABLED if
--skip-ndbcluster is used.
This variable is deprecated and is removed in MySQL 5.6. Use
SHOW ENGINES instead.
| Command-Line Format | --multi_range_count=# | ||
| Option-File Format | multi_range_count | ||
| System Variable Name | multi_range_count | ||
| Variable Scope | Global, Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | numeric | ||
| Default | 256 | ||
| Range | 1 .. 4294967295 | ||
The maximum number of ranges to send to a table handler at
once during range selects. The default value is 256. Sending
multiple ranges to a handler at once can improve the
performance of certain selects dramatically. This is
especially true for the
NDBCLUSTER table handler, which
needs to send the range requests to all nodes. Sending a
batch of those requests at once reduces communication costs
significantly.
This variable was removed in MySQL 5.6.7.
| Command-Line Format | --ndb_autoincrement_prefetch_sz | ||
| Option-File Format | ndb_autoincrement_prefetch_sz | ||
| Option Sets Variable | Yes,
ndb_autoincrement_prefetch_sz | ||
| Variable Name | ndb_autoincrement_prefetch_sz | ||
| Variable Scope | Global, Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | numeric | ||
| Default | 1 | ||
| Range | 1 .. 65536 | ||
Determines the probability of gaps in an autoincremented
column. Set it to 1 to minimize this.
Setting it to a high value for optimization makes inserts
faster, but decreases the likelihood that consecutive
autoincrement numbers will be used in a batch of inserts.
The mininum and default value is 1. The maximum value for
ndb_autoincrement_prefetch_sz is 65536.
This variable affects only the number of
AUTO_INCREMENT IDs that are fetched
between statements; within a given statement, at least 32
IDs are obtained at a time. The default value for
ndb_autoincrement_prefetch_sz
is 1, to increase the speed of statements
inserting single rows.
This variable does not affect inserts performed using
INSERT ...
SELECT.
| Command-Line Format | --ndb_cache_check_time | ||
| Option-File Format | ndb_cache_check_time | ||
| System Variable Name | ndb_cache_check_time | ||
| Variable Scope | Global | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | numeric | ||
| Default | 0 | ||
The number of milliseconds that elapse between checks of MySQL 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.
| Command-Line Format | --ndb-deferred-constraints | ||
| Option-File Format | ndb_deferred_constraints | ||
| System Variable Name | ndb_deferred_constraints | ||
| Variable Scope | Global, Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | false | ||
| Range | false .. true | ||
Controls whether or not constraint checks are deferred,
where these are supported. OFF is the
default.
This variable is not normally needed for operation of MySQL Cluster or MySQL Cluster Replication, and is intended primarily for use in testing.
| Command-Line Format | --ndb-distribution={KEYHASH|LINHASH} | ||
| Option-File Format | ndb_distribution | ||
| System Variable Name | ndb_distribution={KEYHASH|LINHASH} | ||
| Variable Scope | Global, Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | enumeration | ||
| Default | KEYHASH | ||
| Valid Values | LINHASH | ||
KEYHASH | |||
Controls the default distribution method for
NDB tables. Can be set to
either of KEYHASH (key hashing) or
LINHASH (linear hashing).
KEYHASH is the default.
| Command-Line Format | ndb_extra_logging=# | ||
| Option-File Format | ndb_extra_logging | ||
| System Variable Name | ndb_extra_logging | ||
| Variable Scope | Global | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | numeric | ||
| Default | 0 | ||
This variable can be used to enable recording in the MySQL
error log of information specific to the
NDB storage engine. It is
normally of interest only when debugging
NDB storage engine code.
The default value is 0, which means that the only
NDB-specific information
written to the MySQL error log relates to transaction
handling. If the value is greater than 0 but less than 10,
NDB table schema and connection
events are also logged, as well as whether or not conflict
resolution is in use, and other
NDB errors and information. If
the value is set to 10 or more, information about
NDB internals, such as the
progress of data distribution among cluster nodes, is also
written to the MySQL error log.
| Command-Line Format | --ndb-force-send | ||
| Option-File Format | ndb_force_send | ||
| System Variable Name | ndb_force_send | ||
| Variable Scope | Global, Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | TRUE | ||
Forces sending of buffers to
NDB immediately, without
waiting for other threads. Defaults to
ON.
| System Variable Name | ndb_join_pushdown | ||
| Variable Scope | Global | ||
| Dynamic Variable | No | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | TRUE | ||
This variable controls whether joins on
NDB tables are pushed down to
the NDB kernel (data nodes). Previously, a join was handled
using multiple accesses of NDB
by the SQL node; however, when
ndb_join_pushdown is
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_pushdown is
enabled.
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 an
constantINT column and a
BIGINT column also cannot
be pushed down.
Explicit locking is not supported; however, the
NDB storage engine's
characteristic implicit row-based locking is enforced.
This means that a join using FOR
UPDATE cannot 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, or
const access 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_ref or
const, only child
tables joined by
eq_ref can be
appended. (A table joined by
ref is likely to
become the root of another pushed join.)
If the query optimizer decides on Using join
cache for 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, or RANGE
currently 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
the pushed join in the
Extra column 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)
If 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,
and Ndb_pushed_reads.
The counters in the
ndbinfo.counters table
that belong to the DBSPJ kernel
block. See
Section 17.5.10.7, “The ndbinfo counters Table”, for
information about these counters. See also
The DBSPJ Block, in
the MySQL Cluster API Developer
Guide.
| Command-Line Format | --ndb-log-apply-status | ||
| Option-File Format | ndb-log-apply-status | ||
| System Variable Name | ndb_log_apply_status | ||
| Variable Scope | Global | ||
| Dynamic Variable | No | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | OFF | ||
A read-only variable which shows whether the server was
started with the
--ndb-log-apply-status
option.
| Command-Line Format | --ndb-log-bin={1|0} | ||
| System Variable Name | ndb_log_bin | ||
| Variable Scope | Global, Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | ON | ||
Causes updates to NDB tables to be
written to the binary log. Setting this variable has no
effect if binary logging is not already enabled for the
server using log_bin.
ndb_log_bin defaults to 1 (ON); normally,
there is never any need to change this value in a production
environment.
| Command-Line Format | --ndb-log-binlog-index={1|0} | ||
| System Variable Name | ndb_log_binlog_index | ||
| Variable Scope | Global | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | ON | ||
Causes a mapping of epochs to positions in the binary log to
be inserted into the ndb_binlog_index
table. Setting this variable has no effect if binary logging
is not already enabled for the server using
log_bin. (In addition,
ndb_log_bin must not be
disabled.) ndb_log_binlog_index defaults
to 1 (ON); normally,
there is never any need to change this value in a production
environment.
| System Variable Name | ndb_log_transaction_id | ||
| Variable Scope | Global | ||
| Dynamic Variable | No | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | OFF | ||
This read-only, Boolean system variable shows whether a
slave mysqld writes NDB transaction IDs
in the binary log (required to use
“active-active” MySQL Cluster Replication with
NDB$EPOCH_TRANS() conflict detection). To
change the setting, use the
--ndb-log-transaction-id
option.
ndb_log_transaction_id is
not supported in mainline MySQL Server 5.6.
For more information, see Section 17.6.11, “MySQL Cluster Replication Conflict Resolution”.
| Command-Line Format | --ndb-optimized-node-selection=# | ||
| Option-File Format | ndb_optimized_node_selection | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | ON | ||
| Permitted Values | |||
| Type | numeric | ||
| Default | 3 | ||
| Range | 0 .. 3 | ||
There 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; SCI connection; TCP
connection from a host other than
localhost.
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, or 3.
3 is 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 to
0.
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.)
ndb_recv_thread_activation_threshold
| Introduced | 5.6.10-ndb-7.3.1 | ||
| Permitted Values | |||
| Type | numeric | ||
| Default | 8 | ||
| Range | 0 .. 16 | ||
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 on
startup using the
--ndb-recv-thread-activation-threshold
option.
| Introduced | 5.6.10-ndb-7.3.1 | ||
| System Variable Name | ndb_recv_thread_cpu_mask | ||
| Variable Scope | Global | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | Bitmap | ||
| Default | [empty] | ||
CPU mask for locking receiver threads to specific CPUs. This
is specified as a hexadecimal bitmask; for example,
0x33 means that one CPU is used per
receiver thread. An empty string is the default; setting
ndb_recv_thread_cpu_mask to this value
removes any receiver thread locks previously set.
This variable is global in scope. It can also be set on
startup using the
--ndb-recv-thread-cpu-mask
option.
ndb_report_thresh_binlog_epoch_slip
| Command-Line Format | --ndb_report_thresh_binlog_epoch_slip | ||
| Option-File Format | ndb_report_thresh_binlog_epoch_slip | ||
| Permitted Values | |||
| Type | numeric | ||
| Default | 3 | ||
| Range | 0 .. 256 | ||
This is a threshold on the number of epochs to be behind
before reporting binary log status. For example, 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 will be sent to the
cluster log.
ndb_report_thresh_binlog_mem_usage
| Command-Line Format | --ndb_report_thresh_binlog_mem_usage | ||
| Option-File Format | ndb_report_thresh_binlog_mem_usage | ||
| Permitted Values | |||
| Type | numeric | ||
| Default | 10 | ||
| Range | 0 .. 10 | ||
This 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 will
be sent to the cluster log.
| System Variable Name | ndb_table_no_logging | ||
| Variable Scope | Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | FALSE | ||
When this variable is set to ON or
1, it causes
NDB tables not to be
checkpointed to disk. More specifically, this setting
applies to tables which are created or altered using
ENGINE NDB when
ndb_table_no_logging is
enabled, and continues to apply for the lifetime of the
table, even if
ndb_table_no_logging is
later changed. Suppose that A,
B, C, and
D are tables that we create (and perhaps
also alter), and that we also change the setting for
ndb_table_no_logging as
shown here:
SET @@ndb_table_no_logging = 1; CREATE TABLE A ... ENGINE NDB; CREATE TABLE B ... ENGINE MYISAM; CREATE TABLE C ... ENGINE MYISAM; ALTER TABLE B ENGINE NDB; SET @@ndb_table_no_logging = 0; CREATE TABLE D ... ENGINE NDB; ALTER TABLE C ENGINE NDB; SET @@ndb_table_no_logging = 1;
After the previous sequence of events, tables
A and B are not
checkpointed; A was created with
ENGINE NDB and B was altered to use
NDB, both while
ndb_table_no_logging was enabled.
However, tables C and
D are logged; C was
altered to use NDB and
D was created using ENGINE
NDB, both while
ndb_table_no_logging was
disabled. Setting
ndb_table_no_logging back
to 1 or ON does
not cause table C or
D to be checkpointed.
ndb_table_no_logging has
no effect on the creation of
NDB table schema files; to
suppress these, use
ndb_table_temporary
instead.
| System Variable Name | ndb_table_temporary | ||
| Variable Scope | Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | FALSE | ||
When set to ON or 1,
this variable causes NDB tables
not to be written to disk: This means that no table schema
files are created, and that the tables are not logged.
Setting this variable currently has no effect in MySQL Cluster NDB 7.0 and later. This is a known issue; see Bug #34036.
| System Variable Name | ndb_use_copying_alter_table | ||
| Variable Scope | Global, Session | ||
| Dynamic Variable | No | ||
Forces NDB to use copying of
tables in the event of problems with online
ALTER TABLE operations. The
default value is OFF.
| System Variable Name | ndb_use_exact_count | ||
| Variable Scope | Global, Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | ON | ||
Forces NDB to use a count of
records during SELECT COUNT(*) query
planning to speed up this type of query. The default value
is ON. For faster queries overall,
disable this feature by setting the value of
ndb_use_exact_count to
OFF.
| Command-Line Format | --ndb_use_transactions | ||
| Option-File Format | ndb_use_transactions | ||
| System Variable Name | ndb_use_transactions | ||
| Variable Scope | Global, Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | ON | ||
You can disable NDB transaction
support by setting this variable's values to
OFF (not recommended). The default is
ON.
| System Variable Name | transaction_allow_batching | ||
| Variable Scope | Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | FALSE | ||
When set to 1 or ON,
this variable enables batching of statements within the same
transaction. To use this variable,
autocommit must first be
disabled by setting it to 0 or
OFF; otherwise, setting
transaction_allow_batching
has 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
COMMIT if desired) before
issuing a SELECT.
transaction_allow_batching
should 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 MySQL Cluster only.
The system variables in the following list all relate to the
ndbinfo information database.
| System Variable Name | ndbinfo_database | ||
| Variable Scope | Global | ||
| Dynamic Variable | No | ||
| Permitted Values | |||
| Type | string | ||
| Default | ndbinfo | ||
Shows the name used for the NDB
information database; the default is
ndbinfo. This is a read-only variable
whose value is determined at compile time; you can set it by
starting the server using
--ndbinfo-database=,
which sets the value shown for this variable but does not
actually change the name used for the NDB information
database.
name
| Command-Line Format | --ndbinfo-max-bytes=# | ||
| System Variable Name | ndbinfo_max_bytes | ||
| Variable Scope | Global, Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | numeric | ||
| Default | 0 | ||
Used in testing and debugging only.
| Command-Line Format | --ndbinfo-max-rows=# | ||
| System Variable Name | ndbinfo_max_rows | ||
| Variable Scope | Global, Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | numeric | ||
| Default | 10 | ||
Used in testing and debugging only.
| Command-Line Format | --ndbinfo-show-hidden={0|1} | ||
| System Variable Name | ndbinfo_show_hidden | ||
| Variable Scope | Global, Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | OFF | ||
Whether or not the ndbinfo
database's underlying internal tables are shown in the
mysql client. The default is
OFF.
| Command-Line Format | --ndbinfo-table-prefix=name | ||
| System Variable Name | ndbinfo_table_prefix | ||
| Variable Scope | Global, Session | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | string | ||
| Default | 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 is
“ndb$”. You can start the
server with the --ndbinfo-table-prefix
option, but this merely sets the variable and does not
change the actual prefix used to name the hidden base
tables; the prefix itself is determined at compile time.
| System Variable Name | ndbinfo_version | ||
| Variable Scope | Global | ||
| Dynamic Variable | No | ||
| Permitted Values | |||
| Type | string | ||
| Default | | ||
Shows the version of the
ndbinfo engine in use;
read-only.
| Command-Line Format | --ndb-log-empty-epochs | ||
| Option-File Format | ndb_log_empty_epochs | ||
| System Variable Name | ndb_log_empty_epochs | ||
| Variable Scope | Global | ||
| Dynamic Variable | Yes | ||
| Permitted Values | |||
| Type | boolean | ||
| Default | OFF | ||
When 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 | --server-id-bits=# | ||
| Option-File Format | server-id-bits | ||
| System Variable Name | server_id_bits | ||
| Variable Scope | Global | ||
| Dynamic Variable | No | ||
| Permitted Values | |||
| Type | numeric | ||
| Default | 32 | ||
| Range | 7 .. 32 | ||
The effective value of
server_id if the server was
started with the
--server-id-bits option set
to a nondefault value.
If the value of server_id
greater than or equal to 2 to the power of
server_id_bits,
mysqld refuses to start.
This system variable is supported only by MySQL Cluster.
server_id_bits is not
supported by the standard MySQL Server.

User Comments
Add your own comment.