Author: jstephens
Date: 2009-07-30 21:12:22 +0200 (Thu, 30 Jul 2009)
New Revision: 15884
Log:
Added dynamic paras to Cluster configuration parameter descriptions
Removed:
trunk/refman-4.1/mysql-cluster-configuration.xml
trunk/refman-5.0/mysql-cluster-configuration.xml
trunk/refman-5.1/mysql-cluster-configuration.xml
Renamed/Moved:
trunk/refman-4.1/mysql-cluster-configuration-core.xml (from rev 15880, trunk/refman-4.1/mysql-cluster-configuration.xml)
trunk/refman-5.0/mysql-cluster-configuration-core.xml (from rev 15880, trunk/refman-5.0/mysql-cluster-configuration.xml)
trunk/refman-5.1/mysql-cluster-configuration-core.xml (from rev 15880, trunk/refman-5.1/mysql-cluster-configuration.xml)
Modified:
trunk/dynamic-docs/command-optvars/ndb-config-params.xml
trunk/mysql-monitor-2.0/Makefile.depends
trunk/mysql-monitor-2.1/Makefile.depends
trunk/mysql-monitor-common/Makefile.depends
trunk/ndbapi/Makefile.depends
trunk/quick-guides/Makefile.depends
trunk/refman-4.1/Makefile.depends
trunk/refman-4.1/mysql-cluster.xml
trunk/refman-5.0/Makefile.depends
trunk/refman-5.0/mysql-cluster.xml
trunk/refman-5.1-maria/Makefile.depends
trunk/refman-5.1/Makefile.depends
trunk/refman-5.1/mysql-cluster.xml
trunk/refman-5.4/Makefile.depends
trunk/refman-6.0/Makefile.depends
trunk/topic-guides/topics-5.1/Makefile.depends
Modified: trunk/dynamic-docs/command-optvars/ndb-config-params.xml
===================================================================
--- trunk/dynamic-docs/command-optvars/ndb-config-params.xml 2009-07-30 17:01:52 UTC (rev 15883)
+++ trunk/dynamic-docs/command-optvars/ndb-config-params.xml 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 177, Lines Added: 352, Lines Deleted: 2; 39443 bytes
@@ -6,6 +6,8 @@
<mysqloption id="__ndbmt_classic-ndbmtd" section="cluster" subsection="ndbmtd">
+ <xrefto id="ndbparam-ndbmtd-__ndbmt_classic"/>
+
<name>__ndbmt_classic</name>
<shortdescription lang="en">
@@ -29,6 +31,8 @@
<mysqloption id="__ndbmt_lqh_threads-ndbmtd" section="cluster" subsection="ndbmtd">
+ <xrefto id="ndbparam-ndbmtd-__ndbmt_lqh_threads"/>
+
<name>__ndbmt_lqh_threads</name>
<shortdescription lang="en">
@@ -52,6 +56,8 @@
<mysqloption id="__ndbmt_lqh_workers-ndbmtd" section="cluster" subsection="ndbmtd">
+ <xrefto id="ndbparam-ndbmtd-__ndbmt_lqh_workers"/>
+
<name>__ndbmt_lqh_workers</name>
<shortdescription lang="en">
@@ -73,6 +79,8 @@
<mysqloption id="arbitration-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-arbitration"/>
+
<name>Arbitration</name>
<shortdescription lang="en">
@@ -80,7 +88,7 @@
the event of node failure.
</shortdescription>
- <values vartype="enumeration" platform="all" inversion="5.1.35-ndb-7.0.7">
+ <values vartype="enumeration" platform="all" inversion="5.1.35-ndb-7.0.7" units="{Disabled|Default|WaitExternal}">
<choice value="Disabled"/>
<value default="Default"/>
<choice value="WaitExternal"/>
@@ -97,6 +105,8 @@
<mysqloption id="arbitrationdelay-api" section="cluster" subsection="api">
+ <xrefto id="ndbparam-api-arbitrationdelay"/>
+
<name>ArbitrationDelay</name>
<shortdescription lang="en">
@@ -121,6 +131,8 @@
<mysqloption id="arbitrationdelay-mgmd" section="cluster" subsection="mgmd">
+ <xrefto id="ndbparam-mgmd-arbitrationdelay"/>
+
<name>ArbitrationDelay</name>
<shortdescription lang="en">
@@ -145,6 +157,8 @@
<mysqloption id="arbitrationrank-api" section="cluster" subsection="api">
+ <xrefto id="ndbparam-api-arbitrationrank"/>
+
<name>ArbitrationRank</name>
<shortdescription lang="en">
@@ -169,6 +183,8 @@
<mysqloption id="arbitrationrank-mgmd" section="cluster" subsection="mgmd">
+ <xrefto id="ndbparam-mgmd-arbitrationrank"/>
+
<name>ArbitrationRank</name>
<shortdescription lang="en">
@@ -193,6 +209,8 @@
<mysqloption id="arbitrationtimeout-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-arbitrationtimeout"/>
+
<name>ArbitrationTimeout</name>
<shortdescription lang="en">
@@ -217,6 +235,8 @@
<mysqloption id="backupdatabuffersize-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-backupdatabuffersize"/>
+
<name>BackupDataBufferSize</name>
<shortdescription lang="en">
@@ -248,6 +268,8 @@
<mysqloption id="backupdatadir-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-backupdatadir"/>
+
<name>BackupDataDir</name>
<shortdescription lang="en">
@@ -271,6 +293,8 @@
<mysqloption id="backuplogbuffersize-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-backuplogbuffersize"/>
+
<name>BackupLogBufferSize</name>
<shortdescription lang="en">
@@ -302,6 +326,8 @@
<mysqloption id="backupmaxwritesize-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-backupmaxwritesize"/>
+
<name>BackupMaxWriteSize</name>
<shortdescription lang="en">
@@ -329,6 +355,8 @@
<mysqloption id="backupmemory-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-backupmemory"/>
+
<name>BackupMemory</name>
<shortdescription lang="en">
@@ -356,6 +384,8 @@
<mysqloption id="backupreportfrequency-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-backupreportfrequency"/>
+
<name>BackupReportFrequency</name>
<shortdescription lang="en">
@@ -377,6 +407,8 @@
<mysqloption id="backupwritesize-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-backupwritesize"/>
+
<name>BackupWriteSize</name>
<shortdescription lang="en">
@@ -404,6 +436,8 @@
<mysqloption id="batchbytesize-api" section="cluster" subsection="api">
+ <xrefto id="ndbparam-api-batchbytesize"/>
+
<name>BatchByteSize</name>
<shortdescription lang="en">
@@ -427,6 +461,8 @@
<mysqloption id="batchsize-api" section="cluster" subsection="api">
+ <xrefto id="ndbparam-api-batchsize"/>
+
<name>BatchSize</name>
<shortdescription lang="en">
@@ -450,6 +486,8 @@
<mysqloption id="batchsizeperlocalscan-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-batchsizeperlocalscan"/>
+
<name>BatchSizePerLocalScan</name>
<shortdescription lang="en">
@@ -474,6 +512,8 @@
<mysqloption id="checksum-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-checksum"/>
+
<name>Checksum</name>
<shortdescription lang="en">
@@ -498,6 +538,8 @@
<mysqloption id="checksum-shm" section="cluster" subsection="shm">
+ <xrefto id="ndbparam-shm-checksum"/>
+
<name>Checksum</name>
<shortdescription lang="en">
@@ -522,6 +564,8 @@
<mysqloption id="checksum-sci" section="cluster" subsection="sci">
+ <xrefto id="ndbparam-sci-checksum"/>
+
<name>Checksum</name>
<shortdescription lang="en">
@@ -546,6 +590,8 @@
<mysqloption id="compressedbackup-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-compressedbackup"/>
+
<name>CompressedBackup</name>
<shortdescription lang="en">
@@ -567,6 +613,8 @@
<mysqloption id="compressedlcp-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-compressedlcp"/>
+
<name>CompressedLCP</name>
<shortdescription lang="en">
@@ -588,6 +636,8 @@
<mysqloption id="configgenerationnumber-system" section="cluster" subsection="system">
+ <xrefto id="ndbparam-system-configgenerationnumber"/>
+
<name>ConfigGenerationNumber</name>
<shortdescription lang="en">
@@ -613,6 +663,8 @@
<mysqloption id="connectionmap-api" section="cluster" subsection="api">
+ <xrefto id="ndbparam-api-connectionmap"/>
+
<name>ConnectionMap</name>
<shortdescription lang="en">
@@ -634,6 +686,8 @@
<mysqloption id="datadir-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-datadir"/>
+
<name>DataDir</name>
<shortdescription lang="en">
@@ -657,6 +711,8 @@
<mysqloption id="datadir-mgmd" section="cluster" subsection="mgmd">
+ <xrefto id="ndbparam-mgmd-datadir"/>
+
<name>DataDir</name>
<shortdescription lang="en">
@@ -680,6 +736,8 @@
<mysqloption id="datamemory-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-datamemory"/>
+
<name>DataMemory</name>
<shortdescription lang="en">
@@ -704,6 +762,8 @@
<mysqloption id="diskcheckpointspeed-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-diskcheckpointspeed"/>
+
<name>DiskCheckpointSpeed</name>
<shortdescription lang="en">
@@ -725,6 +785,8 @@
<mysqloption id="diskcheckpointspeedinrestart-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-diskcheckpointspeedinrestart"/>
+
<name>DiskCheckpointSpeedInRestart</name>
<shortdescription lang="en">
@@ -747,6 +809,8 @@
<mysqloption id="diskiothreadpool-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-diskiothreadpool"/>
+
<name>DiskIOThreadPool</name>
<shortdescription lang="en">
@@ -777,6 +841,8 @@
<mysqloption id="diskless-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-diskless"/>
+
<name>Diskless</name>
<shortdescription lang="en">
@@ -800,6 +866,8 @@
<mysqloption id="diskpagebuffermemory-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-diskpagebuffermemory"/>
+
<name>DiskPageBufferMemory</name>
<shortdescription lang="en">
@@ -822,6 +890,8 @@
<mysqloption id="disksyncsize-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-disksyncsize"/>
+
<name>DiskSyncSize</name>
<shortdescription lang="en">
@@ -843,6 +913,8 @@
<mysqloption id="executeoncomputer-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-executeoncomputer"/>
+
<name>ExecuteOnComputer</name>
<shortdescription lang="en">
@@ -866,6 +938,8 @@
<mysqloption id="executeoncomputer-api" section="cluster" subsection="api">
+ <xrefto id="ndbparam-api-executeoncomputer"/>
+
<name>ExecuteOnComputer</name>
<shortdescription lang="en">
@@ -889,6 +963,8 @@
<mysqloption id="executeoncomputer-mgmd" section="cluster" subsection="mgmd">
+ <xrefto id="ndbparam-mgmd-executeoncomputer"/>
+
<name>ExecuteOnComputer</name>
<shortdescription lang="en">
@@ -912,6 +988,8 @@
<mysqloption id="filesystempath-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-filesystempath"/>
+
<name>FileSystemPath</name>
<shortdescription lang="en">
@@ -934,6 +1012,8 @@
<mysqloption id="filesystempathdd-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-filesystempathdd"/>
+
<name>FileSystemPathDD</name>
<shortdescription lang="en">
@@ -959,6 +1039,8 @@
<mysqloption id="filesystempathdatafiles-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-filesystempathdatafiles"/>
+
<name>FileSystemPathDataFiles</name>
<shortdescription lang="en">
@@ -985,6 +1067,8 @@
<mysqloption id="filesystempathundofiles-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-filesystempathundofiles"/>
+
<name>FileSystemPathUndoFiles</name>
<shortdescription lang="en">
@@ -1011,6 +1095,8 @@
<mysqloption id="fragmentlogfilesize-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-fragmentlogfilesize"/>
+
<name>FragmentLogFileSize</name>
<shortdescription lang="en">
@@ -1036,6 +1122,8 @@
<mysqloption id="group-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-group"/>
+
<name>Group</name>
<shortdescription lang="en"/>
@@ -1061,6 +1149,8 @@
<mysqloption id="group-shm" section="cluster" subsection="shm">
+ <xrefto id="ndbparam-shm-group"/>
+
<name>Group</name>
<shortdescription lang="en"/>
@@ -1086,6 +1176,8 @@
<mysqloption id="group-sci" section="cluster" subsection="sci">
+ <xrefto id="ndbparam-sci-group"/>
+
<name>Group</name>
<shortdescription lang="en"/>
@@ -1107,6 +1199,8 @@
<mysqloption id="heartbeatintervaldbapi-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-heartbeatintervaldbapi"/>
+
<name>HeartbeatIntervalDbApi</name>
<shortdescription lang="en">
@@ -1131,6 +1225,8 @@
<mysqloption id="heartbeatintervaldbdb-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-heartbeatintervaldbdb"/>
+
<name>HeartbeatIntervalDbDb</name>
<shortdescription lang="en">
@@ -1155,6 +1251,8 @@
<mysqloption id="host1sciid0-sci" section="cluster" subsection="sci">
+ <xrefto id="ndbparam-sci-host1sciid0"/>
+
<name>Host1SciId0</name>
<shortdescription lang="en">
@@ -1179,6 +1277,8 @@
<mysqloption id="host1sciid1-sci" section="cluster" subsection="sci">
+ <xrefto id="ndbparam-sci-host1sciid1"/>
+
<name>Host1SciId1</name>
<shortdescription lang="en">
@@ -1203,6 +1303,8 @@
<mysqloption id="host2sciid0-sci" section="cluster" subsection="sci">
+ <xrefto id="ndbparam-sci-host2sciid0"/>
+
<name>Host2SciId0</name>
<shortdescription lang="en">
@@ -1227,6 +1329,8 @@
<mysqloption id="host2sciid1-sci" section="cluster" subsection="sci">
+ <xrefto id="ndbparam-sci-host2sciid1"/>
+
<name>Host2SciId1</name>
<shortdescription lang="en">
@@ -1251,6 +1355,8 @@
<mysqloption id="hostname-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-hostname"/>
+
<name>HostName</name>
<shortdescription lang="en">
@@ -1274,6 +1380,8 @@
<mysqloption id="hostname-api" section="cluster" subsection="api">
+ <xrefto id="ndbparam-api-hostname"/>
+
<name>HostName</name>
<shortdescription lang="en">
@@ -1297,6 +1405,8 @@
<mysqloption id="hostname-mgmd" section="cluster" subsection="mgmd">
+ <xrefto id="ndbparam-mgmd-hostname"/>
+
<name>HostName</name>
<shortdescription lang="en">
@@ -1320,6 +1430,8 @@
<mysqloption id="indexmemory-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-indexmemory"/>
+
<name>IndexMemory</name>
<shortdescription lang="en">
@@ -1346,6 +1458,8 @@
<mysqloption id="initfragmentlogfiles-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-initfragmentlogfiles"/>
+
<name>InitFragmentLogFiles</name>
<shortdescription lang="en">
@@ -1367,6 +1481,8 @@
<mysqloption id="initiallogfilegroup-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-initiallogfilegroup"/>
+
<name>InitialLogFileGroup</name>
<shortdescription lang="en">
@@ -1393,6 +1509,8 @@
<mysqloption id="initialnoofopenfiles-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-initialnoofopenfiles"/>
+
<name>InitialNoOfOpenFiles</name>
<shortdescription lang="en">
@@ -1415,6 +1533,8 @@
<mysqloption id="initialtablespace-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-initialtablespace"/>
+
<name>InitialTablespace</name>
<shortdescription lang="en">
@@ -1439,7 +1559,7 @@
<mysqloption id="iothreadpool-ndbd" section="cluster" subsection="ndbd">
- <xrefto id="diskiothreadpool-ndbd"/>
+ <xrefto id="ndbparam-ndbd-iothreadpool"/>
<name>IOThreadPool</name>
@@ -1463,6 +1583,8 @@
<mysqloption id="lockexecutethreadtocpu-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-lockexecutethreadtocpu"/>
+
<name>LockExecuteThreadToCPU</name>
<shortdescription lang="en">
@@ -1484,6 +1606,8 @@
<mysqloption id="lockmaintthreadstocpu-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-lockmaintthreadstocpu"/>
+
<name>LockMaintThreadsToCPU</name>
<shortdescription lang="en">
@@ -1505,6 +1629,8 @@
<mysqloption id="lockpagesinmainmemory-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-lockpagesinmainmemory"/>
+
<name>LockPagesInMainMemory</name>
<shortdescription lang="en">
@@ -1546,6 +1672,8 @@
<mysqloption id="logdestination-mgmd" section="cluster" subsection="mgmd">
+ <xrefto id="ndbparam-mgmd-logdestination"/>
+
<name>LogDestination</name>
<shortdescription lang="en">
@@ -1570,6 +1698,8 @@
<mysqloption id="loglevelcheckpoint-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-loglevelcheckpoint"/>
+
<name>LogLevelCheckpoint</name>
<shortdescription lang="en">
@@ -1596,6 +1726,8 @@
<mysqloption id="loglevelcongestion-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-loglevelcongestion"/>
+
<name>LogLevelCongestion</name>
<shortdescription lang="en">
@@ -1620,6 +1752,8 @@
<mysqloption id="loglevelconnection-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-loglevelconnection"/>
+
<name>LogLevelConnection</name>
<shortdescription lang="en">
@@ -1643,6 +1777,8 @@
<mysqloption id="loglevelerror-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-loglevelerror"/>
+
<name>LogLevelError</name>
<shortdescription lang="en">
@@ -1666,6 +1802,8 @@
<mysqloption id="loglevelinfo-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-loglevelinfo"/>
+
<name>LogLevelInfo</name>
<shortdescription lang="en">
@@ -1689,6 +1827,8 @@
<mysqloption id="loglevelnoderestart-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-loglevelnoderestart"/>
+
<name>LogLevelNodeRestart</name>
<shortdescription lang="en">
@@ -1713,6 +1853,8 @@
<mysqloption id="loglevelshutdown-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-loglevelshutdown"/>
+
<name>LogLevelShutdown</name>
<shortdescription lang="en">
@@ -1736,6 +1878,8 @@
<mysqloption id="loglevelstartup-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-loglevelstartup"/>
+
<name>LogLevelStartup</name>
<shortdescription lang="en">
@@ -1759,6 +1903,8 @@
<mysqloption id="loglevelstatistic-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-loglevelstatistic"/>
+
<name>LogLevelStatistic</name>
<shortdescription lang="en">
@@ -1783,6 +1929,8 @@
<mysqloption id="longmessagebuffer-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-longmessagebuffer"/>
+
<name>LongMessageBuffer</name>
<shortdescription lang="en">
@@ -1811,6 +1959,8 @@
<mysqloption id="maxallocate-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxallocate"/>
+
<name>MaxAllocate</name>
<shortdescription lang="en">
@@ -1843,6 +1993,8 @@
<mysqloption id="maxbufferedepochs-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxbufferedepochs"/>
+
<name>MaxBufferedEpochs</name>
<shortdescription lang="en">
@@ -1866,6 +2018,8 @@
<mysqloption id="maxlcpstartdelay-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxlcpstartdelay"/>
+
<name>MaxLCPStartDelay</name>
<shortdescription lang="en">
@@ -1894,6 +2048,8 @@
<mysqloption id="maxnoofattributes-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnoofattributes"/>
+
<name>MaxNoOfAttributes</name>
<shortdescription lang="en">
@@ -1918,6 +2074,8 @@
<mysqloption id="maxnoofconcurrentindexoperations-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnoofconcurrentindexoperations"/>
+
<name>MaxNoOfConcurrentIndexOperations</name>
<shortdescription lang="en">
@@ -1942,6 +2100,8 @@
<mysqloption id="maxnoofconcurrentoperations-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnoofconcurrentoperations"/>
+
<name>MaxNoOfConcurrentOperations</name>
<shortdescription lang="en">
@@ -1965,6 +2125,8 @@
<mysqloption id="maxnoofconcurrentscans-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnoofconcurrentscans"/>
+
<name>MaxNoOfConcurrentScans</name>
<shortdescription lang="en">
@@ -1989,6 +2151,8 @@
<mysqloption id="maxnoofconcurrentsuboperations-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnoofconcurrentsuboperations"/>
+
<name>MaxNoOfConcurrentSubOperations</name>
<shortdescription lang="en">
@@ -2015,6 +2179,8 @@
<mysqloption id="maxnoofconcurrenttransactions-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnoofconcurrenttransactions"/>
+
<name>MaxNoOfConcurrentTransactions</name>
<shortdescription lang="en">
@@ -2039,6 +2205,8 @@
<mysqloption id="maxnoofexecutionthreads-ndbmtd" section="cluster" subsection="ndbmtd">
+ <xrefto id="ndbparam-ndbmtd-maxnoofexecutionthreads"/>
+
<name>MaxNoOfExecutionThreads</name>
<shortdescription lang="en">
@@ -2064,6 +2232,8 @@
<mysqloption id="maxnooffiredtriggers-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnooffiredtriggers"/>
+
<name>MaxNoOfFiredTriggers</name>
<shortdescription lang="en">
@@ -2088,6 +2258,8 @@
<mysqloption id="maxnooflocaloperations-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnooflocaloperations"/>
+
<name>MaxNoOfLocalOperations</name>
<shortdescription lang="en">
@@ -2111,6 +2283,8 @@
<mysqloption id="maxnooflocalscans-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnooflocalscans"/>
+
<name>MaxNoOfLocalScans</name>
<shortdescription lang="en">
@@ -2134,6 +2308,8 @@
<mysqloption id="maxnoofopenfiles-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnoofopenfiles"/>
+
<name>MaxNoOfOpenFiles</name>
<shortdescription lang="en">
@@ -2162,6 +2338,8 @@
<mysqloption id="maxnooforderedindexes-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnooforderedindexes"/>
+
<name>MaxNoOfOrderedIndexes</name>
<shortdescription lang="en">
@@ -2187,6 +2365,8 @@
<mysqloption id="maxnoofsavedevents-mgmd" section="cluster" subsection="mgmd">
+ <xrefto id="ndbparam-mgmd-maxnoofsavedevents"/>
+
<name>MaxNoOfSavedEvents</name>
<shortdescription lang="en"/>
@@ -2208,6 +2388,8 @@
<mysqloption id="maxnoofsavedmessages-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnoofsavedmessages"/>
+
<name>MaxNoOfSavedMessages</name>
<shortdescription lang="en">
@@ -2232,6 +2414,8 @@
<mysqloption id="maxnoofsubscribers-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnoofsubscribers"/>
+
<name>MaxNoOfSubscribers</name>
<shortdescription lang="en">
@@ -2258,6 +2442,8 @@
<mysqloption id="maxnoofsubscriptions-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnoofsubscriptions"/>
+
<name>MaxNoOfSubscriptions</name>
<shortdescription lang="en">
@@ -2284,6 +2470,8 @@
<mysqloption id="maxnooftables-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnooftables"/>
+
<name>MaxNoOfTables</name>
<shortdescription lang="en">
@@ -2307,6 +2495,8 @@
<mysqloption id="maxnooftriggers-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnooftriggers"/>
+
<name>MaxNoOfTriggers</name>
<shortdescription lang="en">
@@ -2330,6 +2520,8 @@
<mysqloption id="maxnoofuniquehashindexes-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-maxnoofuniquehashindexes"/>
+
<name>MaxNoOfUniqueHashIndexes</name>
<shortdescription lang="en">
@@ -2354,6 +2546,8 @@
<mysqloption id="maxscanbatchsize-api" section="cluster" subsection="api">
+ <xrefto id="ndbparam-api-maxscanbatchsize"/>
+
<name>MaxScanBatchSize</name>
<shortdescription lang="en">
@@ -2377,6 +2571,8 @@
<mysqloption id="memreportfrequency-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-memreportfrequency"/>
+
<name>MemReportFrequency</name>
<shortdescription lang="en">
@@ -2404,6 +2600,8 @@
<mysqloption id="name-system" section="cluster" subsection="system">
+ <xrefto id="ndbparam-system-name"/>
+
<name>Name</name>
<shortdescription lang="en">
@@ -2429,6 +2627,8 @@
<mysqloption id="nodegroup-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-nodegroup"/>
+
<name>NodeGroup</name>
<shortdescription lang="en">
@@ -2451,6 +2651,8 @@
<mysqloption id="nodeid-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-nodeid"/>
+
<name>NodeId</name>
<shortdescription lang="en">
@@ -2474,6 +2676,8 @@
<mysqloption id="nodeid-api" section="cluster" subsection="api">
+ <xrefto id="ndbparam-api-nodeid"/>
+
<name>NodeId</name>
<shortdescription lang="en">
@@ -2501,6 +2705,8 @@
<mysqloption id="nodeid-mgmd" section="cluster" subsection="mgmd">
+ <xrefto id="ndbparam-mgmd-nodeid"/>
+
<name>NodeId</name>
<shortdescription lang="en">
@@ -2528,6 +2734,8 @@
<mysqloption id="nodeid1-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-nodeid1"/>
+
<name>NodeId1</name>
<shortdescription lang="en">
@@ -2552,6 +2760,8 @@
<mysqloption id="nodeid1-shm" section="cluster" subsection="shm">
+ <xrefto id="ndbparam-shm-nodeid1"/>
+
<name>NodeId1</name>
<shortdescription lang="en">
@@ -2576,6 +2786,8 @@
<mysqloption id="nodeid1-sci" section="cluster" subsection="sci">
+ <xrefto id="ndbparam-sci-nodeid1"/>
+
<name>NodeId1</name>
<shortdescription lang="en">
@@ -2600,6 +2812,8 @@
<mysqloption id="nodeid2-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-nodeid2"/>
+
<name>NodeId2</name>
<shortdescription lang="en">
@@ -2624,6 +2838,8 @@
<mysqloption id="nodeid2-shm" section="cluster" subsection="shm">
+ <xrefto id="ndbparam-shm-nodeid2"/>
+
<name>NodeId2</name>
<shortdescription lang="en">
@@ -2648,6 +2864,8 @@
<mysqloption id="nodeid2-sci" section="cluster" subsection="sci">
+ <xrefto id="ndbparam-sci-nodeid2"/>
+
<name>NodeId2</name>
<shortdescription lang="en">
@@ -2674,6 +2892,8 @@
<mysqloption id="nodeidserver-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-nodeidserver"/>
+
<name>NodeIdServer</name>
<shortdescription lang="en"/>
@@ -2697,6 +2917,8 @@
<mysqloption id="nodeidserver-shm" section="cluster" subsection="shm">
+ <xrefto id="ndbparam-shm-nodeidserver"/>
+
<name>NodeIdServer</name>
<shortdescription lang="en"/>
@@ -2720,6 +2942,8 @@
<mysqloption id="nodeidserver-sci" section="cluster" subsection="sci">
+ <xrefto id="ndbparam-sci-nodeidserver"/>
+
<name>NodeIdServer</name>
<shortdescription lang="en"/>
@@ -2741,6 +2965,8 @@
<mysqloption id="noofdiskpagestodiskafterrestartacc-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-noofdiskpagestodiskafterrestartacc"/>
+
<name>NoOfDiskPagesToDiskAfterRestartACC</name>
<shortdescription lang="en">
@@ -2765,6 +2991,8 @@
<mysqloption id="noofdiskpagestodiskafterrestarttup-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-noofdiskpagestodiskafterrestarttup"/>
+
<name>NoOfDiskPagesToDiskAfterRestartTUP</name>
<shortdescription lang="en">
@@ -2789,6 +3017,8 @@
<mysqloption id="noofdiskpagestodiskduringrestartacc-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-noofdiskpagestodiskduringrestartacc"/>
+
<name>NoOfDiskPagesToDiskDuringRestartACC</name>
<shortdescription lang="en">
@@ -2813,6 +3043,8 @@
<mysqloption id="noofdiskpagestodiskduringrestarttup-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-noofdiskpagestodiskduringrestarttup"/>
+
<name>NoOfDiskPagesToDiskDuringRestartTUP</name>
<shortdescription lang="en">
@@ -2837,6 +3069,8 @@
<mysqloption id="nooffragmentlogfiles-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-nooffragmentlogfiles"/>
+
<name>NoOfFragmentLogFiles</name>
<shortdescription lang="en">
@@ -2865,6 +3099,8 @@
<mysqloption id="noofreplicas-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-noofreplicas"/>
+
<name>NoOfReplicas</name>
<shortdescription lang="en">
@@ -2889,6 +3125,8 @@
<mysqloption id="odirect-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-odirect"/>
+
<name>ODirect</name>
<shortdescription lang="en">
@@ -2922,6 +3160,8 @@
<mysqloption id="overloadlimit-sci" section="cluster" subsection="sci">
+ <xrefto id="ndbparam-sci-overloadlimit"/>
+
<name>OverloadLimit</name>
<shortdescription lang="en">
@@ -2946,6 +3186,8 @@
<mysqloption id="overloadlimit-shm" section="cluster" subsection="shm">
+ <xrefto id="ndbparam-shm-overloadlimit"/>
+
<name>OverloadLimit</name>
<shortdescription lang="en">
@@ -2970,6 +3212,8 @@
<mysqloption id="overloadlimit-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-overloadlimit"/>
+
<name>OverloadLimit</name>
<shortdescription lang="en">
@@ -2992,6 +3236,8 @@
<mysqloption id="portnumber-mgmd" section="cluster" subsection="mgmd">
+ <xrefto id="ndbparam-mgmd-portnumber"/>
+
<name>PortNumber</name>
<shortdescription lang="en">
@@ -3020,6 +3266,8 @@
<mysqloption id="portnumber-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-portnumber"/>
+
<name>PortNumber</name>
<shortdescription lang="en">
@@ -3043,6 +3291,8 @@
<mysqloption id="portnumber-shm" section="cluster" subsection="shm">
+ <xrefto id="ndbparam-shm-portnumber"/>
+
<name>PortNumber</name>
<shortdescription lang="en">
@@ -3066,6 +3316,8 @@
<mysqloption id="portnumber-sci" section="cluster" subsection="sci">
+ <xrefto id="ndbparam-sci-portnumber"/>
+
<name>PortNumber</name>
<shortdescription lang="en">
@@ -3091,6 +3343,8 @@
<mysqloption id="portnumberstats-mgmd" section="cluster" subsection="mgmd">
+ <xrefto id="ndbparam-mgmd-portnumberstats"/>
+
<name>PortNumberStats</name>
<shortdescription lang="en">
@@ -3117,6 +3371,8 @@
<mysqloption id="primarymgmnode-system" section="cluster" subsection="system">
+ <xrefto id="ndbparam-system-primarymgmnode"/>
+
<name>PrimaryMGMNode</name>
<shortdescription lang="en">
@@ -3142,6 +3398,8 @@
<mysqloption id="proxy-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-proxy"/>
+
<name>Proxy</name>
<shortdescription lang="en"/>
@@ -3163,6 +3421,8 @@
<mysqloption id="realtimescheduler-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-realtimescheduler"/>
+
<name>RealtimeScheduler</name>
<shortdescription lang="en">
@@ -3185,6 +3445,8 @@
<mysqloption id="receivebuffermemory-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-receivebuffermemory"/>
+
<name>ReceiveBufferMemory</name>
<shortdescription lang="en">
@@ -3212,6 +3474,8 @@
<mysqloption id="redobuffer-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-redobuffer"/>
+
<name>RedoBuffer</name>
<shortdescription lang="en">
@@ -3241,6 +3505,8 @@
<mysqloption id="reservedsendbuffermemory-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-reservedsendbuffermemory"/>
+
<name>ReservedSendBufferMemory</name>
<shortdescription lang="en">
@@ -3280,6 +3546,8 @@
<mysqloption id="restartonerrorinsert-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-restartonerrorinsert"/>
+
<name>RestartOnErrorInsert</name>
<shortdescription lang="en">
@@ -3304,6 +3572,8 @@
<mysqloption id="schedulerexecutiontimer-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-schedulerexecutiontimer"/>
+
<name>SchedulerExecutionTimer</name>
<shortdescription lang="en">
@@ -3325,6 +3595,8 @@
<mysqloption id="schedulerspintimer-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-schedulerspintimer"/>
+
<name>SchedulerSpinTimer</name>
<shortdescription lang="en">
@@ -3346,6 +3618,8 @@
<mysqloption id="sendbuffermemory-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-sendbuffermemory"/>
+
<name>SendBufferMemory</name>
<shortdescription lang="en">
@@ -3373,6 +3647,8 @@
<mysqloption id="sendlimit-sci" section="cluster" subsection="sci">
+ <xrefto id="ndbparam-sci-sendlimit"/>
+
<name>SendLimit</name>
<shortdescription lang="en">
@@ -3397,6 +3673,8 @@
<mysqloption id="sendsignalid-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-sendsignalid"/>
+
<name>SendSignalId</name>
<shortdescription lang="en">
@@ -3420,6 +3698,8 @@
<mysqloption id="sendsignalid-shm" section="cluster" subsection="shm">
+ <xrefto id="ndbparam-shm-sendsignalid"/>
+
<name>SendSignalId</name>
<shortdescription lang="en">
@@ -3443,6 +3723,8 @@
<mysqloption id="sendsignalid-sci" section="cluster" subsection="sci">
+ <xrefto id="ndbparam-sci-sendsignalid"/>
+
<name>SendSignalId</name>
<shortdescription lang="en">
@@ -3466,6 +3748,8 @@
<mysqloption id="serverport-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-serverport"/>
+
<name>ServerPort</name>
<shortdescription lang="en">
@@ -3489,6 +3773,8 @@
<mysqloption id="sharedbuffersize-sci" section="cluster" subsection="sci">
+ <xrefto id="ndbparam-sci-sharedbuffersize"/>
+
<name>SharedBufferSize</name>
<shortdescription lang="en">
@@ -3512,6 +3798,8 @@
<mysqloption id="sharedglobalmemory-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-sharedglobalmemory"/>
+
<name>SharedGlobalMemory</name>
<shortdescription lang="en">
@@ -3533,6 +3821,8 @@
<mysqloption id="shmkey-shm" section="cluster" subsection="shm">
+ <xrefto id="ndbparam-shm-shmkey"/>
+
<name>ShmKey</name>
<shortdescription lang="en">
@@ -3556,6 +3846,8 @@
<mysqloption id="shmsize-shm" section="cluster" subsection="shm">
+ <xrefto id="ndbparam-shm-shmsize"/>
+
<name>ShmSize</name>
<shortdescription lang="en">
@@ -3581,6 +3873,8 @@
<mysqloption id="signum-shm" section="cluster" subsection="shm">
+ <xrefto id="ndbparam-shm-signum"/>
+
<name>Signum</name>
<shortdescription lang="en">
@@ -3604,6 +3898,8 @@
<mysqloption id="startfailuretimeout-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-startfailuretimeout"/>
+
<name>StartFailureTimeout</name>
<shortdescription lang="en">
@@ -3627,6 +3923,8 @@
<mysqloption id="startpartialtimeout-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-startpartialtimeout"/>
+
<name>StartPartialTimeout</name>
<shortdescription lang="en">
@@ -3651,6 +3949,8 @@
<mysqloption id="startpartitionedtimeout-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-startpartitionedtimeout"/>
+
<name>StartPartitionedTimeout</name>
<shortdescription lang="en">
@@ -3677,6 +3977,8 @@
<mysqloption id="startupstatusreportfrequency-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-startupstatusreportfrequency"/>
+
<name>StartupStatusReportFrequency</name>
<shortdescription lang="en">
@@ -3696,6 +3998,8 @@
<mysqloption id="stoponerror-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-stoponerror"/>
+
<name>StopOnError</name>
<shortdescription lang="en">
@@ -3720,6 +4024,8 @@
<mysqloption id="stringmemory-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-stringmemory"/>
+
<name>StringMemory</name>
<shortdescription lang="en">
@@ -3750,6 +4056,8 @@
<mysqloption id="tcp_maxseg_size-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-tcp_maxseg_size"/>
+
<name>TCP_MAXSEG_SIZE</name>
<shortdescription lang="en">
@@ -3773,6 +4081,8 @@
<mysqloption id="tcp_rcv_buf_size-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-tcp_rcv_buf_size"/>
+
<name>TCP_RCV_BUF_SIZE</name>
<shortdescription lang="en">
@@ -3796,6 +4106,8 @@
<mysqloption id="tcp_snd_buf_size-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-tcp_snd_buf_size"/>
+
<name>TCP_SND_BUF_SIZE</name>
<shortdescription lang="en">
@@ -3817,6 +4129,8 @@
<mysqloption id="tcpbind_inaddr_any-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-tcpbind_inaddr_any"/>
+
<name>TcpBind_INADDR_ANY</name>
<shortdescription lang="en">
@@ -3839,6 +4153,8 @@
<mysqloption id="tcpbind_inaddr_any-tcp" section="cluster" subsection="tcp">
+ <xrefto id="ndbparam-tcp-tcpbind_inaddr_any"/>
+
<name>TcpBind_INADDR_ANY</name>
<shortdescription lang="en">
@@ -3860,6 +4176,8 @@
<mysqloption id="timebetweenepochs-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-timebetweenepochs"/>
+
<name>TimeBetweenEpochs</name>
<shortdescription lang="en">
@@ -3886,6 +4204,8 @@
<mysqloption id="timebetweenepochstimeout-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-timebetweenepochstimeout"/>
+
<name>TimeBetweenEpochsTimeout</name>
<shortdescription lang="en">
@@ -3913,6 +4233,8 @@
<mysqloption id="timebetweenglobalcheckpoints-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-timebetweenglobalcheckpoints"/>
+
<name>TimeBetweenGlobalCheckpoints</name>
<shortdescription lang="en">
@@ -3940,6 +4262,8 @@
<mysqloption id="timebetweeninactivetransactionabortcheck-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-timebetweeninactivetransactionabortcheck"/>
+
<name>TimeBetweenInactiveTransactionAbortCheck</name>
<shortdescription lang="en">
@@ -3963,6 +4287,8 @@
<mysqloption id="timebetweenlocalcheckpoints-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-timebetweenlocalcheckpoints"/>
+
<name>TimeBetweenLocalCheckpoints</name>
<shortdescription lang="en">
@@ -3987,6 +4313,8 @@
<mysqloption id="timebetweenwatchdogcheck-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-timebetweenwatchdogcheck"/>
+
<name>TimeBetweenWatchDogCheck</name>
<shortdescription lang="en">
@@ -4010,6 +4338,8 @@
<mysqloption id="timebetweenwatchdogcheckinitial-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-timebetweenwatchdogcheckinitial"/>
+
<name>TimeBetweenWatchDogCheckInitial</name>
<shortdescription lang="en">
@@ -4032,6 +4362,8 @@
<mysqloption id="totalsendbuffermemory-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-totalsendbuffermemory"/>
+
<name>TotalSendBufferMemory</name>
<shortdescription lang="en">
@@ -4053,6 +4385,8 @@
<mysqloption id="totalsendbuffermemory-api" section="cluster" subsection="api">
+ <xrefto id="ndbparam-api-totalsendbuffermemory"/>
+
<name>TotalSendBufferMemory</name>
<shortdescription lang="en">
@@ -4074,6 +4408,8 @@
<mysqloption id="transactionbuffermemory-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-transactionbuffermemory"/>
+
<name>TransactionBufferMemory</name>
<shortdescription lang="en">
@@ -4098,6 +4434,8 @@
<mysqloption id="transactiondeadlockdetectiontimeout-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-transactiondeadlockdetectiontimeout"/>
+
<name>TransactionDeadlockDetectionTimeout</name>
<shortdescription lang="en">
@@ -4126,6 +4464,8 @@
<mysqloption id="transactioninactivetimeout-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-transactioninactivetimeout"/>
+
<name>TransactionInactiveTimeout</name>
<shortdescription lang="en">
@@ -4154,6 +4494,8 @@
<mysqloption id="undodatabuffer-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-undodatabuffer"/>
+
<name>UndoDataBuffer</name>
<shortdescription lang="en">
@@ -4178,6 +4520,8 @@
<mysqloption id="undoindexbuffer-ndbd" section="cluster" subsection="ndbd">
+ <xrefto id="ndbparam-ndbd-undoindexbuffer"/>
+
<name>UndoIndexBuffer</name>
<shortdescription lang="en">
@@ -4204,6 +4548,8 @@
<mysqloption id="wan-api" section="cluster" subsection="api">
+ <xrefto id="ndbparam-api-wan"/>
+
<name>wan</name>
<shortdescription lang="en">
@@ -4227,6 +4573,8 @@
<mysqloption id="wan-mgmd" section="cluster" subsection="mgmd">
+ <xrefto id="ndbparam-mgmd-wan"/>
+
<name>wan</name>
<shortdescription lang="en">
@@ -4248,6 +4596,8 @@
<mysqloption id="autoreconnect-api" section="cluster" subsection="api">
+ <xrefto id="ndbparam-api-autoreconnect"/>
+
<name>AutoReconnect</name>
<shortdescription lang="en">
Modified: trunk/mysql-monitor-2.0/Makefile.depends
===================================================================
--- trunk/mysql-monitor-2.0/Makefile.depends 2009-07-30 17:01:52 UTC (rev 15883)
+++ trunk/mysql-monitor-2.0/Makefile.depends 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 11, Lines Added: 29, Lines Deleted: 29; 8942 bytes
@@ -12,10 +12,10 @@
images/published/usage-advisor-configuration.png
dashboard_advisors_SOURCES = dashboard-advisors.xml $(dashboard_advisors_INCLUDES)
dashboard_advisors_IDMAPS = \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-agent.idmap \
+ ../mysql-monitor-common/metadata/dashboard-configure-core.idmap \
+ ../mysql-monitor-common/metadata/install-agent-core.idmap \
metadata/dashboard-advisors.idmap \
metadata/data-items-core.idmap \
- metadata/dynsel-default-monitor-dashboard-configure.idmap \
metadata/install-server.idmap
dashboard-advisors.validpure: $(dashboard_advisors_SOURCES)
dashboard-advisors.titles: $(dashboard_advisors_SOURCES)
@@ -62,15 +62,15 @@
images/published/server-graphs.png
dashboard_overview_SOURCES = dashboard-overview.xml $(dashboard_overview_INCLUDES)
dashboard_overview_IDMAPS = \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-agent.idmap \
+ ../mysql-monitor-common/metadata/dashboard-configure-core.idmap \
+ ../mysql-monitor-common/metadata/dashboard-events-core.idmap \
+ ../mysql-monitor-common/metadata/dashboard-query-analyzer-core.idmap \
+ ../mysql-monitor-common/metadata/install-agent-core.idmap \
+ ../mysql-monitor-common/metadata/mem-reference-core.idmap \
metadata/dashboard-advisors.idmap \
metadata/dashboard-graphs.idmap \
metadata/dashboard-overview.idmap \
metadata/dashboard-replication.idmap \
- metadata/dynsel-default-monitor-dashboard-configure.idmap \
- metadata/dynsel-default-monitor-dashboard-events.idmap \
- metadata/dynsel-default-monitor-dashboard-query-analysis.idmap \
- metadata/dynsel-default-monitor-mem-reference.idmap \
metadata/install-server.idmap
dashboard-overview.validpure: $(dashboard_overview_SOURCES)
dashboard-overview.titles: $(dashboard_overview_SOURCES)
@@ -93,7 +93,7 @@
images/published/replication.png
dashboard_replication_SOURCES = dashboard-replication.xml $(dashboard_replication_INCLUDES)
dashboard_replication_IDMAPS = \
- metadata/dynsel-default-monitor-dashboard-configure.idmap
+ ../mysql-monitor-common/metadata/dashboard-configure-core.idmap
dashboard-replication.validpure: $(dashboard_replication_SOURCES)
dashboard-replication.titles: $(dashboard_replication_SOURCES)
dashboard-replication.useless: $(dashboard_replication_SOURCES)
@@ -132,7 +132,7 @@
images/published/monitor-migration-progress.png
deployment_SOURCES = deployment.xml $(deployment_INCLUDES)
deployment_IDMAPS = \
- metadata/dynsel-default-monitor-dashboard-configure.idmap
+ ../mysql-monitor-common/metadata/dashboard-configure-core.idmap
deployment.validpure: $(deployment_SOURCES)
deployment.titles: $(deployment_SOURCES)
deployment.useless: $(deployment_SOURCES)
@@ -167,12 +167,12 @@
../mysql-monitor-common/images/published/server-rename.png
dynsel_default_monitor_dashboard_configure_SOURCES = dynsel-default-monitor-dashboard-configure.xml $(dynsel_default_monitor_dashboard_configure_INCLUDES)
dynsel_default_monitor_dashboard_configure_IDMAPS = \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-agent.idmap \
+ ../mysql-monitor-common/metadata/dashboard-configure-core.idmap \
+ ../mysql-monitor-common/metadata/dashboard-query-analyzer-core.idmap \
+ ../mysql-monitor-common/metadata/install-agent-core.idmap \
metadata/dashboard-advisors.idmap \
metadata/dashboard-replication.idmap \
metadata/deployment.idmap \
- metadata/dynsel-default-monitor-dashboard-configure.idmap \
- metadata/dynsel-default-monitor-dashboard-query-analysis.idmap \
metadata/install-server.idmap \
metadata/log-files.idmap
dynsel-default-monitor-dashboard-configure.validpure: $(dynsel_default_monitor_dashboard_configure_SOURCES)
@@ -207,8 +207,8 @@
../mysql-monitor-common/images/published/warning_alert.png
dynsel_default_monitor_dashboard_events_SOURCES = dynsel-default-monitor-dashboard-events.xml $(dynsel_default_monitor_dashboard_events_INCLUDES)
dynsel_default_monitor_dashboard_events_IDMAPS = \
- metadata/dynsel-default-monitor-dashboard-configure.idmap \
- metadata/dynsel-default-monitor-dashboard-events.idmap
+ ../mysql-monitor-common/metadata/dashboard-configure-core.idmap \
+ ../mysql-monitor-common/metadata/dashboard-events-core.idmap
dynsel-default-monitor-dashboard-events.validpure: $(dynsel_default_monitor_dashboard_events_SOURCES)
dynsel-default-monitor-dashboard-events.titles: $(dynsel_default_monitor_dashboard_events_SOURCES)
dynsel-default-monitor-dashboard-events.useless: $(dynsel_default_monitor_dashboard_events_SOURCES)
@@ -249,12 +249,12 @@
../mysql-monitor-common/images/published/quan-layout2.png
dynsel_default_monitor_dashboard_query_analyzer_SOURCES = dynsel-default-monitor-dashboard-query-analyzer.xml $(dynsel_default_monitor_dashboard_query_analyzer_INCLUDES)
dynsel_default_monitor_dashboard_query_analyzer_IDMAPS = \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-agent.idmap \
+ ../mysql-monitor-common/metadata/dashboard-query-analyzer-core.idmap \
+ ../mysql-monitor-common/metadata/install-agent-core.idmap \
../refman-5.1/metadata/functions-core.idmap \
../refman-5.1/metadata/sql-syntax-utility.idmap \
../refman-5.1/metadata/tutorial.idmap \
../refman-common/metadata/mysql-proxy-core.idmap \
- metadata/dynsel-default-monitor-dashboard-query-analysis.idmap \
metadata/monitor-faq-core.idmap
dynsel-default-monitor-dashboard-query-analyzer.validpure: $(dynsel_default_monitor_dashboard_query_analyzer_SOURCES)
dynsel-default-monitor-dashboard-query-analyzer.titles: $(dynsel_default_monitor_dashboard_query_analyzer_SOURCES)
@@ -351,15 +351,15 @@
images/published/monitor-update-install-9.png
dynsel_default_monitor_install_SOURCES = dynsel-default-monitor-install.xml $(dynsel_default_monitor_install_INCLUDES)
dynsel_default_monitor_install_IDMAPS = \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-agent.idmap \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-unattended.idmap \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-upgrades.idmap \
+ ../mysql-monitor-common/metadata/dashboard-configure-core.idmap \
+ ../mysql-monitor-common/metadata/dashboard-query-analyzer-core.idmap \
+ ../mysql-monitor-common/metadata/install-agent-core.idmap \
+ ../mysql-monitor-common/metadata/install-unattended-core.idmap \
+ ../mysql-monitor-common/metadata/install-upgrades-core.idmap \
metadata/dashboard-advisors.idmap \
metadata/dashboard-overview.idmap \
metadata/dashboard-replication.idmap \
metadata/deployment.idmap \
- metadata/dynsel-default-monitor-dashboard-configure.idmap \
- metadata/dynsel-default-monitor-dashboard-query-analysis.idmap \
metadata/install-server.idmap \
metadata/install-uninstall.idmap \
metadata/install-user-roles.idmap \
@@ -427,8 +427,8 @@
dynxml_local_monitor_faq_IMAGES =
dynxml_local_monitor_faq_SOURCES = dynxml-local-monitor-faq.xml $(dynxml_local_monitor_faq_INCLUDES)
dynxml_local_monitor_faq_IDMAPS = \
+ ../mysql-monitor-common/metadata/dashboard-query-analyzer-core.idmap \
metadata/deployment.idmap \
- metadata/dynsel-default-monitor-dashboard-query-analysis.idmap \
metadata/monitor-faq-core.idmap
dynxml-local-monitor-faq.validpure: $(dynxml_local_monitor_faq_SOURCES)
dynxml-local-monitor-faq.titles: $(dynxml_local_monitor_faq_SOURCES)
@@ -721,9 +721,13 @@
images/published/usage-advisor-configuration.png
monitor_SOURCES = monitor.xml $(monitor_INCLUDES)
monitor_IDMAPS = \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-agent.idmap \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-unattended.idmap \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-upgrades.idmap \
+ ../mysql-monitor-common/metadata/dashboard-configure-core.idmap \
+ ../mysql-monitor-common/metadata/dashboard-events-core.idmap \
+ ../mysql-monitor-common/metadata/dashboard-query-analyzer-core.idmap \
+ ../mysql-monitor-common/metadata/install-agent-core.idmap \
+ ../mysql-monitor-common/metadata/install-unattended-core.idmap \
+ ../mysql-monitor-common/metadata/install-upgrades-core.idmap \
+ ../mysql-monitor-common/metadata/mem-reference-core.idmap \
../refman-5.1/metadata/functions-core.idmap \
../refman-5.1/metadata/sql-syntax-utility.idmap \
../refman-5.1/metadata/tutorial.idmap \
@@ -734,10 +738,6 @@
metadata/dashboard-replication.idmap \
metadata/data-items-core.idmap \
metadata/deployment.idmap \
- metadata/dynsel-default-monitor-dashboard-configure.idmap \
- metadata/dynsel-default-monitor-dashboard-events.idmap \
- metadata/dynsel-default-monitor-dashboard-query-analysis.idmap \
- metadata/dynsel-default-monitor-mem-reference.idmap \
metadata/install-server.idmap \
metadata/install-uninstall.idmap \
metadata/install-user-roles.idmap \
Modified: trunk/mysql-monitor-2.1/Makefile.depends
===================================================================
--- trunk/mysql-monitor-2.1/Makefile.depends 2009-07-30 17:01:52 UTC (rev 15883)
+++ trunk/mysql-monitor-2.1/Makefile.depends 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 7, Lines Added: 25, Lines Deleted: 25; 6848 bytes
@@ -12,8 +12,8 @@
images/published/dashboard-whatsnew.png
dashboard_whatsnew_SOURCES = dashboard-whatsnew.xml $(dashboard_whatsnew_INCLUDES)
dashboard_whatsnew_IDMAPS = \
- metadata/dashboard-whatsnew.idmap \
- metadata/dynsel-mem21-monitor-dashboard-configure.idmap
+ ../mysql-monitor-common/metadata/dashboard-configure-core.idmap \
+ metadata/dashboard-whatsnew.idmap
dashboard-whatsnew.validpure: $(dashboard_whatsnew_SOURCES)
dashboard-whatsnew.titles: $(dashboard_whatsnew_SOURCES)
dashboard-whatsnew.useless: $(dashboard_whatsnew_SOURCES)
@@ -53,10 +53,10 @@
../mysql-monitor-2.0/metadata/deployment.idmap \
../mysql-monitor-2.0/metadata/install-server.idmap \
../mysql-monitor-2.0/metadata/log-files.idmap \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-agent.idmap \
- metadata/dashboard-whatsnew.idmap \
- metadata/dynsel-mem21-monitor-dashboard-configure.idmap \
- metadata/dynsel-mem21-monitor-dashboard-query-analyzer.idmap
+ ../mysql-monitor-common/metadata/dashboard-configure-core.idmap \
+ ../mysql-monitor-common/metadata/dashboard-query-analyzer-core.idmap \
+ ../mysql-monitor-common/metadata/install-agent-core.idmap \
+ metadata/dashboard-whatsnew.idmap
dynsel-mem21-monitor-dashboard-configure.validpure: $(dynsel_mem21_monitor_dashboard_configure_SOURCES)
dynsel-mem21-monitor-dashboard-configure.titles: $(dynsel_mem21_monitor_dashboard_configure_SOURCES)
dynsel-mem21-monitor-dashboard-configure.useless: $(dynsel_mem21_monitor_dashboard_configure_SOURCES)
@@ -89,8 +89,8 @@
images/published/events-screen.png
dynsel_mem21_monitor_dashboard_events_SOURCES = dynsel-mem21-monitor-dashboard-events.xml $(dynsel_mem21_monitor_dashboard_events_INCLUDES)
dynsel_mem21_monitor_dashboard_events_IDMAPS = \
- metadata/dynsel-mem21-monitor-dashboard-configure.idmap \
- metadata/dynsel-mem21-monitor-dashboard-events.idmap
+ ../mysql-monitor-common/metadata/dashboard-configure-core.idmap \
+ ../mysql-monitor-common/metadata/dashboard-events-core.idmap
dynsel-mem21-monitor-dashboard-events.validpure: $(dynsel_mem21_monitor_dashboard_events_SOURCES)
dynsel-mem21-monitor-dashboard-events.titles: $(dynsel_mem21_monitor_dashboard_events_SOURCES)
dynsel-mem21-monitor-dashboard-events.useless: $(dynsel_mem21_monitor_dashboard_events_SOURCES)
@@ -132,12 +132,12 @@
dynsel_mem21_monitor_dashboard_query_analyzer_SOURCES = dynsel-mem21-monitor-dashboard-query-analyzer.xml $(dynsel_mem21_monitor_dashboard_query_analyzer_INCLUDES)
dynsel_mem21_monitor_dashboard_query_analyzer_IDMAPS = \
../mysql-monitor-2.0/metadata/monitor-faq-core.idmap \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-agent.idmap \
+ ../mysql-monitor-common/metadata/dashboard-query-analyzer-core.idmap \
+ ../mysql-monitor-common/metadata/install-agent-core.idmap \
../refman-5.1/metadata/functions-core.idmap \
../refman-5.1/metadata/sql-syntax-utility.idmap \
../refman-5.1/metadata/tutorial.idmap \
- ../refman-common/metadata/mysql-proxy-core.idmap \
- metadata/dynsel-mem21-monitor-dashboard-query-analyzer.idmap
+ ../refman-common/metadata/mysql-proxy-core.idmap
dynsel-mem21-monitor-dashboard-query-analyzer.validpure: $(dynsel_mem21_monitor_dashboard_query_analyzer_SOURCES)
dynsel-mem21-monitor-dashboard-query-analyzer.titles: $(dynsel_mem21_monitor_dashboard_query_analyzer_SOURCES)
dynsel-mem21-monitor-dashboard-query-analyzer.useless: $(dynsel_mem21_monitor_dashboard_query_analyzer_SOURCES)
@@ -241,11 +241,11 @@
../mysql-monitor-2.0/metadata/install-uninstall.idmap \
../mysql-monitor-2.0/metadata/install-user-roles.idmap \
../mysql-monitor-2.0/metadata/log-files.idmap \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-agent.idmap \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-unattended.idmap \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-upgrades.idmap \
- metadata/dynsel-mem21-monitor-dashboard-configure.idmap \
- metadata/dynsel-mem21-monitor-dashboard-query-analyzer.idmap
+ ../mysql-monitor-common/metadata/dashboard-configure-core.idmap \
+ ../mysql-monitor-common/metadata/dashboard-query-analyzer-core.idmap \
+ ../mysql-monitor-common/metadata/install-agent-core.idmap \
+ ../mysql-monitor-common/metadata/install-unattended-core.idmap \
+ ../mysql-monitor-common/metadata/install-upgrades-core.idmap
dynsel-mem21-monitor-install.validpure: $(dynsel_mem21_monitor_install_SOURCES)
dynsel-mem21-monitor-install.titles: $(dynsel_mem21_monitor_install_SOURCES)
dynsel-mem21-monitor-install.useless: $(dynsel_mem21_monitor_install_SOURCES)
@@ -288,8 +288,8 @@
dynxml_local_news_monitor_IMAGES =
dynxml_local_news_monitor_SOURCES = dynxml-local-news-monitor.xml $(dynxml_local_news_monitor_INCLUDES)
dynxml_local_news_monitor_IDMAPS = \
- metadata/dashboard-whatsnew.idmap \
- metadata/dynsel-mem21-monitor-dashboard-configure.idmap
+ ../mysql-monitor-common/metadata/dashboard-configure-core.idmap \
+ metadata/dashboard-whatsnew.idmap
dynxml-local-news-monitor.validpure: $(dynxml_local_news_monitor_SOURCES)
dynxml-local-news-monitor.titles: $(dynxml_local_news_monitor_SOURCES)
dynxml-local-news-monitor.useless: $(dynxml_local_news_monitor_SOURCES)
@@ -503,18 +503,18 @@
../mysql-monitor-2.0/metadata/install-user-roles.idmap \
../mysql-monitor-2.0/metadata/log-files.idmap \
../mysql-monitor-2.0/metadata/monitor-faq-core.idmap \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-agent.idmap \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-unattended.idmap \
- ../mysql-monitor-common/metadata/dynsel-default-monitor-install-upgrades.idmap \
+ ../mysql-monitor-common/metadata/dashboard-configure-core.idmap \
+ ../mysql-monitor-common/metadata/dashboard-events-core.idmap \
+ ../mysql-monitor-common/metadata/dashboard-query-analyzer-core.idmap \
+ ../mysql-monitor-common/metadata/install-agent-core.idmap \
+ ../mysql-monitor-common/metadata/install-unattended-core.idmap \
+ ../mysql-monitor-common/metadata/install-upgrades-core.idmap \
../mysql-monitor-common/metadata/mem-reference-core.idmap \
../refman-5.1/metadata/functions-core.idmap \
../refman-5.1/metadata/sql-syntax-utility.idmap \
../refman-5.1/metadata/tutorial.idmap \
../refman-common/metadata/mysql-proxy-core.idmap \
- metadata/dashboard-whatsnew.idmap \
- metadata/dynsel-mem21-monitor-dashboard-configure.idmap \
- metadata/dynsel-mem21-monitor-dashboard-events.idmap \
- metadata/dynsel-mem21-monitor-dashboard-query-analyzer.idmap
+ metadata/dashboard-whatsnew.idmap
monitor.validpure: $(monitor_SOURCES)
monitor.titles: $(monitor_SOURCES)
monitor.useless: $(monitor_SOURCES)
Modified: trunk/mysql-monitor-common/Makefile.depends
===================================================================
--- trunk/mysql-monitor-common/Makefile.depends 2009-07-30 17:01:52 UTC (rev 15883)
+++ trunk/mysql-monitor-common/Makefile.depends 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 1, Lines Added: 19, Lines Deleted: 0; 1467 bytes
@@ -571,3 +571,22 @@
install-upgrades-core-manprepped.xml: $(install_upgrades_core_SOURCES) $(install_upgrades_core_IDMAPS)
install-upgrades-core-remprepped.xml: $(install_upgrades_core_SOURCES) $(install_upgrades_core_IDMAPS)
+mem_reference_core_INCLUDES = \
+ ../common/fixedchars.ent \
+ ../common/phrases.ent \
+ ../mysql-monitor-2.1/version.ent \
+ ../refman-common/urls.ent \
+ all-entities.ent \
+ enterprise.ent
+mem_reference_core_IMAGES =
+mem_reference_core_SOURCES = mem-reference-core.xml $(mem_reference_core_INCLUDES)
+mem_reference_core_IDMAPS =
+mem-reference-core.validpure: $(mem_reference_core_SOURCES)
+mem-reference-core.titles: $(mem_reference_core_SOURCES)
+mem-reference-core.useless: $(mem_reference_core_SOURCES)
+mem-reference-core.valid: $(mem_reference_core_SOURCES) $(mem_reference_core_IDMAPS)
+mem-reference-core.validwarn: $(mem_reference_core_SOURCES) $(mem_reference_core_IDMAPS)
+mem-reference-core-prepped.xml: $(mem_reference_core_SOURCES) $(mem_reference_core_IDMAPS)
+mem-reference-core-manprepped.xml: $(mem_reference_core_SOURCES) $(mem_reference_core_IDMAPS)
+mem-reference-core-remprepped.xml: $(mem_reference_core_SOURCES) $(mem_reference_core_IDMAPS)
+
Modified: trunk/ndbapi/Makefile.depends
===================================================================
--- trunk/ndbapi/Makefile.depends 2009-07-30 17:01:52 UTC (rev 15883)
+++ trunk/ndbapi/Makefile.depends 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 5, Lines Added: 5, Lines Deleted: 5; 2471 bytes
@@ -191,7 +191,7 @@
images/published/Ndb-cluster-connection-class.png
class_ndb_cluster_connection_SOURCES = class-ndb-cluster-connection.xml $(class_ndb_cluster_connection_INCLUDES)
class_ndb_cluster_connection_IDMAPS = \
- ../refman-5.1/metadata/mysql-cluster-configuration.idmap \
+ ../refman-5.1/metadata/mysql-cluster-configuration-core.idmap \
metadata/class-ndb-cluster-connection.idmap \
metadata/class-ndb.idmap \
metadata/mgm-api.idmap \
@@ -820,7 +820,7 @@
../refman-5.1/metadata/data-types.idmap \
../refman-5.1/metadata/errors-problems-core.idmap \
../refman-5.1/metadata/functions-core.idmap \
- ../refman-5.1/metadata/mysql-cluster-configuration.idmap \
+ ../refman-5.1/metadata/mysql-cluster-configuration-core.idmap \
../refman-5.1/metadata/mysql-cluster-disk-data.idmap \
../refman-5.1/metadata/partitioning.idmap \
../refman-5.1/metadata/sql-syntax-data-definition.idmap \
@@ -1031,7 +1031,7 @@
images/published/ndb-protocol-uk-lookup-1.png
ndb_internals_SOURCES = ndb-internals.xml $(ndb_internals_INCLUDES)
ndb_internals_IDMAPS = \
- ../refman-5.1/metadata/mysql-cluster-configuration.idmap \
+ ../refman-5.1/metadata/mysql-cluster-configuration-core.idmap \
../refman-5.1/metadata/mysql-cluster-disk-data.idmap \
../refman-5.1/metadata/mysql-cluster-management.idmap \
../refman-5.1/metadata/mysql-cluster-programs-core.idmap \
@@ -1187,7 +1187,7 @@
../refman-5.1/metadata/data-types.idmap \
../refman-5.1/metadata/errors-problems-core.idmap \
../refman-5.1/metadata/functions-core.idmap \
- ../refman-5.1/metadata/mysql-cluster-configuration.idmap \
+ ../refman-5.1/metadata/mysql-cluster-configuration-core.idmap \
../refman-5.1/metadata/mysql-cluster-disk-data.idmap \
../refman-5.1/metadata/mysql-cluster-glossary.idmap \
../refman-5.1/metadata/mysql-cluster-interconnects.idmap \
@@ -1258,7 +1258,7 @@
overview_IMAGES =
overview_SOURCES = overview.xml $(overview_INCLUDES)
overview_IDMAPS = \
- ../refman-5.1/metadata/mysql-cluster-configuration.idmap \
+ ../refman-5.1/metadata/mysql-cluster-configuration-core.idmap \
../refman-5.1/metadata/mysql-cluster-glossary.idmap \
../refman-5.1/metadata/mysql-cluster-interconnects.idmap \
../refman-5.1/metadata/mysql-cluster-programs-core.idmap \
Modified: trunk/quick-guides/Makefile.depends
===================================================================
--- trunk/quick-guides/Makefile.depends 2009-07-30 17:01:52 UTC (rev 15883)
+++ trunk/quick-guides/Makefile.depends 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 2; 1182 bytes
@@ -63,7 +63,7 @@
../refman-4.1/metadata/installing.idmap \
../refman-4.1/metadata/internationalization.idmap \
../refman-4.1/metadata/language-structure.idmap \
- ../refman-4.1/metadata/mysql-cluster-configuration.idmap \
+ ../refman-4.1/metadata/mysql-cluster-configuration-core.idmap \
../refman-4.1/metadata/mysql-cluster-upgrade-downgrade.idmap \
../refman-4.1/metadata/programs-client-core.idmap \
../refman-4.1/metadata/programs-server-core.idmap \
@@ -492,7 +492,7 @@
../refman-4.1/metadata/installing.idmap \
../refman-4.1/metadata/internationalization.idmap \
../refman-4.1/metadata/language-structure.idmap \
- ../refman-4.1/metadata/mysql-cluster-configuration.idmap \
+ ../refman-4.1/metadata/mysql-cluster-configuration-core.idmap \
../refman-4.1/metadata/mysql-cluster-upgrade-downgrade.idmap \
../refman-4.1/metadata/programs-client-core.idmap \
../refman-4.1/metadata/programs-server-core.idmap \
Modified: trunk/refman-4.1/Makefile.depends
===================================================================
--- trunk/refman-4.1/mysql-cluster-configuration-core.xml (rev 0)
+++ trunk/refman-4.1/mysql-cluster-configuration-core.xml 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 26, Lines Added: 6473, Lines Deleted: 47; 249010 bytes
@@ -471,7 +471,7 @@
dba_mysqld_max_IDMAPS = \
metadata/dba-log-files.idmap \
metadata/installing.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/se-innodb-core.idmap \
metadata/sql-syntax-server-administration.idmap \
metadata/storage-engines.idmap
@@ -977,6 +977,36 @@
dynxml-local-functions-manprepped.xml: $(dynxml_local_functions_SOURCES) $(dynxml_local_functions_IDMAPS)
dynxml-local-functions-remprepped.xml: $(dynxml_local_functions_SOURCES) $(dynxml_local_functions_IDMAPS)
dynxml-local-functions.xml: $(dynxml_local_functions_INCLUDES)
+dynxml_local_mysql_cluster_configuration_INCLUDES = \
+ ../../mysqldoc/dynamic-docs/command-optvars/ndb-config-params.xml \
+ ../../mysqldoc/dynamic-docs/metadata-titles.en.xml \
+ ../common/fixedchars.ent \
+ ../common/phrases.ent \
+ ../refman-common/urls.ent \
+ all-entities.ent \
+ mysql-cluster-configuration-core.xml \
+ versions.ent
+dynxml_local_mysql_cluster_configuration_IMAGES =
+dynxml_local_mysql_cluster_configuration_SOURCES = dynxml-local-mysql-cluster-configuration.xml $(dynxml_local_mysql_cluster_configuration_INCLUDES)
+dynxml_local_mysql_cluster_configuration_IDMAPS = \
+ ../refman-common/metadata/bug-reports.idmap \
+ metadata/dba-mysqld-server-core.idmap \
+ metadata/installing.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
+ metadata/mysql-cluster-interconnects.idmap \
+ metadata/mysql-cluster-limitations.idmap \
+ metadata/mysql-cluster-management.idmap \
+ metadata/mysql-cluster-optvar-core.idmap \
+ metadata/mysql-cluster-programs-core.idmap
+dynxml-local-mysql-cluster-configuration.validpure: $(dynxml_local_mysql_cluster_configuration_SOURCES)
+dynxml-local-mysql-cluster-configuration.titles: $(dynxml_local_mysql_cluster_configuration_SOURCES)
+dynxml-local-mysql-cluster-configuration.useless: $(dynxml_local_mysql_cluster_configuration_SOURCES)
+dynxml-local-mysql-cluster-configuration.valid: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration.validwarn: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration-prepped.xml: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration-manprepped.xml: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration-remprepped.xml: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration.xml: $(dynxml_local_mysql_cluster_configuration_INCLUDES)
dynxml_local_mysql_cluster_optvar_INCLUDES = \
../../mysqldoc/dynamic-docs/command-optvars/mysqld.xml \
../../mysqldoc/dynamic-docs/metadata-titles.en.xml \
@@ -990,7 +1020,7 @@
dynxml_local_mysql_cluster_optvar_SOURCES = dynxml-local-mysql-cluster-optvar.xml $(dynxml_local_mysql_cluster_optvar_INCLUDES)
dynxml_local_mysql_cluster_optvar_IDMAPS = \
metadata/dba-mysqld-server-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-optvar-core.idmap \
metadata/mysql-cluster-programs-core.idmap
dynxml-local-mysql-cluster-optvar.validpure: $(dynxml_local_mysql_cluster_optvar_SOURCES)
@@ -1026,7 +1056,7 @@
dynxml_local_mysql_cluster_programs_IDMAPS = \
../ndbapi/metadata/ndb-errors.idmap \
../ndbapi/metadata/ndb-internals.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-glossary.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-management.idmap \
@@ -1273,7 +1303,7 @@
metadata/extending-mysql.idmap \
metadata/installing.idmap \
metadata/internationalization.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/programs-admin-util-core.idmap \
metadata/programs-using.idmap \
metadata/replication.idmap \
@@ -1366,7 +1396,7 @@
metadata/installing.idmap \
metadata/internationalization.idmap \
metadata/language-structure.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-programs-core.idmap \
metadata/news-4.0.idmap \
metadata/news-4.1-core.idmap \
@@ -1560,6 +1590,7 @@
../../mysqldoc/dynamic-docs/command-optvars/mysqlhotcopy.xml \
../../mysqldoc/dynamic-docs/command-optvars/mysqlimport.xml \
../../mysqldoc/dynamic-docs/command-optvars/mysqlshow.xml \
+ ../../mysqldoc/dynamic-docs/command-optvars/ndb-config-params.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_common.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_config.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_error_reporter.xml \
@@ -1754,6 +1785,7 @@
dynxml-local-dba-security.xml \
dynxml-local-dba-user-management.xml \
dynxml-local-functions.xml \
+ dynxml-local-mysql-cluster-configuration.xml \
dynxml-local-mysql-cluster-optvar.xml \
dynxml-local-mysql-cluster-programs.xml \
dynxml-local-news-4.1.xml \
@@ -1771,7 +1803,7 @@
introduction.xml \
language-structure.xml \
legalnotice.en.xml \
- mysql-cluster-configuration.xml \
+ mysql-cluster-configuration-core.xml \
mysql-cluster-faq.xml \
mysql-cluster-glossary.xml \
mysql-cluster-interconnects.xml \
@@ -1995,7 +2027,7 @@
metadata/internationalization.idmap \
metadata/introduction.idmap \
metadata/language-structure.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-faq.idmap \
metadata/mysql-cluster-glossary.idmap \
metadata/mysql-cluster-interconnects.idmap \
@@ -2045,32 +2077,18 @@
manual-manprepped.xml: $(manual_SOURCES) $(manual_IDMAPS)
manual-remprepped.xml: $(manual_SOURCES) $(manual_IDMAPS)
-mysql_cluster_configuration_INCLUDES = \
- ../common/fixedchars.ent \
- ../common/phrases.ent \
- ../refman-common/urls.ent \
- all-entities.ent \
- versions.ent
-mysql_cluster_configuration_IMAGES =
-mysql_cluster_configuration_SOURCES = mysql-cluster-configuration.xml $(mysql_cluster_configuration_INCLUDES)
-mysql_cluster_configuration_IDMAPS = \
- ../refman-common/metadata/bug-reports.idmap \
- metadata/dba-mysqld-server-core.idmap \
- metadata/installing.idmap \
- metadata/mysql-cluster-configuration.idmap \
- metadata/mysql-cluster-interconnects.idmap \
- metadata/mysql-cluster-limitations.idmap \
- metadata/mysql-cluster-management.idmap \
- metadata/mysql-cluster-optvar-core.idmap \
- metadata/mysql-cluster-programs-core.idmap
-mysql-cluster-configuration.validpure: $(mysql_cluster_configuration_SOURCES)
-mysql-cluster-configuration.titles: $(mysql_cluster_configuration_SOURCES)
-mysql-cluster-configuration.useless: $(mysql_cluster_configuration_SOURCES)
-mysql-cluster-configuration.valid: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
-mysql-cluster-configuration.validwarn: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
-mysql-cluster-configuration-prepped.xml: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
-mysql-cluster-configuration-manprepped.xml: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
-mysql-cluster-configuration-remprepped.xml: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
+mysql_cluster_configuration_core_INCLUDES =
+mysql_cluster_configuration_core_IMAGES =
+mysql_cluster_configuration_core_SOURCES = mysql-cluster-configuration-core.xml $(mysql_cluster_configuration_core_INCLUDES)
+mysql_cluster_configuration_core_IDMAPS =
+mysql-cluster-configuration-core.validpure: $(mysql_cluster_configuration_core_SOURCES)
+mysql-cluster-configuration-core.titles: $(mysql_cluster_configuration_core_SOURCES)
+mysql-cluster-configuration-core.useless: $(mysql_cluster_configuration_core_SOURCES)
+mysql-cluster-configuration-core.valid: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
+mysql-cluster-configuration-core.validwarn: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
+mysql-cluster-configuration-core-prepped.xml: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
+mysql-cluster-configuration-core-manprepped.xml: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
+mysql-cluster-configuration-core-remprepped.xml: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
mysql_cluster_faq_INCLUDES = \
../common/fixedchars.ent \
@@ -2084,7 +2102,7 @@
../ndbapi/metadata/ndb-internals.idmap \
../ndbapi/metadata/overview.idmap \
metadata/data-types.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-interconnects.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-management.idmap \
@@ -2113,7 +2131,7 @@
mysql_cluster_glossary_IMAGES =
mysql_cluster_glossary_SOURCES = mysql-cluster-glossary.xml $(mysql_cluster_glossary_INCLUDES)
mysql_cluster_glossary_IDMAPS = \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-interconnects.idmap \
metadata/mysql-cluster-management.idmap \
metadata/mysql-cluster-overview.idmap \
@@ -2136,7 +2154,7 @@
mysql_cluster_interconnects_IMAGES =
mysql_cluster_interconnects_SOURCES = mysql-cluster-interconnects.xml $(mysql_cluster_interconnects_INCLUDES)
mysql_cluster_interconnects_IDMAPS = \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-interconnects.idmap
mysql-cluster-interconnects.validpure: $(mysql_cluster_interconnects_SOURCES)
mysql-cluster-interconnects.titles: $(mysql_cluster_interconnects_SOURCES)
@@ -2158,7 +2176,7 @@
mysql_cluster_limitations_IDMAPS = \
../refman-common/metadata/bug-reports.idmap \
../refman-common/metadata/news-cluster.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-management.idmap \
metadata/mysql-cluster-upgrade-downgrade.idmap \
@@ -2185,7 +2203,7 @@
../ndbapi/metadata/ndb-errors.idmap \
../ndbapi/metadata/ndb-internals.idmap \
metadata/dba-mysqld-server-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-management.idmap \
metadata/mysql-cluster-optvar-core.idmap \
metadata/mysql-cluster-programs-core.idmap \
@@ -2213,7 +2231,7 @@
mysql_cluster_multi_computer_IDMAPS = \
metadata/dba-mysqld-max.idmap \
metadata/installing.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-interconnects.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-management.idmap \
@@ -2260,7 +2278,7 @@
mysql_cluster_overview_IDMAPS = \
../ndbapi/metadata/getting-started.idmap \
../ndbapi/metadata/mgm-api.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-overview.idmap
mysql-cluster-overview.validpure: $(mysql_cluster_overview_SOURCES)
@@ -2301,7 +2319,7 @@
mysql_cluster_security_SOURCES = mysql-cluster-security.xml $(mysql_cluster_security_INCLUDES)
mysql_cluster_security_IDMAPS = \
metadata/dba-security-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-programs-core.idmap \
metadata/mysql-cluster-security.idmap
mysql-cluster-security.validpure: $(mysql_cluster_security_SOURCES)
@@ -2327,7 +2345,7 @@
mysql_cluster_upgrade_downgrade_SOURCES = mysql-cluster-upgrade-downgrade.xml $(mysql_cluster_upgrade_downgrade_INCLUDES)
mysql_cluster_upgrade_downgrade_IDMAPS = \
metadata/installing.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-upgrade-downgrade.idmap
mysql-cluster-upgrade-downgrade.validpure: $(mysql_cluster_upgrade_downgrade_SOURCES)
mysql-cluster-upgrade-downgrade.titles: $(mysql_cluster_upgrade_downgrade_SOURCES)
@@ -2340,6 +2358,7 @@
mysql_cluster_INCLUDES = \
../../mysqldoc/dynamic-docs/command-optvars/mysqld.xml \
+ ../../mysqldoc/dynamic-docs/command-optvars/ndb-config-params.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_common.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_config.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_error_reporter.xml \
@@ -2364,9 +2383,10 @@
../refman-common/images/published/rolling-restarts.png \
../refman-common/urls.ent \
all-entities.ent \
+ dynxml-local-mysql-cluster-configuration.xml \
dynxml-local-mysql-cluster-optvar.xml \
dynxml-local-mysql-cluster-programs.xml \
- mysql-cluster-configuration.xml \
+ mysql-cluster-configuration-core.xml \
mysql-cluster-faq.xml \
mysql-cluster-glossary.xml \
mysql-cluster-interconnects.xml \
@@ -2405,7 +2425,7 @@
metadata/dba-mysqld-server-core.idmap \
metadata/dba-security-core.idmap \
metadata/installing.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-faq.idmap \
metadata/mysql-cluster-glossary.idmap \
metadata/mysql-cluster-interconnects.idmap \
@@ -2743,7 +2763,7 @@
metadata/dba-mysqld-server-core.idmap \
metadata/dba-user-management-core.idmap \
metadata/installing.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-multi-computer.idmap \
metadata/programs-using.idmap \
metadata/sql-syntax-server-administration.idmap
@@ -2800,7 +2820,7 @@
metadata/dba-user-management-core.idmap \
metadata/installing.idmap \
metadata/internationalization.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-multi-computer.idmap \
metadata/mysql-cluster.idmap \
metadata/optimization.idmap \
Copied: trunk/refman-4.1/mysql-cluster-configuration-core.xml (from rev 15880, trunk/refman-4.1/mysql-cluster-configuration.xml)
===================================================================
--- trunk/refman-4.1/mysql-cluster-configuration-core.xml (rev 0)
+++ trunk/refman-4.1/mysql-cluster-configuration-core.xml 2009-07-30 19:12:22 UTC (rev 15884)
@@ -0,0 +1,6406 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY % all.entities SYSTEM "all-entities.ent">
+ %all.entities;
+]>
+<section id="mysql-cluster-configuration">
+
+ <title>MySQL Cluster Configuration</title>
+
+ <indexterm>
+ <primary>configuring MySQL Cluster</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <remark role="dynamic-dependency-list"/>
+
+ <para>
+ A MySQL server that is part of a MySQL Cluster differs in one chief
+ respect from a normal (nonclustered) MySQL server, in that it
+ employs the <literal role="se">NDBCLUSTER</literal> storage engine.
+ This engine is also referred to simply as
+ <literal role="se">NDB</literal>, and the two forms of the name are
+ synonymous.
+ </para>
+
+ <para>
+ To avoid unnecessary allocation of resources, the server is
+ configured by default with the <literal role="se">NDB</literal>
+ storage engine disabled. To enable <literal role="se">NDB</literal>,
+ you must modify the server's <filename>my.cnf</filename>
+ configuration file, or start the server with the
+ <option role="mysqld">--ndbcluster</option> option.
+ </para>
+
+ <para>
+ For more information about
+ <option role="mysqld">--ndbcluster</option> and other MySQL server
+ options specific to MySQL Cluster, see
+ <xref linkend="mysql-cluster-program-options-mysqld"/>.
+ </para>
+
+ <para>
+ The MySQL server is a part of the cluster, so it also must know how
+ to access an MGM node to obtain the cluster configuration data. The
+ default behavior is to look for the MGM node on
+ <literal>localhost</literal>. However, should you need to specify
+ that its location is elsewhere, this can be done in
+ <filename>my.cnf</filename> or on the MySQL server command line.
+ Before the <literal role="se">NDB</literal> storage engine can be
+ used, at least one MGM node must be operational, as well as any
+ desired data nodes.
+ </para>
+
+ <section id="mysql-cluster-building">
+
+ <title>Building MySQL Cluster from Source Code</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>compiling from source</secondary>
+ </indexterm>
+
+ <para>
+ <literal role="se">NDB</literal>, the Cluster storage engine, is
+ available in binary distributions for Linux, Mac OS X, and
+ Solaris. We are working to make Cluster run on all operating
+ systems supported by MySQL, including Windows.
+ </para>
+
+ <para>
+ If you choose to build from a source tarball or one of the MySQL
+ Cluster public development trees, be sure to use the
+ <option>--with-ndbcluster</option> option when running
+ <command>configure</command>. You can also use the
+ <command>BUILD/compile-pentium-max</command> build script. Note
+ that this script includes OpenSSL, so you must either have or
+ obtain OpenSSL to build successfully, or else modify
+ <command>compile-pentium-max</command> to exclude this
+ requirement. Of course, you can also just follow the standard
+ instructions for compiling your own binaries, and then perform the
+ usual tests and installation procedure. See
+ <xref linkend="installing-source-tree"/>.
+ </para>
+
+ <para>
+ You should also note that <command>compile-pentium-max</command>
+ installs MySQL to the directory
+ <filename>/usr/local/mysql</filename>, placing all MySQL Cluster
+ executables, scripts, databases, and support files in
+ subdirectories under this directory. If this is not what you
+ desire, be sure to modify the script accordingly.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-installing">
+
+ <title>Installing MySQL Cluster Software</title>
+
+ <indexterm>
+ <primary>installing MySQL Cluster</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>installation</secondary>
+ </indexterm>
+
+ <para>
+ In the next few sections, we assume that you are already familiar
+ with installing MySQL, and here we cover only the differences
+ between configuring MySQL Cluster and configuring MySQL without
+ clustering. (See <xref linkend="installing"/>, if you require more
+ information about the latter.)
+ </para>
+
+ <para>
+ You will find Cluster configuration easiest if you have already
+ have all management and data nodes running first; this is likely
+ to be the most time-consuming part of the configuration. Editing
+ the <filename>my.cnf</filename> file is fairly straightforward,
+ and this section will cover only any differences from configuring
+ MySQL without clustering.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-quick">
+
+ <title>Quick Test Setup of MySQL Cluster</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>"quick" configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>starting</secondary>
+ </indexterm>
+
+ <para>
+ To familiarize you with the basics, we will describe the simplest
+ possible configuration for a functional MySQL Cluster. After this,
+ you should be able to design your desired setup from the
+ information provided in the other relevant sections of this
+ chapter.
+ </para>
+
+ <para>
+ First, you need to create a configuration directory such as
+ <filename>/var/lib/mysql-cluster</filename>, by executing the
+ following command as the system <literal>root</literal> user:
+ </para>
+
+<programlisting>
+shell> <userinput>mkdir /var/lib/mysql-cluster</userinput>
+</programlisting>
+
+ <para>
+ In this directory, create a file named
+ <filename>config.ini</filename> that contains the following
+ information. Substitute appropriate values for
+ <literal>HostName</literal> and <literal>DataDir</literal> as
+ necessary for your system.
+ </para>
+
+<programlisting>
+# file "config.ini" - showing minimal setup consisting of 1 data node,
+# 1 management server, and 3 MySQL servers.
+# The empty default sections are not required, and are shown only for
+# the sake of completeness.
+# Data nodes must provide a hostname but MySQL Servers are not required
+# to do so.
+# If you don't know the hostname for your machine, use localhost.
+# The DataDir parameter also has a default value, but it is recommended to
+# set it explicitly.
+# Note: [db], [api], and [mgm] are aliases for [ndbd], [mysqld], and [ndb_mgmd],
+# respectively. [db] is deprecated and should not be used in new installations.
+
+[ndbd default]
+NoOfReplicas= 1
+
+[mysqld default]
+[ndb_mgmd default]
+[tcp default]
+
+[ndb_mgmd]
+HostName= myhost.example.com
+
+[ndbd]
+HostName= myhost.example.com
+DataDir= /var/lib/mysql-cluster
+
+[mysqld]
+[mysqld]
+[mysqld]
+</programlisting>
+
+ <para>
+ You can now start the <command>ndb_mgmd</command> management
+ server. By default, it attempts to read the
+ <filename>config.ini</filename> file in its current working
+ directory, so change location into the directory where the file is
+ located and then invoke <command>ndb_mgmd</command>:
+ </para>
+
+<programlisting>
+shell> <userinput>cd /var/lib/mysql-cluster</userinput>
+shell> <userinput>ndb_mgmd</userinput>
+</programlisting>
+
+ <para>
+ Then start a single data node by running <command>ndbd</command>:
+ </para>
+
+<programlisting>
+shell> <userinput>ndbd</userinput>
+</programlisting>
+
+ <para>
+ For command-line options which can be used when starting
+ <command>ndbd</command>, see
+ <xref linkend="mysql-cluster-program-options-common"/>.
+ </para>
+
+ <para>
+ By default, <command>ndbd</command> looks for the management
+ server at <literal>localhost</literal> on port 1186. (Prior to
+ MySQL 4.1.8, the default port was 2200.)
+ </para>
+
+ <note>
+ <para>
+ If you have installed MySQL from a binary tarball, you will need
+ to specify the path of the <command>ndb_mgmd</command> and
+ <command>ndbd</command> servers explicitly. (Normally, these
+ will be found in <filename>/usr/local/mysql/bin</filename>.)
+ </para>
+ </note>
+
+ <para>
+ Finally, change location to the MySQL data directory (usually
+ <filename>/var/lib/mysql</filename> or
+ <filename>/usr/local/mysql/data</filename>), and make sure that
+ the <filename>my.cnf</filename> file contains the option necessary
+ to enable the NDB storage engine:
+ </para>
+
+<programlisting>
+[mysqld]
+ndbcluster
+</programlisting>
+
+ <para>
+ You can now start the MySQL server as usual:
+ </para>
+
+<programlisting>
+shell> <userinput>mysqld_safe --user=mysql &</userinput>
+</programlisting>
+
+ <para>
+ Wait a moment to make sure the MySQL server is running properly.
+ If you see the notice <literal>mysql ended</literal>, check the
+ server's <filename>.err</filename> file to find out what went
+ wrong.
+ </para>
+
+ <para>
+ If all has gone well so far, you now can start using the cluster.
+ Connect to the server and verify that the
+ <literal role="se">NDBCLUSTER</literal> storage engine is enabled:
+ </para>
+
+<programlisting>
+shell> <userinput>mysql</userinput>
+Welcome to the MySQL monitor. Commands end with ; or \g.
+Your MySQL connection id is 1 to server version: ¤t-version;-Max
+
+Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
+
+mysql> <userinput>SHOW ENGINES\G</userinput>
+...
+*************************** 12. row ***************************
+Engine: NDBCLUSTER
+Support: YES
+Comment: Clustered, fault-tolerant, memory-based tables
+*************************** 13. row ***************************
+Engine: NDB
+Support: YES
+Comment: Alias for NDBCLUSTER
+...
+</programlisting>
+
+ <para>
+ The row numbers shown in the preceding example output may be
+ different from those shown on your system, depending upon how your
+ server is configured.
+ </para>
+
+ <para>
+ Try to create an <literal role="se">NDBCLUSTER</literal> table:
+ </para>
+
+<programlisting>
+shell> <userinput>mysql</userinput>
+mysql> <userinput>USE test;</userinput>
+Database changed
+
+mysql> <userinput>CREATE TABLE ctest (i INT) ENGINE=NDBCLUSTER;</userinput>
+Query OK, 0 rows affected (0.09 sec)
+
+mysql> <userinput>SHOW CREATE TABLE ctest \G</userinput>
+*************************** 1. row ***************************
+ Table: ctest
+Create Table: CREATE TABLE `ctest` (
+ `i` int(11) default NULL
+) ENGINE=ndbcluster DEFAULT CHARSET=latin1
+1 row in set (0.00 sec)
+</programlisting>
+
+ <para>
+ To check that your nodes were set up properly, start the
+ management client:
+ </para>
+
+<programlisting>
+shell> <userinput>ndb_mgm</userinput>
+</programlisting>
+
+ <indexterm>
+ <primary>SHOW</primary>
+ <secondary>in MySQL Cluster management client</secondary>
+ </indexterm>
+
+ <para>
+ Use the <command>SHOW</command> command from within the management
+ client to obtain a report on the cluster's status:
+ </para>
+
+<programlisting>
+ndb_mgm> <userinput>SHOW</userinput>
+Cluster Configuration
+---------------------
+[ndbd(NDB)] 1 node(s)
+id=2 @127.0.0.1 (Version: 3.5.3, Nodegroup: 0, Master)
+
+[ndb_mgmd(MGM)] 1 node(s)
+id=1 @127.0.0.1 (Version: 3.5.3)
+
+[mysqld(API)] 3 node(s)
+id=3 @127.0.0.1 (Version: 3.5.3)
+id=4 (not connected, accepting connect from any host)
+id=5 (not connected, accepting connect from any host)
+</programlisting>
+
+ <para>
+ At this point, you have successfully set up a working MySQL
+ Cluster. You can now store data in the cluster by using any table
+ created with <literal>ENGINE=NDBCLUSTER</literal> or its alias
+ <literal>ENGINE=NDB</literal>.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-config-file">
+
+ <title>MySQL Cluster Configuration Files</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration files</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>my.cnf</primary>
+ <secondary>and MySQL Cluster</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>config.ini (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ Configuring MySQL Cluster requires working with two files:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <filename>my.cnf</filename>: Specifies options for all MySQL
+ Cluster executables. This file, with which you should be
+ familiar with from previous work with MySQL, must be
+ accessible by each executable running in the cluster.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>config.ini</filename>: This file, sometimes known as
+ the <firstterm>global configuration file</firstterm>, is read
+ only by the MySQL Cluster management server, which then
+ distributes the information contained therein to all processes
+ participating in the cluster. <filename>config.ini</filename>
+ contains a description of each node involved in the cluster.
+ This includes configuration parameters for data nodes and
+ configuration parameters for connections between all nodes in
+ the cluster. For a quick reference to the sections that can
+ appear in this file, and what sorts of configuration
+ parameters may be placed in each section, see
+ <link linkend="mysql-cluster-config-ini-sections">Sections of
+ the <filename>config.ini</filename> File</link>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ We are continuously making improvements in Cluster configuration
+ and attempting to simplify this process. Although we strive to
+ maintain backward compatibility, there may be times when introduce
+ an incompatible change. In such cases we will try to let Cluster
+ users know in advance if a change is not backward compatible. If
+ you find such a change and we have not documented it, please
+ report it in the MySQL bugs database using the instructions given
+ in <xref linkend="bug-reports"/>.
+ </para>
+
+ <section id="mysql-cluster-config-example">
+
+ <title>MySQL Cluster Configuration — Basic Example</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration (example)</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>my.cnf</primary>
+ <secondary>and MySQL Cluster</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>config.ini (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ To support MySQL Cluster, you will need to update
+ <filename>my.cnf</filename> as shown in the following example.
+ You may also specify these parameters on the command line when
+ invoking the executables.
+ </para>
+
+ <para>
+ In MySQL 4.1.8, some simplifications in
+ <filename>my.cnf</filename> were introduced, including new
+ sections for <literal role="se">NDBCLUSTER</literal>
+ executables.
+ </para>
+
+ <note>
+ <para>
+ The options shown here should not be confused with those that
+ are used in <filename>config.ini</filename> global
+ configuration files. Global configuration options are
+ discussed later in this section.
+ </para>
+ </note>
+
+<programlisting>
+# my.cnf
+# example additions to my.cnf for MySQL Cluster
+# (valid from 4.1.8)
+
+# enable ndbcluster storage engine, and provide connectstring for
+# management server host (default port is 1186)
+[mysqld]
+ndbcluster
+ndb-connectstring=ndb_mgmd.mysql.com
+
+
+# provide connectstring for management server host (default port: 1186)
+[ndbd]
+connect-string=ndb_mgmd.mysql.com
+
+# provide connectstring for management server host (default port: 1186)
+[ndb_mgm]
+connect-string=ndb_mgmd.mysql.com
+
+# provide location of cluster configuration file
+[ndb_mgmd]
+config-file=/etc/config.ini
+</programlisting>
+
+ <para>
+ (For more information on connectstrings, see
+ <xref linkend="mysql-cluster-connectstring"/>.)
+ </para>
+
+<programlisting>
+# my.cnf
+# example additions to my.cnf for MySQL Cluster
+# (will work on all versions)
+
+# enable ndbcluster storage engine, and provide connectstring for management
+# server host to the default port 1186
+[mysqld]
+ndbcluster
+ndb-connectstring=ndb_mgmd.mysql.com:1186
+</programlisting>
+
+ <important>
+ <para>
+ Once you have started a <command>mysqld</command> process with
+ the <literal role="se">NDBCLUSTER</literal> and
+ <literal>ndb-connectstring</literal> parameters in the
+ <literal>[mysqld]</literal> in the <filename>my.cnf</filename>
+ file as shown previously, you cannot execute any
+ <literal role="stmt">CREATE TABLE</literal> or
+ <literal role="stmt">ALTER TABLE</literal> statements without
+ having actually started the cluster. Otherwise, these
+ statements will fail with an error. <emphasis>This is by
+ design</emphasis>.
+ </para>
+ </important>
+
+ <para>
+ Starting with MySQL 4.1.8, you may also use a separate
+ <literal>[mysql_cluster]</literal> section in the cluster
+ <filename>my.cnf</filename> file for settings to be read and
+ used by all executables:
+ </para>
+
+<programlisting>
+# cluster-specific settings
+[mysql_cluster]
+ndb-connectstring=ndb_mgmd.mysql.com:1186
+</programlisting>
+
+ <para>
+ For additional <literal role="se">NDB</literal> variables that
+ can be set in the <filename>my.cnf</filename> file, see
+ <xref linkend="mysql-cluster-system-variables"/>.
+ </para>
+
+ <para>
+ The MySQL Cluster global configuration file is named
+ <filename>config.ini</filename> by default. It is read by
+ <command>ndb_mgmd</command> at startup and can be placed
+ anywhere. Its location and name are specified by using
+ <option>--config-file=<replaceable>path_name</replaceable></option>
+ on the <command>ndb_mgmd</command> command line. If the
+ configuration file is not specified, <command>ndb_mgmd</command>
+ by default tries to read a file named
+ <filename>config.ini</filename> located in the current working
+ directory.
+ </para>
+
+ <para>
+ The global configuration file for MySQL Cluster uses INI format,
+ which consists of sections preceded by section headings
+ (surrounded by square brackets), followed by the appropriate
+ parameter names and values. One deviation from the standard INI
+ format is that the parameter name and value can be separated by
+ a colon (<quote><literal>:</literal></quote>) as well as the
+ equals sign (<quote><literal>=</literal></quote>); however, the
+ equals sign is preferred. Another deviation is that sections are
+ not uniquely identified by section name. Instead, unique
+ sections (such as two different nodes of the same type) are
+ identified by a unique ID specified as a parameter within the
+ section.
+ </para>
+
+ <para>
+ Default values are defined for most parameters, and can also be
+ specified in <filename>config.ini</filename>.
+ (<emphasis>Exception</emphasis>: The
+ <literal>NoOfReplicas</literal> configuration parameter has no
+ default value, and must always be specified explicitly in the
+ <literal>[ndbd default]</literal> section.) To create a default
+ value section, simply add the word <literal>default</literal> to
+ the section name. For example, an <literal>[ndbd]</literal>
+ section contains parameters that apply to a particular data
+ node, whereas an <literal>[ndbd default]</literal> section
+ contains parameters that apply to all data nodes. Suppose that
+ all data nodes should use the same data memory size. To
+ configure them all, create an <literal>[ndbd default]</literal>
+ section that contains a <literal>DataMemory</literal> line to
+ specify the data memory size.
+ </para>
+
+ <para>
+ The global configuration file must define the computers and
+ nodes involved in the cluster and on which computers these nodes
+ are located. An example of a simple configuration file for a
+ cluster consisting of one management server, two data nodes and
+ two MySQL servers is shown here:
+ </para>
+
+<programlisting>
+# file "config.ini" - 2 data nodes and 2 SQL nodes
+# This file is placed in the startup directory of ndb_mgmd (the
+# management server)
+# The first MySQL Server can be started from any host. The second
+# can be started only on the host mysqld_5.mysql.com
+
+[ndbd default]
+NoOfReplicas= 2
+DataDir= /var/lib/mysql-cluster
+
+[ndb_mgmd]
+Hostname= ndb_mgmd.mysql.com
+DataDir= /var/lib/mysql-cluster
+
+[ndbd]
+HostName= ndbd_2.mysql.com
+
+[ndbd]
+HostName= ndbd_3.mysql.com
+
+[mysqld]
+[mysqld]
+HostName= mysqld_5.mysql.com
+</programlisting>
+
+ <para>
+ Each node has its own section in the
+ <filename>config.ini</filename> file. For example, this cluster
+ has two data nodes, so the preceding configuration file contains
+ two <literal>[ndbd]</literal> sections defining these nodes.
+ </para>
+
+ <note>
+ <para>
+ Do not place comments on the same line as a section heading in
+ the <filename>config.ini</filename> file; this causes the
+ management server not to start because it cannot parse the
+ configuration file in such cases.
+ </para>
+ </note>
+
+ <para id="mysql-cluster-config-ini-sections">
+ <emphasis role="bold">Sections of the
+ <filename>config.ini</filename> File</emphasis>
+ </para>
+
+ <para>
+ There are six different sections that you can use in the
+ <filename>config.ini</filename> configuration file, as described
+ in the following list:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>[computer]</literal>: Defines cluster hosts. This
+ is not required to configure a viable MySQL Cluster, but be
+ may used as a convenience when setting up a large cluster.
+ See <xref linkend="mysql-cluster-computer-definition"/>, for
+ more information.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[ndbd]</literal>: Defines a cluster data node
+ (<command>ndbd</command> process). See
+ <xref linkend="mysql-cluster-ndbd-definition"/>, for
+ details.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[mysqld]</literal>: Defines the cluster's MySQL
+ server nodes (also called SQL or API nodes). For a
+ discussion of SQL node configuration, see
+ <xref linkend="mysql-cluster-api-definition"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[mgm]</literal> or <literal>[ndb_mgmd]</literal>:
+ Defines a cluster management server (MGM) node. For
+ information concerning the configuration of MGM nodes, see
+ <xref linkend="mysql-cluster-mgm-definition"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[tcp]</literal>: Defines a TCP/IP connection
+ between cluster nodes, with TCP/IP being the default
+ connection protocol. Normally, <literal>[tcp]</literal> or
+ <literal>[tcp default]</literal> sections are not required
+ to set up a MySQL Cluster, as the cluster handles this
+ automatically; however, it may be necessary in some
+ situations to override the defaults provided by the cluster.
+ See <xref linkend="mysql-cluster-tcp-definition"/>, for
+ information about available TCP/IP configuration parameters
+ and how to use them. (You may also find
+ <xref linkend="mysql-cluster-tcp-definition-direct"/> to be
+ of interest in some cases.)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[shm]</literal>: Defines shared-memory connections
+ between nodes. Prior to MySQL 4.1.9, this type of connection
+ was available only in binaries that were built using the
+ <option>--with-ndb-shm</option> option. Beginning with MySQL
+ 4.1.9-max, it is enabled by default, but should still be
+ considered experimental. For a discussion of SHM
+ interconnects, see
+ <xref linkend="mysql-cluster-shm-definition"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[sci]</literal>:Defines <firstterm>Scalable
+ Coherent Interface</firstterm> connections between cluster
+ data nodes. Such connections require software which, while
+ freely available, is not part of the MySQL Cluster
+ distribution, as well as specialised hardware. See
+ <xref linkend="mysql-cluster-sci-definition"/> for detailed
+ information about SCI interconnects.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ You can define <literal>default</literal> values for each
+ section. As of MySQL 4.1.5, all parameter names are
+ case-insensitive, which differs from parameters specified in
+ <filename>my.cnf</filename> or <filename>my.ini</filename>
+ files.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-connectstring">
+
+ <title>The MySQL Cluster Connectstring</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>connectstring</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>connectstring</primary>
+ <see>MySQL Cluster</see>
+ </indexterm>
+
+ <para>
+ With the exception of the MySQL Cluster management server
+ (<command>ndb_mgmd</command>), each node that is part of a MySQL
+ Cluster requires a <firstterm>connectstring</firstterm> that
+ points to the management server's location. This connectstring
+ is used in establishing a connection to the management server as
+ well as in performing other tasks depending on the node's role
+ in the cluster. The syntax for a connectstring is as follows:
+ </para>
+
+<programlisting>
+[nodeid=<replaceable>node_id</replaceable>, ]<replaceable>host-definition</replaceable>[, <replaceable>host-definition</replaceable>[, ...]]
+
+<replaceable>host-definition</replaceable>:
+ <replaceable>host_name</replaceable>[:<replaceable>port_number</replaceable>]
+</programlisting>
+
+ <para>
+ <literal>node_id</literal> is an integer larger than 1 which
+ identifies a node in <filename>config.ini</filename>.
+ <replaceable>host_name</replaceable> is a string representing a
+ valid Internet host name or IP address.
+ <replaceable>port_number</replaceable> is an integer referring
+ to a TCP/IP port number.
+ </para>
+
+<programlisting>
+example 1 (long): "nodeid=2,myhost1:1100,myhost2:1100,192.168.0.3:1200"
+example 2 (short): "myhost1"
+</programlisting>
+
+ <para>
+ <literal>localhost:1186</literal> is used as the default
+ connectstring value if none is provided. If
+ <replaceable>port_num</replaceable> is omitted from the
+ connectstring, the default port is 1186.
+
+ <note>
+ <para>
+ Prior to MySQL 4.1.8, the default port was 2200.
+ </para>
+ </note>
+
+ Port 1186 should always be available on the network because it
+ has been assigned by IANA for this purpose (see
+ <ulink url="http://www.iana.org/assignments/port-numbers"/> for
+ details).
+ </para>
+
+ <para>
+ By listing multiple host definitions, it is possible to
+ designate several redundant management servers. A MySQL Cluster
+ data or API node attempts to contact successive management
+ servers on each host in the order specified, until a successful
+ connection has been established.
+ </para>
+
+ <para>
+ There are a number of different ways to specify the
+ connectstring:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Each executable has its own command-line option which
+ enables specifying the management server at startup. (See
+ the documentation for the respective executable.)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Beginning with MySQL 4.1.8, it is also possible to set the
+ connectstring for all nodes in the cluster at once by
+ placing it in a <literal>[mysql_cluster]</literal> section
+ in the management server's <filename>my.cnf</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ For backward compatibility, two other options are available,
+ using the same syntax:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Set the <envar>NDB_CONNECTSTRING</envar> environment
+ variable to contain the connectstring.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Write the connectstring for each executable into a text
+ file named <filename>Ndb.cfg</filename> and place this
+ file in the executable's startup directory.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ <para>
+ However, these are now deprecated and should not be used for
+ new installations.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The recommended method for specifying the connectstring is to
+ set it on the command line or in the <filename>my.cnf</filename>
+ file for each executable.
+ </para>
+
+ <para>
+ The maximum length of a connectstring is 1024 characters.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-computer-definition">
+
+ <title>Defining Computers in a MySQL Cluster</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>defining node hosts</secondary>
+ </indexterm>
+
+ <para>
+ The <literal>[computer]</literal> section has no real
+ significance other than serving as a way to avoid the need of
+ defining host names for each node in the system. All parameters
+ mentioned here are required.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para id="ndbparam-computer-id">
+ <literal>Id</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:id-computer"/>
+
+ <para>
+ This is an integer value, used to refer to the host computer
+ elsewhere in the configuration file. This is not the same as
+ the node ID.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para id="ndbparam-computer-hostname">
+ <literal>HostName</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:hostname-computer"/>
+
+ <para>
+ This is the computer's host name or IP address.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
+ <section id="mysql-cluster-mgm-definition">
+
+ <title>Defining a MySQL Cluster Management Server</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>management node</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <para>
+ The <literal>[ndb_mgmd]</literal> section is used to configure
+ the behavior of the management server. <literal>[mgm]</literal>
+ can be used as an alias; the two section names are equivalent.
+ All parameters in the following list are optional and assume
+ their default values if omitted.
+ </para>
+
+ <note>
+ <para>
+ If neither the <literal>ExecuteOnComputer</literal> nor the
+ <literal>HostName</literal> parameter is present, the default
+ value <literal>localhost</literal> will be assumed for both.
+ </para>
+ </note>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>Id</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-id">
+ <literal>Id</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:id-mgm"/>
+
+ <para>
+ Each node in the cluster has a unique identity, which is
+ represented by an integer value in the range 1 to 63
+ inclusive. This ID is used by all internal cluster messages
+ for addressing the node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ExecuteOnComputer</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-executeoncomputer">
+ <literal>ExecuteOnComputer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:executeoncomputer-mgm"/>
+
+ <para>
+ This refers to the <literal>Id</literal> set for one of the
+ computers defined in a <literal>[computer]</literal> section
+ of the <filename>config.ini</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>PortNumber</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-portnumber">
+ <literal>PortNumber</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:portnumber-mgm"/>
+
+ <para>
+ This is the port number on which the management server
+ listens for configuration requests and management commands.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HostName</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-hostname">
+ <literal>HostName</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:hostname-mgm"/>
+
+ <para>
+ Specifying this parameter defines the host name of the
+ computer on which the management node is to reside. To
+ specify a host name other than <literal>localhost</literal>,
+ either this parameter or
+ <literal>ExecuteOnComputer</literal> is required.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogDestination</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-logdestination">
+ <literal>LogDestination</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:logdestination-mgm"/>
+
+ <para>
+ This parameter specifies where to send cluster logging
+ information. There are three options in this regard —
+ <literal>CONSOLE</literal>, <literal>SYSLOG</literal>, and
+ <literal>FILE</literal> — with <literal>FILE</literal>
+ being the default:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>CONSOLE</literal> outputs the log to
+ <literal>stdout</literal>:
+ </para>
+
+<programlisting>
+CONSOLE
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>SYSLOG</literal> sends the log to a
+ <literal>syslog</literal> facility, possible values
+ being one of <literal>auth</literal>,
+ <literal>authpriv</literal>, <literal>cron</literal>,
+ <literal>daemon</literal>, <literal>ftp</literal>,
+ <literal>kern</literal>, <literal>lpr</literal>,
+ <literal>mail</literal>, <literal>news</literal>,
+ <literal>syslog</literal>, <literal>user</literal>,
+ <literal>uucp</literal>, <literal>local0</literal>,
+ <literal>local1</literal>, <literal>local2</literal>,
+ <literal>local3</literal>, <literal>local4</literal>,
+ <literal>local5</literal>, <literal>local6</literal>, or
+ <literal>local7</literal>.
+ </para>
+
+ <note>
+ <para>
+ Not every facility is necessarily supported by every
+ operating system.
+ </para>
+ </note>
+
+<programlisting>
+SYSLOG:facility=syslog
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>FILE</literal> pipes the cluster log output to
+ a regular file on the same machine. The following values
+ can be specified:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>filename</literal>: The name of the log
+ file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>maxsize</literal>: The maximum size (in
+ bytes) to which the file can grow before logging
+ rolls over to a new file. When this occurs, the old
+ log file is renamed by appending
+ <replaceable>.N</replaceable> to the file name,
+ where <replaceable>N</replaceable> is the next
+ number not yet used with this name.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>maxfiles</literal>: The maximum number of
+ log files.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+<programlisting>
+FILE:filename=cluster.log,maxsize=1000000,maxfiles=6
+</programlisting>
+
+ <para>
+ The default value for the <literal>FILE</literal>
+ parameter is
+ <literal>FILE:filename=ndb_<replaceable>node_id</replaceable>_cluster.log,maxsize=1000000,maxfiles=6</literal>,
+ where <replaceable>node_id</replaceable> is the ID of
+ the node.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ It is possible to specify multiple log destinations
+ separated by semicolons as shown here:
+ </para>
+
+<programlisting>
+CONSOLE;SYSLOG:facility=local0;FILE:filename=/var/log/mgmd
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationRank</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-arbitrationrank">
+ <literal>ArbitrationRank</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:arbitrationrank-mgm"/>
+
+ <para>
+ This parameter is used to define which nodes can act as
+ arbitrators. Only management nodes and SQL nodes can be
+ arbitrators. <literal>ArbitrationRank</literal> can take one
+ of the following values:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>0</literal>: The node will never be used as an
+ arbitrator.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>1</literal>: The node has high priority; that
+ is, it will be preferred as an arbitrator over
+ low-priority nodes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>2</literal>: Indicates a low-priority node
+ which be used as an arbitrator only if a node with a
+ higher priority is not available for that purpose.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ Normally, the management server should be configured as an
+ arbitrator by setting its <literal>ArbitrationRank</literal>
+ to 1 (the default value) and that of all SQL nodes to 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationDelay</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-arbitrationdelay">
+ <literal>ArbitrationDelay</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:arbitrationdelay-mgm"/>
+
+ <para>
+ An integer value which causes the management server's
+ responses to arbitration requests to be delayed by that
+ number of milliseconds. By default, this value is 0; it is
+ normally not necessary to change it.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>DataDir</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-datadir">
+ <literal>DataDir</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:datadir-mgm"/>
+
+ <para>
+ This specifies the directory where output files from the
+ management server will be placed. These files include
+ cluster log files, process output files, and the daemon's
+ process ID (PID) file. (For log files, this location can be
+ overridden by setting the <literal>FILE</literal> parameter
+ for <literal>LogDestination</literal> as discussed
+ previously in this section.)
+ </para>
+
+ <para>
+ The default value for this parameter is the directory in
+ which <command>ndb_mgmd</command> is located.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <note>
+ <para>
+ After making changes in a management node's
+ configuration, it is necessary to perform a rolling restart of
+ the cluster in order for the new configuration to take effect.
+ </para>
+
+ <para>
+ To add new management servers to a running MySQL Cluster, it
+ is also necessary to perform a rolling restart of all cluster
+ nodes after modifying any existing
+ <filename>config.ini</filename> files. For more information
+ about issues arising when using multiple management nodes, see
+ <xref linkend="mysql-cluster-limitations-multiple-nodes"/>.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-ndbd-definition">
+
+ <title>Defining MySQL Cluster Data Nodes</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>data node</secondary>
+ </indexterm>
+
+ <para>
+ The <literal>[ndbd]</literal> and <literal>[ndbd
+ default]</literal> sections are used to configure the behavior
+ of the cluster's data nodes.
+ </para>
+
+ <para>
+ There are many parameters which control buffer sizes, pool
+ sizes, timeouts, and so forth. The only mandatory parameters
+ are:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Either <literal>ExecuteOnComputer</literal> or
+ <literal>HostName</literal>, which must be defined in the
+ local <literal>[ndbd]</literal> section.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The parameter <literal>NoOfReplicas</literal>, which must be
+ defined in the<literal>[ndbd default]</literal>section, as
+ it is common to all Cluster data nodes.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ Most data node parameters are set in the <literal>[ndbd
+ default]</literal> section. Only those parameters explicitly
+ stated as being able to set local values are allowed to be
+ changed in the <literal>[ndbd]</literal> section. Where present,
+ <literal>HostName</literal>, <literal>Id</literal> and
+ <literal>ExecuteOnComputer</literal> <emphasis>must</emphasis>
+ be defined in the local <literal>[ndbd]</literal> section, and
+ not in any other section of <filename>config.ini</filename>. In
+ other words, settings for these parameters are specific to one
+ data node.
+ </para>
+
+ <para>
+ For those parameters affecting memory usage or buffer sizes, it
+ is possible to use <literal>K</literal>, <literal>M</literal>,
+ or <literal>G</literal> as a suffix to indicate units of 1024,
+ 1024×1024, or 1024×1024×1024. (For example,
+ <literal>100K</literal> means 100 × 1024 = 102400.)
+ Parameter names and values are currently case-sensitive.
+ </para>
+
+ <formalpara>
+
+ <title>Identifying data nodes</title>
+
+ <para id="mysql-cluster-identifying-data-nodes">
+ The <literal>Id</literal> value (that is, the data node
+ identifier) can be allocated on the command line when the node
+ is started or in the configuration file.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>Id</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-id">
+ <literal>Id</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:id-ndbd"/>
+
+ <para>
+ This is the node ID used as the address of the node for all
+ cluster internal messages. For data nodes, this is an
+ integer in the range 1 to 49 inclusive. Each node in the
+ cluster must have a unique identity.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ExecuteOnComputer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-executeoncomputer">
+ <literal>ExecuteOnComputer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:executeoncomputer-ndbd"/>
+
+ <para>
+ This refers to the <literal>Id</literal> set for one of the
+ computers defined in a <literal>[computer]</literal>
+ section.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HostName</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-hostname">
+ <literal>HostName</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:hostname-ndbd"/>
+
+ <para>
+ Specifying this parameter defines the host name of the
+ computer on which the data node is to reside. To specify a
+ host name other than <literal>localhost</literal>, either
+ this parameter or <literal>ExecuteOnComputer</literal> is
+ required.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ServerPort</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-serverport">
+ <literal>ServerPort</literal>
+ (<emphasis>OBSOLETE</emphasis>)
+ </para>
+
+ <para>
+ Each node in the cluster uses a port to connect to other
+ nodes. This port is used also for non-TCP transporters in
+ the connection setup phase. The default port is allocated
+ dynamically in such a way as to ensure that no two nodes on
+ the same computer receive the same port number, so it should
+ not normally be necessary to specify a value for this
+ parameter.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfReplicas</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofreplicas">
+ <literal>NoOfReplicas</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:noofreplicas-ndbd"/>
+
+ <para>
+ This global parameter can be set only in the <literal>[ndbd
+ default]</literal> section, and defines the number of
+ replicas for each table stored in the cluster. This
+ parameter also specifies the size of node groups. A node
+ group is a set of nodes all storing the same information.
+ </para>
+
+ <para>
+ Node groups are formed implicitly. The first node group is
+ formed by the set of data nodes with the lowest node IDs,
+ the next node group by the set of the next lowest node
+ identities, and so on. By way of example, assume that we
+ have 4 data nodes and that <literal>NoOfReplicas</literal>
+ is set to 2. The four data nodes have node IDs 2, 3, 4 and
+ 5. Then the first node group is formed from nodes 2 and 3,
+ and the second node group by nodes 4 and 5. It is important
+ to configure the cluster in such a manner that nodes in the
+ same node groups are not placed on the same computer because
+ a single hardware failure would cause the entire cluster to
+ fail.
+ </para>
+
+ <para>
+ If no node IDs are provided, the order of the data nodes
+ will be the determining factor for the node group. Whether
+ or not explicit assignments are made, they can be viewed in
+ the output of the management client's
+ <literal role="ndb_mgm_cmd">SHOW</literal> command.
+ </para>
+
+ <para>
+ There is no default value for
+ <literal>NoOfReplicas</literal>; the maximum possible value
+ is 4. Currently, only the values 1 and 2 are actually
+ supported (see Bug#18621).
+ </para>
+
+ <important>
+ <para>
+ Setting <literal>NoOfReplicas</literal> to 1 means that
+ there is only a single copy of all Cluster data; in this
+ case, the loss of a single data node causes the cluster to
+ fail because there are no additional copies of the data
+ stored by that node.
+ </para>
+ </important>
+
+ <para>
+ The value for this parameter must divide evenly into the
+ number of data nodes in the cluster. For example, if there
+ are two data nodes, then <literal>NoOfReplicas</literal>
+ must be equal to either 1 or 2, since 2/3 and 2/4 both yield
+ fractional values; if there are four data nodes, then
+ <literal>NoOfReplicas</literal> must be equal to 1, 2, or 4.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>DataDir</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-datadir">
+ <literal>DataDir</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:datadir-ndbd"/>
+
+ <para>
+ This parameter specifies the directory where trace files,
+ log files, pid files and error logs are placed.
+ </para>
+
+ <para>
+ The default is the data node process working directory.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>FileSystemPath</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-filesystempath">
+ <literal>FileSystemPath</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:filesystempath-ndbd"/>
+
+ <para>
+ This parameter specifies the directory where all files
+ created for metadata, REDO logs, UNDO logs and data files
+ are placed. The default is the directory specified by
+ <literal>DataDir</literal>.
+ </para>
+
+ <note>
+ <para>
+ This directory must exist before the
+ <command>ndbd</command> process is initiated.
+ </para>
+ </note>
+
+ <para>
+ The recommended directory hierarchy for MySQL Cluster
+ includes <filename>/var/lib/mysql-cluster</filename>, under
+ which a directory for the node's file system is created. The
+ name of this subdirectory contains the node ID. For example,
+ if the node ID is 2, this subdirectory is named
+ <filename>ndb_2_fs</filename>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupDataDir</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupdatadir">
+ <literal>BackupDataDir</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:backupdatadir-ndbd"/>
+
+ <para>
+ This parameter specifies the directory in which backups are
+ placed. If omitted, the default backup location is the
+ directory named <filename>BACKUP</filename> under the
+ location specified by the <literal>FileSystemPath</literal>
+ parameter. (See above.)
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para id="mysql-cluster-data-memory-index-memory-string-memory">
+ <emphasis role="bold">Data Memory, Index Memory, and String
+ Memory</emphasis>
+ </para>
+
+ <para>
+ <literal>DataMemory</literal> and <literal>IndexMemory</literal>
+ are <literal>[ndbd]</literal> parameters specifying the size of
+ memory segments used to store the actual records and their
+ indexes. In setting values for these, it is important to
+ understand how <literal>DataMemory</literal> and
+ <literal>IndexMemory</literal> are used, as they usually need to
+ be updated to reflect actual usage by the cluster:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>DataMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-datamemory">
+ <literal>DataMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:datamemory-ndbd"/>
+
+ <para>
+ This parameter defines the amount of space (in bytes)
+ available for storing database records. The entire amount
+ specified by this value is allocated in memory, so it is
+ extremely important that the machine has sufficient physical
+ memory to accommodate it.
+ </para>
+
+ <para>
+ The memory allocated by <literal>DataMemory</literal> is
+ used to store both the actual records and indexes. Each
+ record is currently of fixed size. (Even
+ <literal role="type">VARCHAR</literal> columns are stored as
+ fixed-width columns.) There is a 16-byte overhead on each
+ record; an additional amount for each record is incurred
+ because it is stored in a 32KB page with 128 byte page
+ overhead (see below). There is also a small amount wasted
+ per page due to the fact that each record is stored in only
+ one page.
+ </para>
+
+ <para>
+ The maximum record size is currently 8052 bytes.
+ </para>
+
+ <para>
+ The memory space defined by <literal>DataMemory</literal> is
+ also used to store ordered indexes, which use about 10 bytes
+ per record. Each table row is represented in the ordered
+ index. A common error among users is to assume that all
+ indexes are stored in the memory allocated by
+ <literal>IndexMemory</literal>, but this is not the case:
+ Only primary key and unique hash indexes use this memory;
+ ordered indexes use the memory allocated by
+ <literal>DataMemory</literal>. However, creating a primary
+ key or unique hash index also creates an ordered index on
+ the same keys, unless you specify <literal>USING
+ HASH</literal> in the index creation statement. This can be
+ verified by running <command>ndb_desc -d
+ <replaceable>db_name</replaceable>
+ <replaceable>table_name</replaceable></command> in the
+ management client.
+ </para>
+
+ <para>
+ The memory space allocated by <literal>DataMemory</literal>
+ consists of 32KB pages, which are allocated to table
+ fragments. Each table is normally partitioned into the same
+ number of fragments as there are data nodes in the cluster.
+ Thus, for each node, there are the same number of fragments
+ as are set in <literal>NoOfReplicas</literal>.
+ </para>
+
+ <para>
+ In addition, due to the way in which new pages are allocated
+ when the capacity of the current page is exhausted, there is
+ an additional overhead of approximately 18.75%. When more
+ <literal>DataMemory</literal> is required, more than one new
+ page is allocated, according to the following formula:
+
+<programlisting>
+number of new pages = FLOOR(number of current pages × 0.1875) + 1
+</programlisting>
+
+ For example, if 15 pages are currently allocated to a given
+ table and an insert to this table requires additional
+ storage space, the number of new pages allocated to the
+ table is <literal>FLOOR(15 × 0.1875) + 1 =
+ FLOOR(2.8125) + 1 = 2 + 1 =
+ 3</literal>. Now 15 + 3 = 18 memory pages are
+ allocated to the table. When the last of these 18 pages
+ becomes full, <literal>FLOOR(18 × 0.1875) + 1
+ = FLOOR(3.3750) + 1 = 3 + 1 =
+ 4</literal> new pages are allocated, so the total number of
+ pages allocated to the table is now 22.
+ </para>
+
+ <para>
+ Once a page has been allocated, it is currently not possible
+ to return it to the pool of free pages, except by deleting
+ the table. (This also means that
+ <literal>DataMemory</literal> pages, once allocated to a
+ given table, cannot be used by other tables.) Performing a
+ node recovery also compresses the partition because all
+ records are inserted into empty partitions from other live
+ nodes.
+ </para>
+
+ <para>
+ The <literal>DataMemory</literal> memory space also contains
+ UNDO information: For each update, a copy of the unaltered
+ record is allocated in the <literal>DataMemory</literal>.
+ There is also a reference to each copy in the ordered table
+ indexes. Unique hash indexes are updated only when the
+ unique index columns are updated, in which case a new entry
+ in the index table is inserted and the old entry is deleted
+ upon commit. For this reason, it is also necessary to
+ allocate enough memory to handle the largest transactions
+ performed by applications using the cluster. In any case,
+ performing a few large transactions holds no advantage over
+ using many smaller ones, for the following reasons:
+ </para>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>transactions</secondary>
+ </indexterm>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Large transactions are not any faster than smaller ones
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Large transactions increase the number of operations
+ that are lost and must be repeated in event of
+ transaction failure
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Large transactions use more memory
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The default value for <literal>DataMemory</literal> is 80MB;
+ the minimum is 1MB. There is no maximum size, but in reality
+ the maximum size has to be adapted so that the process does
+ not start swapping when the limit is reached. This limit is
+ determined by the amount of physical RAM available on the
+ machine and by the amount of memory that the operating
+ system may commit to any one process. 32-bit operating
+ systems are generally limited to 2−4GB per process;
+ 64-bit operating systems can use more. For large databases,
+ it may be preferable to use a 64-bit operating system for
+ this reason.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>IndexMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-indexmemory">
+ <literal>IndexMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:indexmemory-ndbd"/>
+
+ <para>
+ This parameter controls the amount of storage used for hash
+ indexes in MySQL Cluster. Hash indexes are always used for
+ primary key indexes, unique indexes, and unique constraints.
+ Note that when defining a primary key and a unique index,
+ two indexes will be created, one of which is a hash index
+ used for all tuple accesses as well as lock handling. It is
+ also used to enforce unique constraints.
+ </para>
+
+ <para>
+ The size of the hash index is 25 bytes per record, plus the
+ size of the primary key. For primary keys larger than 32
+ bytes another 8 bytes is added.
+ </para>
+
+ <para>
+ The default value for <literal>IndexMemory</literal> is
+ 18MB. The minimum is 1MB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StringMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-stringmemory">
+ <literal>StringMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:stringmemory-ndbd"/>
+
+ <para>
+ This parameter determines how much memory is allocated for
+ strings such as table names, and is specified in an
+ <literal>[ndbd]</literal> or <literal>[ndbd
+ default]</literal> section of the
+ <filename>config.ini</filename> file. A value between
+ <literal>0</literal> and <literal>100</literal> inclusive is
+ interpreted as a percent of the maximum default value, which
+ is calculated based on a number of factors including the
+ number of tables, maximum table name size, maximum size of
+ <filename>.FRM</filename> files,
+ <literal>MaxNoOfTriggers</literal>, maximum column name
+ size, and maximum default column value. In general it is
+ safe to assume that the maximum default value is
+ approximately 5 MB for a MySQL Cluster having 1000 tables.
+ </para>
+
+ <para>
+ A value greater than <literal>100</literal> is interpreted
+ as a number of bytes.
+ </para>
+
+ <para>
+ In MySQL ¤t-series;, the default value is
+ <literal>100</literal> — that is, 100 percent of the
+ default maximum, or roughly 5 MB. It is possible to reduce
+ this value safely, but it should never be less than 5
+ percent. If you encounter Error 773 <errortext>Out of string
+ memory, please modify StringMemory config parameter:
+ Permanent error: Schema error</errortext>, this means that
+ means that you have set the <literal>StringMemory</literal>
+ value too low. <literal>25</literal> (25 percent) is not
+ excessive, and should prevent this error from recurring in
+ all but the most extreme conditions, as when there are
+ hundreds or thousands of <literal role="se">NDB</literal>
+ tables with names whose lengths and columns whose number
+ approach their permitted maximums.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The following example illustrates how memory is used for a
+ table. Consider this table definition:
+ </para>
+
+<programlisting>
+CREATE TABLE example (
+ a INT NOT NULL,
+ b INT NOT NULL,
+ c INT NOT NULL,
+ PRIMARY KEY(a),
+ UNIQUE(b)
+) ENGINE=NDBCLUSTER;
+</programlisting>
+
+ <para>
+ For each record, there are 12 bytes of data plus 12 bytes
+ overhead. Having no nullable columns saves 4 bytes of overhead.
+ In addition, we have two ordered indexes on columns
+ <literal>a</literal> and <literal>b</literal> consuming roughly
+ 10 bytes each per record. There is a primary key hash index on
+ the base table using roughly 29 bytes per record. The unique
+ constraint is implemented by a separate table with
+ <literal>b</literal> as primary key and <literal>a</literal> as
+ a column. This other table consumes an additional 29 bytes of
+ index memory per record in the <literal>example</literal> table
+ as well 8 bytes of record data plus 12 bytes of overhead.
+ </para>
+
+ <para>
+ Thus, for one million records, we need 58MB for index memory to
+ handle the hash indexes for the primary key and the unique
+ constraint. We also need 64MB for the records of the base table
+ and the unique index table, plus the two ordered index tables.
+ </para>
+
+ <para>
+ You can see that hash indexes takes up a fair amount of memory
+ space; however, they provide very fast access to the data in
+ return. They are also used in MySQL Cluster to handle uniqueness
+ constraints.
+ </para>
+
+ <para>
+ Currently, the only partitioning algorithm is hashing and
+ ordered indexes are local to each node. Thus, ordered indexes
+ cannot be used to handle uniqueness constraints in the general
+ case.
+ </para>
+
+ <para>
+ An important point for both <literal>IndexMemory</literal> and
+ <literal>DataMemory</literal> is that the total database size is
+ the sum of all data memory and all index memory for each node
+ group. Each node group is used to store replicated information,
+ so if there are four nodes with two replicas, there will be two
+ node groups. Thus, the total data memory available is 2 ×
+ <literal>DataMemory</literal> for each data node.
+ </para>
+
+ <para>
+ It is highly recommended that <literal>DataMemory</literal> and
+ <literal>IndexMemory</literal> be set to the same values for all
+ nodes. Data distribution is even over all nodes in the cluster,
+ so the maximum amount of space available for any node can be no
+ greater than that of the smallest node in the cluster.
+ </para>
+
+ <para>
+ <literal>DataMemory</literal> and <literal>IndexMemory</literal>
+ can be changed, but decreasing either of these can be risky;
+ doing so can easily lead to a node or even an entire MySQL
+ Cluster that is unable to restart due to there being
+ insufficient memory space. Increasing these values should be
+ acceptable, but it is recommended that such upgrades are
+ performed in the same manner as a software upgrade, beginning
+ with an update of the configuration file, and then restarting
+ the management server followed by restarting each data node in
+ turn.
+ </para>
+
+ <para>
+ Updates do not increase the amount of index memory used. Inserts
+ take effect immediately; however, rows are not actually deleted
+ until the transaction is committed.
+ </para>
+
+ <formalpara>
+
+ <title>Transaction parameters</title>
+
+ <para id="mysql-cluster-transaction-parameters">
+ The next three <literal>[ndbd]</literal> parameters that we
+ discuss are important because they affect the number of
+ parallel transactions and the sizes of transactions that can
+ be handled by the system.
+ <literal>MaxNoOfConcurrentTransactions</literal> sets the
+ number of parallel transactions possible in a node.
+ <literal>MaxNoOfConcurrentOperations</literal> sets the number
+ of records that can be in update phase or locked
+ simultaneously.
+ </para>
+
+ </formalpara>
+
+ <para>
+ Both of these parameters (especially
+ <literal>MaxNoOfConcurrentOperations</literal>) are likely
+ targets for users setting specific values and not using the
+ default value. The default value is set for systems using small
+ transactions, to ensure that these do not use excessive memory.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfConcurrentTransactions</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofconcurrenttransactions">
+ <literal>MaxNoOfConcurrentTransactions</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnoofconcurrenttransactions-ndbd"/>
+
+ <para>
+ Each cluster data node requires a transaction record for
+ each active transaction in the cluster. The task of
+ coordinating transactions is distributed among all of the
+ data nodes. The total number of transaction records in the
+ cluster is the number of transactions in any given node
+ times the number of nodes in the cluster.
+ </para>
+
+ <para>
+ Transaction records are allocated to individual MySQL
+ servers. Each connection to a MySQL server requires at least
+ one transaction record, plus an additional transaction
+ object per table accessed by that connection. This means
+ that a reasonable minimum for this parameter is
+
+<programlisting>
+MaxNoOfConcurrentTransactions =
+ (maximum number of tables accessed in any single transaction + 1)
+ * number of cluster SQL nodes
+</programlisting>
+
+ For example, suppose that there are 4 SQL nodes using the
+ cluster. A single join involving 5 tables requires 6
+ transaction records; if there are 5 such joins in a
+ transaction, then 5 * 6 = 30 transaction records are
+ required for this transaction, per MySQL server, or 30 * 4 =
+ 120 transaction records total.
+ </para>
+
+ <para>
+ This parameter must be set to the same value for all cluster
+ data nodes. This is due to the fact that, when a data node
+ fails, the oldest surviving node re-creates the transaction
+ state of all transactions that were ongoing in the failed
+ node.
+ </para>
+
+ <para>
+ Changing the value of
+ <literal>MaxNoOfConcurrentTransactions</literal> requires a
+ complete shutdown and restart of the cluster.
+ </para>
+
+ <para>
+ The default value is 4096.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfConcurrentOperations</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofconcurrentoperations">
+ <literal>MaxNoOfConcurrentOperations</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnoofconcurrentoperations-ndbd"/>
+
+ <para>
+ It is a good idea to adjust the value of this parameter
+ according to the size and number of transactions. When
+ performing transactions of only a few operations each and
+ not involving a great many records, there is no need to set
+ this parameter very high. When performing large transactions
+ involving many records need to set this parameter higher.
+ </para>
+
+ <para>
+ Records are kept for each transaction updating cluster data,
+ both in the transaction coordinator and in the nodes where
+ the actual updates are performed. These records contain
+ state information needed to find UNDO records for rollback,
+ lock queues, and other purposes.
+ </para>
+
+ <para>
+ This parameter should be set to the number of records to be
+ updated simultaneously in transactions, divided by the
+ number of cluster data nodes. For example, in a cluster
+ which has four data nodes and which is expected to handle
+ 1,000,000 concurrent updates using transactions, you should
+ set this value to 1000000 / 4 = 250000.
+ </para>
+
+ <para>
+ Read queries which set locks also cause operation records to
+ be created. Some extra space is allocated within individual
+ nodes to accommodate cases where the distribution is not
+ perfect over the nodes.
+ </para>
+
+ <para>
+ When queries make use of the unique hash index, there are
+ actually two operation records used per record in the
+ transaction. The first record represents the read in the
+ index table and the second handles the operation on the base
+ table.
+ </para>
+
+ <para>
+ The default value is 32768.
+ </para>
+
+ <para>
+ This parameter actually handles two values that can be
+ configured separately. The first of these specifies how many
+ operation records are to be placed with the transaction
+ coordinator. The second part specifies how many operation
+ records are to be local to the database.
+ </para>
+
+ <para>
+ A very large transaction performed on an eight-node cluster
+ requires as many operation records in the transaction
+ coordinator as there are reads, updates, and deletes
+ involved in the transaction. However, the operation records
+ of the are spread over all eight nodes. Thus, if it is
+ necessary to configure the system for one very large
+ transaction, it is a good idea to configure the two parts
+ separately. <literal>MaxNoOfConcurrentOperations</literal>
+ will always be used to calculate the number of operation
+ records in the transaction coordinator portion of the node.
+ </para>
+
+ <para>
+ It is also important to have an idea of the memory
+ requirements for operation records. These consume about 1KB
+ per record.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfLocalOperations</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooflocaloperations">
+ <literal>MaxNoOfLocalOperations</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnooflocaloperations-ndbd"/>
+
+ <para>
+ By default, this parameter is calculated as 1.1 ×
+ <literal>MaxNoOfConcurrentOperations</literal>. This fits
+ systems with many simultaneous transactions, none of them
+ being very large. If there is a need to handle one very
+ large transaction at a time and there are many nodes, it is
+ a good idea to override the default value by explicitly
+ specifying this parameter.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Transaction temporary storage</title>
+
+ <para id="mysql-cluster-transaction-temporary-storage">
+ The next set of <literal>[ndbd]</literal> parameters is used
+ to determine temporary storage when executing a statement that
+ is part of a Cluster transaction. All records are released
+ when the statement is completed and the cluster is waiting for
+ the commit or rollback.
+ </para>
+
+ </formalpara>
+
+ <para>
+ The default values for these parameters are adequate for most
+ situations. However, users with a need to support transactions
+ involving large numbers of rows or operations may need to
+ increase these values to enable better parallelism in the
+ system, whereas users whose applications require relatively
+ small transactions can decrease the values to save memory.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfConcurrentIndexOperations</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofconcurrentindexoperations">
+ <literal>MaxNoOfConcurrentIndexOperations</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnoofconcurrentindexoperations-ndbd"/>
+
+ <para>
+ For queries using a unique hash index, another temporary set
+ of operation records is used during a query's execution
+ phase. This parameter sets the size of that pool of records.
+ Thus, this record is allocated only while executing a part
+ of a query. As soon as this part has been executed, the
+ record is released. The state needed to handle aborts and
+ commits is handled by the normal operation records, where
+ the pool size is set by the parameter
+ <literal>MaxNoOfConcurrentOperations</literal>.
+ </para>
+
+ <para>
+ The default value of this parameter is 8192. Only in rare
+ cases of extremely high parallelism using unique hash
+ indexes should it be necessary to increase this value. Using
+ a smaller value is possible and can save memory if the DBA
+ is certain that a high degree of parallelism is not required
+ for the cluster.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfFiredTriggers</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooffiredtriggers">
+ <literal>MaxNoOfFiredTriggers</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnooffiredtriggers-ndbd"/>
+
+ <para>
+ The default value of <literal>MaxNoOfFiredTriggers</literal>
+ is 4000, which is sufficient for most situations. In some
+ cases it can even be decreased if the DBA feels certain the
+ need for parallelism in the cluster is not high.
+ </para>
+
+ <para>
+ A record is created when an operation is performed that
+ affects a unique hash index. Inserting or deleting a record
+ in a table with unique hash indexes or updating a column
+ that is part of a unique hash index fires an insert or a
+ delete in the index table. The resulting record is used to
+ represent this index table operation while waiting for the
+ original operation that fired it to complete. This operation
+ is short-lived but can still require a large number of
+ records in its pool for situations with many parallel write
+ operations on a base table containing a set of unique hash
+ indexes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TransactionBufferMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-transactionbuffermemory">
+ <literal>TransactionBufferMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:transactionbuffermemory-ndbd"/>
+
+ <para>
+ The memory affected by this parameter is used for tracking
+ operations fired when updating index tables and reading
+ unique indexes. This memory is used to store the key and
+ column information for these operations. It is only very
+ rarely that the value for this parameter needs to be altered
+ from the default.
+ </para>
+
+ <para>
+ The default value for
+ <literal>TransactionBufferMemory</literal> is 1MB.
+ </para>
+
+ <para>
+ Normal read and write operations use a similar buffer, whose
+ usage is even more short-lived. The compile-time parameter
+ <literal>ZATTRBUF_FILESIZE</literal> (found in
+ <filename>ndb/src/kernel/blocks/Dbtc/Dbtc.hpp</filename>)
+ set to 4000 × 128 bytes (500KB). A similar buffer for
+ key information, <literal>ZDATABUF_FILESIZE</literal> (also
+ in <filename>Dbtc.hpp</filename>) contains 4000 × 16 =
+ 62.5KB of buffer space. <literal>Dbtc</literal> is the
+ module that handles transaction coordination.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Scans and buffering</title>
+
+ <para id="mysql-cluster-scans-and-buffering">
+ There are additional <literal>[ndbd]</literal> parameters in
+ the <literal>Dblqh</literal> module (in
+ <filename>ndb/src/kernel/blocks/Dblqh/Dblqh.hpp</filename>)
+ that affect reads and updates. These include
+ <literal>ZATTRINBUF_FILESIZE</literal>, set by default to
+ 10000 × 128 bytes (1250KB) and
+ <literal>ZDATABUF_FILE_SIZE</literal>, set by default to
+ 10000*16 bytes (roughly 156KB) of buffer space. To date, there
+ have been neither any reports from users nor any results from
+ our own extensive tests suggesting that either of these
+ compile-time limits should be increased.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfConcurrentScans</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofconcurrentscans">
+ <literal>MaxNoOfConcurrentScans</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnoofconcurrentscans-ndbd"/>
+
+ <para>
+ This parameter is used to control the number of parallel
+ scans that can be performed in the cluster. Each transaction
+ coordinator can handle the number of parallel scans defined
+ for this parameter. Each scan query is performed by scanning
+ all partitions in parallel. Each partition scan uses a scan
+ record in the node where the partition is located, the
+ number of records being the value of this parameter times
+ the number of nodes. The cluster should be able to sustain
+ <literal>MaxNoOfConcurrentScans</literal> scans concurrently
+ from all nodes in the cluster.
+ </para>
+
+ <para>
+ Scans are actually performed in two cases. The first of
+ these cases occurs when no hash or ordered indexes exists to
+ handle the query, in which case the query is executed by
+ performing a full table scan. The second case is encountered
+ when there is no hash index to support the query but there
+ is an ordered index. Using the ordered index means executing
+ a parallel range scan. The order is kept on the local
+ partitions only, so it is necessary to perform the index
+ scan on all partitions.
+ </para>
+
+ <para>
+ The default value of
+ <literal>MaxNoOfConcurrentScans</literal> is 256. The
+ maximum value is 500.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfLocalScans</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooflocalscans">
+ <literal>MaxNoOfLocalScans</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnooflocalscans-ndbd"/>
+
+ <para>
+ Specifies the number of local scan records if many scans are
+ not fully parallelized. If the number of local scan records
+ is not provided, it is calculated as the product of
+ <literal>MaxNoOfConcurrentScans</literal> and the number of
+ data nodes in the system. The minimum value is 32.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BatchSizePerLocalScan</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-batchsizeperlocalscan">
+ <literal>BatchSizePerLocalScan</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:batchsizeperlocalscan-ndbd"/>
+
+ <para>
+ This parameter is used to calculate the number of lock
+ records used to handle concurrent scan operations.
+ </para>
+
+ <para>
+ The default value is 64; this value has a strong connection
+ to the <literal>ScanBatchSize</literal> defined in the SQL
+ nodes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LongMessageBuffer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-longmessagebuffer">
+ <literal>LongMessageBuffer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:longmessagebuffer-ndbd"/>
+
+ <para>
+ This is an internal buffer used for passing messages within
+ individual nodes and between nodes. Although it is highly
+ unlikely that this would need to be changed, it is
+ configurable. By default, it is set to 1MB.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para id="mysql-cluster-logging-and-checkpointing">
+ <emphasis role="bold">Logging and checkpointing</emphasis>
+ </para>
+
+ <para>
+ The following <literal>[ndbd]</literal> parameters control log
+ and checkpoint behavior.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfFragmentLogFiles</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-nooffragmentlogfiles">
+ <literal>NoOfFragmentLogFiles</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:nooffragmentlogfiles-ndbd"/>
+
+ <para>
+ This parameter sets the number of REDO log files for the
+ node, and thus the amount of space allocated to REDO
+ logging. Because the REDO log files are organized in a ring,
+ it is extremely important that the first and last log files
+ in the set (sometimes referred to as the <quote>head</quote>
+ and <quote>tail</quote> log files, respectively) do not
+ meet. When these approach one another too closely, the node
+ begins aborting all transactions encompassing updates due to
+ a lack of room for new log records.
+ </para>
+
+ <para>
+ A <literal>REDO</literal> log record is not removed until
+ three local checkpoints have been completed since that log
+ record was inserted. Checkpointing frequency is determined
+ by its own set of configuration parameters discussed
+ elsewhere in this chapter.
+ </para>
+
+ <para>
+ How these parameters interact and proposals for how to
+ configure them are discussed in
+ <xref linkend="mysql-cluster-config-lcp-params"/>.
+ </para>
+
+ <para>
+ The default parameter value is 8, which means 8 sets of 4
+ 16MB files for a total of 512MB. In other words, REDO log
+ space is always allocated in blocks of 64MB. In scenarios
+ requiring a great many updates, the value for
+ <literal>NoOfFragmentLogFiles</literal> may need to be set
+ as high as 300 or even higher to provide sufficient space
+ for REDO logs.
+ </para>
+
+ <para>
+ If the checkpointing is slow and there are so many writes to
+ the database that the log files are full and the log tail
+ cannot be cut without jeopardizing recovery, all updating
+ transactions are aborted with internal error code 410
+ (<literal>Out of log file space temporarily</literal>). This
+ condition prevails until a checkpoint has completed and the
+ log tail can be moved forward.
+ </para>
+
+ <important>
+ <para>
+ This parameter cannot be changed <quote>on the
+ fly</quote>; you must restart the node using
+ <option>--initial</option>. If you wish to change this
+ value for all data nodes in a running cluster, you can do
+ so via a rolling node restart (using
+ <option>--initial</option> when starting each data node).
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfOpenFiles</primary>
+ </indexterm>
+
+ <remark role="todo">
+ If this doesn't ever need to be changed, then why is it even
+ mentioned? [js]
+ </remark>
+
+ <para id="ndbparam-ndbd-maxnoofopenfiles">
+ <literal>MaxNoOfOpenFiles</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnoofopenfiles-ndbd"/>
+
+ <para>
+ This parameter sets a ceiling on how many internal threads
+ to allocate for open files. <emphasis>Any situation
+ requiring a change in this parameter should be reported as a
+ bug</emphasis>.
+ </para>
+
+ <para>
+ The default value is 40.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfSavedMessages</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofsavedmessages">
+ <literal>MaxNoOfSavedMessages</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnoofsavedmessages-ndbd"/>
+
+ <para>
+ This parameter sets the maximum number of trace files that
+ are kept before overwriting old ones. Trace files are
+ generated when, for whatever reason, the node crashes.
+ </para>
+
+ <para>
+ The default is 25 trace files.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Metadata objects</title>
+
+ <para id="mysql-cluster-metadata-objects">
+ The next set of <literal>[ndbd]</literal> parameters defines
+ pool sizes for metadata objects, used to define the maximum
+ number of attributes, tables, indexes, and trigger objects
+ used by indexes, events, and replication between clusters.
+ Note that these act merely as <quote>suggestions</quote> to
+ the cluster, and any that are not specified revert to the
+ default values shown.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfAttributes</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofattributes">
+ <literal>MaxNoOfAttributes</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnoofattributes-ndbd"/>
+
+ <para>
+ Defines the number of attributes that can be defined in the
+ cluster.
+ </para>
+
+ <para>
+ The default value is 1000, with the minimum possible value
+ being 32. The maximum is 4294967039. Each attribute consumes
+ around 200 bytes of storage per node due to the fact that
+ all metadata is fully replicated on the servers.
+ </para>
+
+ <para>
+ When setting <literal>MaxNoOfAttributes</literal>, it is
+ important to prepare in advance for any
+ <literal role="stmt">ALTER TABLE</literal> statements that
+ you might want to perform in the future. This is due to the
+ fact, during the execution of <literal role="stmt">ALTER
+ TABLE</literal> on a Cluster table, 3 times the number of
+ attributes as in the original table are used, and a good
+ practice is to allow double this amount. For example, if the
+ MySQL Cluster table having the greatest number of attributes
+ (<replaceable>greatest_number_of_attributes</replaceable>)
+ has 100 attributes, a good starting point for the value of
+ <literal>MaxNoOfAttributes</literal> would be <literal>6 *
+ <replaceable>greatest_number_of_attributes</replaceable> =
+ 600</literal>.
+ </para>
+
+ <para>
+ You should also estimate the average number of attributes
+ per table and multiply this by the total number of MySQL
+ Cluster tables. If this value is larger than the value
+ obtained in the previous paragraph, you should use the
+ larger value instead.
+ </para>
+
+ <para>
+ Assuming that you can create all desired tables without any
+ problems, you should also verify that this number is
+ sufficient by trying an actual <literal role="stmt">ALTER
+ TABLE</literal> after configuring the parameter. If this is
+ not successful, increase
+ <literal>MaxNoOfAttributes</literal> by another multiple of
+ <literal>MaxNoOfTables</literal> and test it again.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfTables</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooftables">
+ <literal>MaxNoOfTables</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnooftables-ndbd"/>
+
+ <para>
+ A table object is allocated for each table, unique hash
+ index, and ordered index. This parameter sets the maximum
+ number of table objects for the cluster as a whole.
+ </para>
+
+ <para>
+ For each attribute that has a
+ <literal role="type">BLOB</literal> data type an extra table
+ is used to store most of the
+ <literal role="type">BLOB</literal> data. These tables also
+ must be taken into account when defining the total number of
+ tables.
+ </para>
+
+ <para>
+ The default value of this parameter is 128. The minimum is 8
+ and the maximum is 1600. Each table object consumes
+ approximately 20KB per node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfOrderedIndexes</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooforderedindexes">
+ <literal>MaxNoOfOrderedIndexes</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnooforderedindexes-ndbd"/>
+
+ <para>
+ For each ordered index in the cluster, an object is
+ allocated describing what is being indexed and its storage
+ segments. By default, each index so defined also defines an
+ ordered index. Each unique index and primary key has both an
+ ordered index and a hash index.
+ <literal>MaxNoOfOrderedIndexes</literal> sets the total
+ number of hash indexes that can be in use in the system at
+ any one time.
+ </para>
+
+ <para>
+ The default value of this parameter is 128. Each hash index
+ object consumes approximately 10KB of data per node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfUniqueHashIndexes</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofuniquehashindexes">
+ <literal>MaxNoOfUniqueHashIndexes</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnoofuniquehashindexes-ndbd"/>
+
+ <para>
+ For each unique index that is not a primary key, a special
+ table is allocated that maps the unique key to the primary
+ key of the indexed table. By default, an ordered index is
+ also defined for each unique index. To prevent this, you
+ must specify the <literal>USING HASH</literal> option when
+ defining the unique index.
+ </para>
+
+ <para>
+ The default value is 64. Each index consumes approximately
+ 15KB per node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfTriggers</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooftriggers">
+ <literal>MaxNoOfTriggers</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnooftriggers-ndbd"/>
+
+ <para>
+ Internal update, insert, and delete triggers are allocated
+ for each unique hash index. (This means that three triggers
+ are created for each unique hash index.) However, an
+ <emphasis>ordered</emphasis> index requires only a single
+ trigger object. Backups also use three trigger objects for
+ each normal table in the cluster.
+ </para>
+
+ <para>
+ This parameter sets the maximum number of trigger objects in
+ the cluster.
+ </para>
+
+ <para>
+ The default value is 768.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfIndexes</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofindexes">
+ <literal>MaxNoOfIndexes</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxnoofindexes-ndbd"/>
+
+ <para>
+ This parameter was deprecated in MySQL 4.1.5. In MySQL 4.1.6
+ and newer versions; you should use
+ <literal>MaxNoOfOrderedIndexes</literal> and
+ <literal>MaxNoOfUniqueHashIndexes</literal> instead.
+ </para>
+
+ <para>
+ This parameter is used only by unique hash indexes. There
+ needs to be one record in this pool for each unique hash
+ index defined in the cluster.
+ </para>
+
+ <para>
+ The default value of this parameter is 128.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Boolean parameters</title>
+
+ <para id="mysql-cluster-boolean-parameters">
+ The behavior of data nodes is also affected by a set of
+ <literal>[ndbd]</literal> parameters taking on boolean values.
+ These parameters can each be specified as
+ <literal>TRUE</literal> by setting them equal to
+ <literal>1</literal> or <literal>Y</literal>, and as
+ <literal>FALSE</literal> by setting them equal to
+ <literal>0</literal> or <literal>N</literal>.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>LockPagesInMainMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-lockpagesinmainmemory">
+ <literal>LockPagesInMainMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:lockpagesinmainmemory-ndbd"/>
+
+ <para>
+ For a number of operating systems, including Solaris and
+ Linux, it is possible to lock a process into memory and so
+ avoid any swapping to disk. This can be used to help
+ guarantee the cluster's real-time characteristics.
+ </para>
+
+ <para>
+ This feature is disabled by default.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StopOnError</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-stoponerror">
+ <literal>StopOnError</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:stoponerror-ndbd"/>
+
+ <para>
+ This parameter specifies whether an <command>ndbd</command>
+ process should exit or perform an automatic restart when an
+ error condition is encountered.
+ </para>
+
+ <para>
+ This feature is enabled by default.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Diskless</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-diskless">
+ <literal>Diskless</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:diskless-ndbd"/>
+
+ <para>
+ It is possible to specify MySQL Cluster tables as
+ <firstterm>diskless</firstterm>, meaning that tables are not
+ checkpointed to disk and that no logging occurs. Such tables
+ exist only in main memory. A consequence of using diskless
+ tables is that neither the tables nor the records in those
+ tables survive a crash. However, when operating in diskless
+ mode, it is possible to run <command>ndbd</command> on a
+ diskless computer.
+ </para>
+
+ <important>
+ <para>
+ This feature causes the <emphasis>entire</emphasis>
+ cluster to operate in diskless mode.
+ </para>
+ </important>
+
+ <para>
+ When this feature is enabled, Cluster online backup is
+ disabled. In addition, a partial start of the cluster is not
+ possible.
+ </para>
+
+ <para>
+ <literal>Diskless</literal> is disabled by default.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>RestartOnErrorInsert</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-restartonerrorinsert">
+ <literal>RestartOnErrorInsert</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:restartonerrorinsert-ndbd"/>
+
+ <para>
+ This feature is accessible only when building the debug
+ version where it is possible to insert errors in the
+ execution of individual blocks of code as part of testing.
+ </para>
+
+ <para>
+ This feature is disabled by default.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para id="mysql-cluster-timeouts-intervals-disk-paging">
+ <emphasis role="bold">Controlling Timeouts, Intervals, and Disk
+ Paging</emphasis>
+ </para>
+
+ <para>
+ There are a number of <literal>[ndbd]</literal> parameters
+ specifying timeouts and intervals between various actions in
+ Cluster data nodes. Most of the timeout values are specified in
+ milliseconds. Any exceptions to this are mentioned where
+ applicable.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenWatchDogCheck</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweenwatchdogcheck">
+ <literal>TimeBetweenWatchDogCheck</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:timebetweenwatchdogcheck-ndbd"/>
+
+ <para>
+ To prevent the main thread from getting stuck in an endless
+ loop at some point, a <quote>watchdog</quote> thread checks
+ the main thread. This parameter specifies the number of
+ milliseconds between checks. If the process remains in the
+ same state after three checks, the watchdog thread
+ terminates it.
+ </para>
+
+ <para>
+ This parameter can easily be changed for purposes of
+ experimentation or to adapt to local conditions. It can be
+ specified on a per-node basis although there seems to be
+ little reason for doing so.
+ </para>
+
+ <para>
+ The default timeout is 4000 milliseconds (4 seconds).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StartPartialTimeout</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-startpartialtimeout">
+ <literal>StartPartialTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:startpartialtimeout-ndbd"/>
+
+ <para>
+ This parameter specifies how long the Cluster waits for all
+ data nodes to come up before the cluster initialization
+ routine is invoked. This timeout is used to avoid a partial
+ Cluster startup whenever possible.
+ </para>
+
+ <para>
+ The default value is 30000 milliseconds (30 seconds). 0
+ disables the timeout, in which case the cluster may start
+ only if all nodes are available.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StartPartitionedTimeout (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-startpartitionedtimeout">
+ <literal>StartPartitionedTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:startpartitionedtimeout-ndbd"/>
+
+ <para>
+ If the cluster is ready to start after waiting for
+ <literal>StartPartialTimeout</literal> milliseconds but is
+ still possibly in a partitioned state, the cluster waits
+ until this timeout has also passed.
+ </para>
+
+ <para>
+ The default timeout is 60000 milliseconds (60 seconds).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StartFailureTimeout (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-startfailuretimeout">
+ <literal>StartFailureTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:startfailuretimeout-ndbd"/>
+
+ <para>
+ If a data node has not completed its startup sequence within
+ the time specified by this parameter, the node startup
+ fails. Setting this parameter to 0 (the default value) means
+ that no data node timeout is applied.
+ </para>
+
+ <para>
+ For nonzero values, this parameter is measured in
+ milliseconds. For data nodes containing extremely large
+ amounts of data, this parameter should be increased. For
+ example, in the case of a data node containing several
+ gigabytes of data, a period as long as 10−15 minutes
+ (that is, 600000 to 1000000 milliseconds) might be required
+ to perform a node restart.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HeartbeatIntervalDbDb (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-heartbeatintervaldbdb">
+ <literal>HeartbeatIntervalDbDb</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:heartbeatintervaldbdb-ndbd"/>
+
+ <para>
+ One of the primary methods of discovering failed nodes is by
+ the use of heartbeats. This parameter states how often
+ heartbeat signals are sent and how often to expect to
+ receive them. After missing three heartbeat intervals in a
+ row, the node is declared dead. Thus, the maximum time for
+ discovering a failure through the heartbeat mechanism is
+ four times the heartbeat interval.
+ </para>
+
+ <para>
+ The default heartbeat interval is 1500 milliseconds (1.5
+ seconds). This parameter must not be changed drastically and
+ should not vary widely between nodes. If one node uses 5000
+ milliseconds and the node watching it uses 1000
+ milliseconds, obviously the node will be declared dead very
+ quickly. This parameter can be changed during an online
+ software upgrade, but only in small increments.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HeartbeatIntervalDbApi (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-heartbeatintervaldbapi">
+ <literal>HeartbeatIntervalDbApi</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:heartbeatintervaldbapi-ndbd"/>
+
+ <para>
+ Each data node sends heartbeat signals to each MySQL server
+ (SQL node) to ensure that it remains in contact. If a MySQL
+ server fails to send a heartbeat in time it is declared
+ <quote>dead,</quote> in which case all ongoing transactions
+ are completed and all resources released. The SQL node
+ cannot reconnect until all activities initiated by the
+ previous MySQL instance have been completed. The
+ three-heartbeat criteria for this determination are the same
+ as described for <literal>HeartbeatIntervalDbDb</literal>.
+ </para>
+
+ <para>
+ The default interval is 1500 milliseconds (1.5 seconds).
+ This interval can vary between individual data nodes because
+ each data node watches the MySQL servers connected to it,
+ independently of all other data nodes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenLocalCheckpoints (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweenlocalcheckpoints">
+ <literal>TimeBetweenLocalCheckpoints</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:timebetweenlocalcheckpoints-ndbd"/>
+
+ <para>
+ This parameter is an exception in that it does not specify a
+ time to wait before starting a new local checkpoint; rather,
+ it is used to ensure that local checkpoints are not
+ performed in a cluster where relatively few updates are
+ taking place. In most clusters with high update rates, it is
+ likely that a new local checkpoint is started immediately
+ after the previous one has been completed.
+ </para>
+
+ <para>
+ The size of all write operations executed since the start of
+ the previous local checkpoints is added. This parameter is
+ also exceptional in that it is specified as the base-2
+ logarithm of the number of 4-byte words, so that the default
+ value 20 means 4MB (4 ×
+ 2<superscript>20</superscript>) of write operations, 21
+ would mean 8MB, and so on up to a maximum value of 31, which
+ equates to 8GB of write operations.
+ </para>
+
+ <para>
+ All the write operations in the cluster are added together.
+ Setting <literal>TimeBetweenLocalCheckpoints</literal> to 6
+ or less means that local checkpoints will be executed
+ continuously without pause, independent of the cluster's
+ workload.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenGlobalCheckpoints (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweenglobalcheckpoints">
+ <literal>TimeBetweenGlobalCheckpoints</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:timebetweenglobalcheckpoints-ndbd"/>
+
+ <para>
+ When a transaction is committed, it is committed in main
+ memory in all nodes on which the data is mirrored. However,
+ transaction log records are not flushed to disk as part of
+ the commit. The reasoning behind this behavior is that
+ having the transaction safely committed on at least two
+ autonomous host machines should meet reasonable standards
+ for durability.
+ </para>
+
+ <para>
+ It is also important to ensure that even the worst of cases
+ — a complete crash of the cluster — is handled
+ properly. To guarantee that this happens, all transactions
+ taking place within a given interval are put into a global
+ checkpoint, which can be thought of as a set of committed
+ transactions that has been flushed to disk. In other words,
+ as part of the commit process, a transaction is placed in a
+ global checkpoint group. Later, this group's log records are
+ flushed to disk, and then the entire group of transactions
+ is safely committed to disk on all computers in the cluster.
+ </para>
+
+ <para>
+ This parameter defines the interval between global
+ checkpoints. The default is 2000 milliseconds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenInactiveTransactionAbortCheck (MySQL Cluster configuration
+ parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweeninactivetransactionabortcheck">
+ <literal>TimeBetweenInactiveTransactionAbortCheck</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:timebetweeninactivetransactionabortcheck-ndbd"/>
+
+ <para>
+ Timeout handling is performed by checking a timer on each
+ transaction once for every interval specified by this
+ parameter. Thus, if this parameter is set to 1000
+ milliseconds, every transaction will be checked for timing
+ out once per second.
+ </para>
+
+ <para>
+ The default value is 1000 milliseconds (1 second).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TransactionInactiveTimeout (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-transactioninactivetimeout">
+ <literal>TransactionInactiveTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:transactioninactivetimeout-ndbd"/>
+
+ <para>
+ This parameter states the maximum time that is permitted to
+ lapse between operations in the same transaction before the
+ transaction is aborted.
+ </para>
+
+ <para>
+ The default for this parameter is zero (no timeout). For a
+ real-time database that needs to ensure that no transaction
+ keeps locks for too long, this parameter should be set to a
+ relatively small value. The unit is milliseconds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TransactionDeadlockDetectionTimeout</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-transactiondeadlockdetectiontimeout">
+ <literal>TransactionDeadlockDetectionTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:transactiondeadlockdetectiontimeout-ndbd"/>
+
+ <para>
+ When a node executes a query involving a transaction, the
+ node waits for the other nodes in the cluster to respond
+ before continuing. A failure to respond can occur for any of
+ the following reasons:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The node is <quote>dead</quote>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The operation has entered a lock queue
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The node requested to perform the action could be
+ heavily overloaded.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ This timeout parameter states how long the transaction
+ coordinator waits for query execution by another node before
+ aborting the transaction, and is important for both node
+ failure handling and deadlock detection. In MySQL 4.1.18 and
+ earlier versions, setting it too high could cause
+ undesirable behavior in situations involving deadlocks and
+ node failure. Beginning with MySQL 4.1.19, active
+ transactions occurring during node failures are actively
+ aborted by the Cluster Transaction Coordinator, and so high
+ settings are no longer an issue with this parameter.
+ </para>
+
+ <para>
+ The default timeout value is 1200 milliseconds (1.2
+ seconds). The effective minimum value is 100 milliseconds;
+ it is possible to set it as low as 50 milliseconds, but any
+ such value is treated as 100 ms. (Bug#44099)
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskAfterRestartTUP</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofdiskpagestodiskafterrestarttup">
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:noofdiskpagestodiskafterrestarttup-ndbd"/>
+
+ <para>
+ When executing a local checkpoint, the algorithm flushes all
+ data pages to disk. Merely doing so as quickly as possible
+ without any moderation is likely to impose excessive loads
+ on processors, networks, and disks. To control the write
+ speed, this parameter specifies how many pages per 100
+ milliseconds are to be written. In this context, a
+ <quote>page</quote> is defined as 8KB. This parameter is
+ specified in units of 80KB per second, so setting
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> to a
+ value of <literal>20</literal> entails writing 1.6MB in data
+ pages to disk each second during a local checkpoint. This
+ value includes the writing of UNDO log records for data
+ pages. That is, this parameter handles the limitation of
+ writes from data memory. UNDO log records for index pages
+ are handled by the parameter
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal>. (See
+ the entry for <literal>IndexMemory</literal> for information
+ about index pages.)
+ </para>
+
+ <para>
+ In short, this parameter specifies how quickly to execute
+ local checkpoints. It operates in conjunction with
+ <literal>NoOfFragmentLogFiles</literal>,
+ <literal>DataMemory</literal>, and
+ <literal>IndexMemory</literal>.
+ </para>
+
+ <para>
+ For more information about the interaction between these
+ parameters and possible strategies for choosing appropriate
+ values for them, see
+ <xref linkend="mysql-cluster-config-lcp-params"/>.
+ </para>
+
+ <para>
+ The default value is 40 (3.2MB of data pages per second).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskAfterRestartACC</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofdiskpagestodiskafterrestartacc">
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:noofdiskpagestodiskafterrestartacc-ndbd"/>
+
+ <para>
+ This parameter uses the same units as
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> and
+ acts in a similar fashion, but limits the speed of writing
+ index pages from index memory.
+ </para>
+
+ <para>
+ The default value of this parameter is 20 (1.6MB of index
+ memory pages per second).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskDuringRestartTUP</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofdiskpagestodiskduringrestarttup">
+ <literal>NoOfDiskPagesToDiskDuringRestartTUP</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:noofdiskpagestodiskduringrestarttup-ndbd"/>
+
+ <para>
+ This parameter is used in a fashion similar to
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> and
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal>, only
+ it does so with regard to local checkpoints executed in the
+ node when a node is restarting. A local checkpoint is always
+ performed as part of all node restarts. During a node
+ restart it is possible to write to disk at a higher speed
+ than at other times, because fewer activities are being
+ performed in the node.
+ </para>
+
+ <para>
+ This parameter covers pages written from data memory.
+ </para>
+
+ <para>
+ The default value is 40 (3.2MB per second).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskDuringRestartACC</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofdiskpagestodiskduringrestartacc">
+ <literal>NoOfDiskPagesToDiskDuringRestartACC</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:noofdiskpagestodiskduringrestartacc-ndbd"/>
+
+ <para>
+ Controls the number of index memory pages that can be
+ written to disk during the local checkpoint phase of a node
+ restart.
+ </para>
+
+ <para>
+ As with
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> and
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal>,
+ values for this parameter are expressed in terms of 8KB
+ pages written per 100 milliseconds (80KB/second).
+ </para>
+
+ <para>
+ The default value is 20 (1.6MB per second).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationTimeout</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-arbitrationtimeout">
+ <literal>ArbitrationTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:arbitrationtimeout-ndbd"/>
+
+ <para>
+ This parameter specifies how long data nodes wait for a
+ response from the arbitrator to an arbitration message. If
+ this is exceeded, the network is assumed to have split.
+ </para>
+
+ <para>
+ The default value is 1000 milliseconds (1 second).
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Buffering and logging</title>
+
+ <para id="mysql-cluster-buffering-and-logging">
+ Several <literal>[ndbd]</literal> configuration parameters
+ corresponding to former compile-time parameters were
+ introduced in MySQL 4.1.5. These enable the advanced user to
+ have more control over the resources used by node processes
+ and to adjust various buffer sizes at need.
+ </para>
+
+ </formalpara>
+
+ <para>
+ These buffers are used as front ends to the file system when
+ writing log records to disk. If the node is running in diskless
+ mode, these parameters can be set to their minimum values
+ without penalty due to the fact that disk writes are
+ <quote>faked</quote> by the <literal role="se">NDB</literal>
+ storage engine's file system abstraction layer.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>UndoIndexBuffer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-undoindexbuffer">
+ <literal>UndoIndexBuffer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:undoindexbuffer-ndbd"/>
+
+ <para>
+ The UNDO index buffer, whose size is set by this parameter,
+ is used during local checkpoints. The
+ <literal role="se">NDB</literal> storage engine uses a
+ recovery scheme based on checkpoint consistency in
+ conjunction with an operational REDO log. To produce a
+ consistent checkpoint without blocking the entire system for
+ writes, UNDO logging is done while performing the local
+ checkpoint. UNDO logging is activated on a single table
+ fragment at a time. This optimization is possible because
+ tables are stored entirely in main memory.
+ </para>
+
+ <para>
+ The UNDO index buffer is used for the updates on the primary
+ key hash index. Inserts and deletes rearrange the hash
+ index; the NDB storage engine writes UNDO log records that
+ map all physical changes to an index page so that they can
+ be undone at system restart. It also logs all active insert
+ operations for each fragment at the start of a local
+ checkpoint.
+ </para>
+
+ <para>
+ Reads and updates set lock bits and update a header in the
+ hash index entry. These changes are handled by the
+ page-writing algorithm to ensure that these operations need
+ no UNDO logging.
+ </para>
+
+ <para>
+ This buffer is 2MB by default. The minimum value is 1MB,
+ which is sufficient for most applications. For applications
+ doing extremely large or numerous inserts and deletes
+ together with large transactions and large primary keys, it
+ may be necessary to increase the size of this buffer. If
+ this buffer is too small, the NDB storage engine issues
+ internal error code 677 (<literal>Index UNDO buffers
+ overloaded</literal>).
+ </para>
+
+ <important>
+ <para>
+ It is not safe to decrease the value of this parameter
+ during a rolling restart.
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>UndoDataBuffer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-undodatabuffer">
+ <literal>UndoDataBuffer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:undodatabuffer-ndbd"/>
+
+ <para>
+ This parameter sets the size of the UNDO data buffer, which
+ performs a function similar to that of the UNDO index
+ buffer, except the UNDO data buffer is used with regard to
+ data memory rather than index memory. This buffer is used
+ during the local checkpoint phase of a fragment for inserts,
+ deletes, and updates.
+ </para>
+
+ <para>
+ Because UNDO log entries tend to grow larger as more
+ operations are logged, this buffer is also larger than its
+ index memory counterpart, with a default value of 16MB.
+ </para>
+
+ <para>
+ This amount of memory may be unnecessarily large for some
+ applications. In such cases, it is possible to decrease this
+ size to a minimum of 1MB.
+ </para>
+
+ <para>
+ It is rarely necessary to increase the size of this buffer.
+ If there is such a need, it is a good idea to check whether
+ the disks can actually handle the load caused by database
+ update activity. A lack of sufficient disk space cannot be
+ overcome by increasing the size of this buffer.
+ </para>
+
+ <para>
+ If this buffer is too small and gets congested, the NDB
+ storage engine issues internal error code 891
+ (<errortext>Data UNDO buffers overloaded</errortext>).
+ </para>
+
+ <important>
+ <para>
+ It is not safe to decrease the value of this parameter
+ during a rolling restart.
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>RedoBuffer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-redobuffer">
+ <literal>RedoBuffer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:redobuffer-ndbd"/>
+
+ <para>
+ All update activities also need to be logged. The REDO log
+ makes it possible to replay these updates whenever the
+ system is restarted. The NDB recovery algorithm uses a
+ <quote>fuzzy</quote> checkpoint of the data together with
+ the UNDO log, and then applies the REDO log to play back all
+ changes up to the restoration point.
+ </para>
+
+ <para>
+ <literal>RedoBuffer</literal> sets the size of the buffer in
+ which the REDO log is written, and is 8MB by default. The
+ minimum value is 1MB.
+ </para>
+
+ <para>
+ If this buffer is too small, the NDB storage engine issues
+ error code 1221 (<literal>REDO log buffers
+ overloaded</literal>).
+ </para>
+
+ <important>
+ <para>
+ It is not safe to decrease the value of this parameter
+ during a rolling restart.
+ </para>
+ </important>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Controlling log messages</title>
+
+ <para id="mysql-cluster-controlling-log-messages">
+ In managing the cluster, it is very important to be able to
+ control the number of log messages sent for various event
+ types to <literal>stdout</literal>. For each event category,
+ there are 16 possible event levels (numbered 0 through 15).
+ Setting event reporting for a given event category to level 15
+ means all event reports in that category are sent to
+ <literal>stdout</literal>; setting it to 0 means that there
+ will be no event reports made in that category.
+ </para>
+
+ </formalpara>
+
+ <para>
+ By default, only the startup message is sent to
+ <literal>stdout</literal>, with the remaining event reporting
+ level defaults being set to 0. The reason for this is that these
+ messages are also sent to the management server's cluster log.
+ </para>
+
+ <para>
+ An analogous set of levels can be set for the management client
+ to determine which event levels to record in the cluster log.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelStartup</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelstartup">
+ <literal>LogLevelStartup</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:loglevelstartup-ndbd"/>
+
+ <para>
+ The reporting level for events generated during startup of
+ the process.
+ </para>
+
+ <para>
+ The default level is 1.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelShutdown</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelshutdown">
+ <literal>LogLevelShutdown</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:loglevelshutdown-ndbd"/>
+
+ <para>
+ The reporting level for events generated as part of graceful
+ shutdown of a node.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelStatistic (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelstatistic">
+ <literal>LogLevelStatistic</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:loglevelstatistic-ndbd"/>
+
+ <para>
+ The reporting level for statistical events such as number of
+ primary key reads, number of updates, number of inserts,
+ information relating to buffer usage, and so on.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelCheckpoint (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelcheckpoint">
+ <literal>LogLevelCheckpoint</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:loglevelcheckpoint-ndbd"/>
+
+ <para>
+ The reporting level for events generated by local and global
+ checkpoints.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelNodeRestart (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelnoderestart">
+ <literal>LogLevelNodeRestart</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:loglevelnoderestart-ndbd"/>
+
+ <para>
+ The reporting level for events generated during node
+ restart.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelConnection (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelconnection">
+ <literal>LogLevelConnection</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:loglevelconnection-ndbd"/>
+
+ <para>
+ The reporting level for events generated by connections
+ between cluster nodes.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelError</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelerror">
+ <literal>LogLevelError</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:loglevelerror-ndbd"/>
+
+ <para>
+ The reporting level for events generated by errors and
+ warnings by the cluster as a whole. These errors do not
+ cause any node failure but are still considered worth
+ reporting.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelInfo</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelinfo">
+ <literal>LogLevelInfo</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:loglevelinfo-ndbd"/>
+
+ <para>
+ The reporting level for events generated for information
+ about the general state of the cluster.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Backup parameters</title>
+
+ <para id="mysql-cluster-backup-parameters">
+ The <literal>[ndbd]</literal> parameters discussed in this
+ section define memory buffers set aside for execution of
+ online backups.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupDataBufferSize (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupdatabuffersize">
+ <literal>BackupDataBufferSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:backupdatabuffersize-ndbd"/>
+
+ <para>
+ In creating a backup, there are two buffers used for sending
+ data to the disk. The backup data buffer is used to fill in
+ data recorded by scanning a node's tables. Once this buffer
+ has been filled to the level specified as
+ <literal>BackupWriteSize</literal> (see below), the pages
+ are sent to disk. While flushing data to disk, the backup
+ process can continue filling this buffer until it runs out
+ of space. When this happens, the backup process pauses the
+ scan and waits until some disk writes have completed freed
+ up memory so that scanning may continue.
+ </para>
+
+ <para>
+ The default value is 2MB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupLogBufferSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backuplogbuffersize">
+ <literal>BackupLogBufferSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:backuplogbuffersize-ndbd"/>
+
+ <para>
+ The backup log buffer fulfills a role similar to that played
+ by the backup data buffer, except that it is used for
+ generating a log of all table writes made during execution
+ of the backup. The same principles apply for writing these
+ pages as with the backup data buffer, except that when there
+ is no more space in the backup log buffer, the backup fails.
+ For that reason, the size of the backup log buffer must be
+ large enough to handle the load caused by write activities
+ while the backup is being made. See
+ <xref linkend="mysql-cluster-backup-configuration"/>.
+ </para>
+
+ <para>
+ The default value for this parameter should be sufficient
+ for most applications. In fact, it is more likely for a
+ backup failure to be caused by insufficient disk write speed
+ than it is for the backup log buffer to become full. If the
+ disk subsystem is not configured for the write load caused
+ by applications, the cluster is unlikely to be able to
+ perform the desired operations.
+ </para>
+
+ <para>
+ It is preferable to configure cluster nodes in such a manner
+ that the processor becomes the bottleneck rather than the
+ disks or the network connections.
+ </para>
+
+ <para>
+ The default value is 2MB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupmemory">
+ <literal>BackupMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:backupmemory-ndbd"/>
+
+ <para>
+ This parameter is simply the sum of
+ <literal>BackupDataBufferSize</literal> and
+ <literal>BackupLogBufferSize</literal>.
+ </para>
+
+ <para>
+ The default value is 2MB + 2MB = 4MB.
+ </para>
+
+ <important>
+ <para>
+ If <literal>BackupDataBufferSize</literal> and
+ <literal>BackupLogBufferSize</literal> taken together
+ exceed 4MB, then this parameter must be set explicitly in
+ the <filename>config.ini</filename> file to their sum.
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupWriteSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupwritesize">
+ <literal>BackupWriteSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:backupwritesize-ndbd"/>
+
+ <para>
+ This parameter specifies the default size of messages
+ written to disk by the backup log and backup data buffers.
+ </para>
+
+ <para>
+ The default value is 32KB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupMaxWriteSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupmaxwritesize">
+ <literal>BackupMaxWriteSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:backupmaxwritesize-ndbd"/>
+
+ <para>
+ This parameter specifies the maximum size of messages
+ written to disk by the backup log and backup data buffers.
+ </para>
+
+ <para>
+ The default value is 256KB.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <important>
+ <para>
+ When specifying these parameters, the following relationships
+ must hold true. Otherwise, the data node will be unable to
+ start.
+ </para>
+ </important>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>BackupDataBufferSize >= BackupWriteSize +
+ 188KB</literal>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>BackupLogBufferSize >= BackupWriteSize +
+ 16KB</literal>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>BackupMaxWriteSize >= BackupWriteSize</literal>
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <note>
+ <para>
+ To add new data nodes to a MySQL Cluster, it is necessary to
+ shut down the cluster completely, update the
+ <filename>config.ini</filename> file, and then restart the
+ cluster (that is, you must perform a system restart). All data
+ node processes must be started with the
+ <option>--initial</option> option.
+ </para>
+
+ <para>
+ We are working to make it possible to add new data node groups
+ to a running cluster online in a future release; however, we
+ do not plan to implement this change in MySQL
+ ¤t-series;.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-api-definition">
+
+ <title>Defining SQL and Other API Nodes in a MySQL Cluster</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>SQL node</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>API node</secondary>
+ </indexterm>
+
+ <para>
+ The <literal>[mysqld]</literal> and <literal>[api]</literal>
+ sections in the <filename>config.ini</filename> file define the
+ behavior of the MySQL servers (SQL nodes) and other applications
+ (API nodes) used to access cluster data. None of the parameters
+ shown is required. If no computer or host name is provided, any
+ host can use this SQL or API node.
+ </para>
+
+ <para>
+ Generally speaking, a <literal>[mysqld]</literal> section is
+ used to indicate a MySQL server providing an SQL interface to
+ the cluster, and an <literal>[api]</literal> section is used for
+ applications other than <command>mysqld</command> processes
+ accessing cluster data, but the two designations are actually
+ synonomous; you can, for instance, list parameters for a MySQL
+ server acting as an SQL node in an <literal>[api]</literal>
+ section.
+ </para>
+
+ <note>
+ <para>
+ For a discussion of MySQL server options for MySQL Cluster,
+ see <xref linkend="mysql-cluster-program-options-mysqld"/>;
+ for information about MySQL server system variables relating
+ to MySQL Cluster, see
+ <xref linkend="mysql-cluster-system-variables"/>.
+ </para>
+ </note>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>Id</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-id">
+ <literal>Id</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:id-api"/>
+
+ <para>
+ The <literal>Id</literal> value is used to identify the node
+ in all cluster internal messages. It must be an integer in
+ the range 1 to 63 inclusive, and must be unique among all
+ node IDs within the cluster.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ExecuteOnComputer</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-executeoncomputer">
+ <literal>ExecuteOnComputer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:executeoncomputer-api"/>
+
+ <para>
+ This refers to the <literal>Id</literal> set for one of the
+ computers (hosts) defined in a <literal>[computer]</literal>
+ section of the configuration file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HostName</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-hostname">
+ <literal>HostName</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:hostname-api"/>
+
+ <para>
+ Specifying this parameter defines the host name of the
+ computer on which the SQL node (API node) is to reside. To
+ specify a host name, either this parameter or
+ <literal>ExecuteOnComputer</literal> is required.
+ </para>
+
+ <para>
+ If no <literal>HostName</literal> or
+ <literal>ExecuteOnComputer</literal> is specified in a given
+ <literal>[mysql]</literal> or <literal>[api]</literal>
+ section of the <filename>config.ini</filename> file, then an
+ SQL or API node may connect using the corresponding
+ <quote>slot</quote> from any host which can establish a
+ network connection to the management server host machine.
+ <emphasis>This differs from the default behavior for data
+ nodes, where <literal>localhost</literal> is assumed for
+ <literal>HostName</literal> unless otherwise
+ specified</emphasis>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationRank</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-arbitrationrank">
+ <literal>ArbitrationRank</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:arbitrationrank-api"/>
+
+ <para>
+ This parameter defines which nodes can act as arbitrators.
+ Both MGM nodes and SQL nodes can be arbitrators. A value of
+ 0 means that the given node is never used as an arbitrator,
+ a value of 1 gives the node high priority as an arbitrator,
+ and a value of 2 gives it low priority. A normal
+ configuration uses the management server as arbitrator,
+ setting its <literal>ArbitrationRank</literal> to 1 (the
+ default) and those for all SQL nodes to 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationDelay</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-arbitrationdelay">
+ <literal>ArbitrationDelay</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:arbitrationdelay-api"/>
+
+ <para>
+ Setting this parameter to any other value than 0 (the
+ default) means that responses by the arbitrator to
+ arbitration requests will be delayed by the stated number of
+ milliseconds. It is usually not necessary to change this
+ value.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BatchByteSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-batchbytesize">
+ <literal>BatchByteSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:batchbytesize-api"/>
+
+ <remark role="todo">
+ Add pointers to discussions of table scans and range scans
+ in Optimization chapter. [js]
+ </remark>
+
+ <para>
+ For queries that are translated into full table scans or
+ range scans on indexes, it is important for best performance
+ to fetch records in properly sized batches. It is possible
+ to set the proper size both in terms of number of records
+ (<literal>BatchSize</literal>) and in terms of bytes
+ (<literal>BatchByteSize</literal>). The actual batch size is
+ limited by both parameters.
+ </para>
+
+ <para>
+ The speed at which queries are performed can vary by more
+ than 40% depending upon how this parameter is set. In future
+ releases, MySQL Server will make educated guesses on how to
+ set parameters relating to batch size, based on the query
+ type.
+ </para>
+
+ <para>
+ This parameter is measured in bytes and by default is equal
+ to 32KB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BatchSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-batchsize">
+ <literal>BatchSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:batchsize-api"/>
+
+ <para>
+ This parameter is measured in number of records and is by
+ default set to 64. The maximum size is 992.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxScanBatchSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-maxscanbatchsize">
+ <literal>MaxScanBatchSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:maxscanbatchsize-api"/>
+
+ <para>
+ The batch size is the size of each batch sent from each data
+ node. Most scans are performed in parallel to protect the
+ MySQL Server from receiving too much data from many nodes in
+ parallel; this parameter sets a limit to the total batch
+ size over all nodes.
+ </para>
+
+ <para>
+ The default value of this parameter is set to 256KB. Its
+ maximum size is 16MB.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ You can obtain some information from a MySQL server running as a
+ Cluster SQL node using <literal role="stmt">SHOW
+ STATUS</literal> in the <literal>mysql</literal> client, as
+ shown here:
+ </para>
+
+<programlisting>
+mysql> <userinput>SHOW STATUS LIKE 'ndb%';</userinput>
++-----------------------------+---------------+
+| Variable_name | Value |
++-----------------------------+---------------+
+| Ndb_cluster_node_id | 5 |
+| Ndb_config_from_host | 192.168.0.112 |
+| Ndb_config_from_port | 1186 |
+| Ndb_number_of_storage_nodes | 4 |
++-----------------------------+---------------+
+4 rows in set (0.02 sec)
+</programlisting>
+
+ <para>
+ For information about these Cluster system status variables, see
+ <xref linkend="server-status-variables"/>.
+ </para>
+
+ <note>
+ <para>
+ To add new SQL or API nodes to the configuration of a running
+ MySQL Cluster, it is necessary to perform a rolling restart of
+ all cluster nodes after adding new <literal>[mysqld]</literal>
+ or <literal>[api]</literal> sections to the
+ <filename>config.ini</filename> file (or files, if you are
+ using more than one management server). This must be done
+ before the new SQL or API nodes can connect to the cluster.
+ </para>
+
+ <para>
+ It is <emphasis>not</emphasis> necessary to perform any
+ restart of the cluster if new SQL or API nodes can employ
+ previously unused API slots in the cluster configuration to
+ connect to the cluster.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-tcp-definition">
+
+ <title>MySQL Cluster TCP/IP Connections</title>
+
+ <para>
+ TCP/IP is the default transport mechanism for all connections
+ between nodes in a MySQL Cluster. Normally it is not necessary
+ to define TCP/IP connections; MySQL Cluster automatically sets
+ up such connections for all data nodes, management nodes, and
+ SQL or API nodes.
+ </para>
+
+ <note>
+ <para>
+ For an exception to this rule, see
+ <xref linkend="mysql-cluster-tcp-definition-direct"/>.
+ </para>
+ </note>
+
+ <para>
+ To override the default connection parameters, it is necessary
+ to define a connection using one or more
+ <literal>[tcp]</literal> sections in the
+ <filename>config.ini</filename> file. Each
+ <literal>[tcp]</literal> section explicitly defines a TCP/IP
+ connection between two MySQL Cluster nodes, and must contain at
+ a minimum the parameters <literal>NodeId1</literal> and
+ <literal>NodeId2</literal>, as well as any connection parameters
+ to override.
+ </para>
+
+ <para>
+ It is also possible to change the default values for these
+ parameters by setting them in the <literal>[tcp
+ default]</literal> section.
+ </para>
+
+ <important>
+ <para>
+ Any <literal>[tcp]</literal> sections in the
+ <filename>config.ini</filename> file should be listed
+ <emphasis>last</emphasis>, following all other sections in the
+ file. However, this is not required for a <literal>[tcp
+ default]</literal> section. This requirement is a known issue
+ with the way in which the <filename>config.ini</filename> file
+ is read by the MySQL Cluster management server.
+ </para>
+ </important>
+
+ <para>
+ Connection parameters which can be set in
+ <literal>[tcp]</literal> and <literal>[tcp default]</literal>
+ sections of the <filename>config.ini</filename> file are listed
+ here:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para id="ndbparam-tcp-nodeid">
+ <literal>NodeId1</literal>, <literal>NodeId2</literal>
+ </para>
+
+ <para>
+ To identify a connection between two nodes it is necessary
+ to provide their node IDs in the <literal>[tcp]</literal>
+ section of the configuration file. These are the same unique
+ <literal>Id</literal> values for each of these nodes as
+ described in <xref linkend="mysql-cluster-api-definition"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendBufferMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-sendbuffermemory">
+ <literal>SendBufferMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:sendbuffermemory-tcp"/>
+
+ <para>
+ TCP transporters use a buffer to store all messages before
+ performing the send call to the operating system. When this
+ buffer reaches 64KB its contents are sent; these are also
+ sent when a round of messages have been executed. To handle
+ temporary overload situations it is also possible to define
+ a bigger send buffer.
+ </para>
+
+ <para>
+ The default size of the send buffer is 256 KB; 2MB is
+ recommended in most situations in which it is necessary to
+ set this parameter. The minimum size is 64 KB; the
+ theoretical maximum is 4 GB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendSignalId</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-sendsignalid">
+ <literal>SendSignalId</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:sendsignalid-tcp"/>
+
+ <para>
+ To be able to retrace a distributed message datagram, it is
+ necessary to identify each message. When this parameter is
+ set to <literal>Y</literal>, message IDs are transported
+ over the network. This feature is disabled by default in
+ production builds, and enabled in <literal>-debug</literal>
+ builds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Checksum</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-checksum">
+ <literal>Checksum</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:checksum-tcp"/>
+
+ <para>
+ This parameter is a boolean parameter (enabled by setting it
+ to <literal>Y</literal> or <literal>1</literal>, disabled by
+ setting it to <literal>N</literal> or <literal>0</literal>).
+ It is disabled by default. When it is enabled, checksums for
+ all messages are calculated before they placed in the send
+ buffer. This feature ensures that messages are not corrupted
+ while waiting in the send buffer, or by the transport
+ mechanism.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>PortNumber</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-portnumber">
+ <literal>PortNumber</literal>
+ (<emphasis>OBSOLETE</emphasis>)
+ </para>
+
+ <para>
+ This formerly specified the port number to be used for
+ listening for connections from other nodes. This parameter
+ should no longer be used.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ReceiveBufferMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-receivebuffermemory">
+ <literal>ReceiveBufferMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:receivebuffermemory-tcp"/>
+
+ <para>
+ Specifies the size of the buffer used when receiving data
+ from the TCP/IP socket.
+ </para>
+
+ <para>
+ The default value of this parameter from its of 64 KB; 1M is
+ recommended in most situations where the size of the receive
+ buffer needs to be set. The minimum possible value is 16K;
+ theoretical maximum is 4G.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
+ <section id="mysql-cluster-tcp-definition-direct">
+
+ <title>MySQL Cluster TCP/IP Connections Using Direct Connections</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>networking</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>transporters</secondary>
+ <tertiary>TCP/IP</tertiary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>direct connections between nodes</secondary>
+ </indexterm>
+
+ <para>
+ Setting up a cluster using direct connections between data nodes
+ requires specifying explicitly the crossover IP addresses of the
+ data nodes so connected in the <literal>[tcp]</literal> section
+ of the cluster <filename>config.ini</filename> file.
+ </para>
+
+ <para>
+ In the following example, we envision a cluster with at least
+ four hosts, one each for a management server, an SQL node, and
+ two data nodes. The cluster as a whole resides on the
+ <literal>172.23.72.*</literal> subnet of a LAN. In addition to
+ the usual network connections, the two data nodes are connected
+ directly using a standard crossover cable, and communicate with
+ one another directly using IP addresses in the
+ <literal>1.1.0.*</literal> address range as shown:
+ </para>
+
+<programlisting>
+# Management Server
+[ndb_mgmd]
+Id=1
+HostName=172.23.72.20
+
+# SQL Node
+[mysqld]
+Id=2
+HostName=172.23.72.21
+
+# Data Nodes
+[ndbd]
+Id=3
+HostName=172.23.72.22
+
+[ndbd]
+Id=4
+HostName=172.23.72.23
+
+# TCP/IP Connections
+[tcp]
+NodeId1=3
+NodeId2=4
+HostName1=1.1.0.1
+HostName2=1.1.0.2
+</programlisting>
+
+ <para>
+ The <literal>HostName<replaceable>N</replaceable></literal>
+ parameter, where <replaceable>N</replaceable> is an integer, is
+ used only when specifying direct TCP/IP connections.
+ </para>
+
+ <para>
+ The use of direct connections between data nodes can improve the
+ cluster's overall efficiency by allowing the data nodes to
+ bypass an Ethernet device such as a switch, hub, or router, thus
+ cutting down on the cluster's latency. It is important to note
+ that to take the best advantage of direct connections in this
+ fashion with more than two data nodes, you must have a direct
+ connection between each data node and every other data node in
+ the same node group.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-shm-definition">
+
+ <title>MySQL Cluster Shared-Memory Connections</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>networking</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>shared memory transporter</primary>
+<!-- <see>MySQL Cluster</see> -->
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>shared memory transport</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>transporters</secondary>
+ <tertiary>shared memory (SHM)</tertiary>
+ </indexterm>
+
+ <para>
+ Beginning with MySQL 4.1.9-max, MySQL Cluster will attempt to
+ use the shared memory transporter and configure it automatically
+ where possible. (In previous versions of MySQL Cluster, shared
+ memory segments functioned only when the <literal>-max</literal>
+ binary was built using <option>--with-ndb-shm</option>.)
+ <literal>[shm]</literal> sections in the
+ <filename>config.ini</filename> file explicitly define
+ shared-memory connections between nodes in the cluster. When
+ explicitly defining shared memory as the connection method, it
+ is necessary to define at least <literal>NodeId1</literal>,
+ <literal>NodeId2</literal> and <literal>ShmKey</literal>. All
+ other parameters have default values that should work well in
+ most cases.
+ </para>
+
+ <important>
+ <para>
+ <emphasis>SHM functionality is considered experimental
+ only</emphasis>. It is not officially supported in any current
+ MySQL Cluster release, and testing results indicate that SHM
+ performance is not appreciably greater than when using TCP/IP
+ for the transporter.
+ </para>
+
+ <para>
+ For these reasons, you must determine for yourself or by using
+ our free resources (forums, mailing lists) whether SHM can be
+ made to work correctly in your specific case.
+ </para>
+ </important>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>node identifiers (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>node identifiers</secondary>
+ </indexterm>
+
+ <para id="ndbparam-shm-nodeids">
+ <literal>NodeId1</literal>, <literal>NodeId2</literal>
+ </para>
+
+ <para>
+ To identify a connection between two nodes it is necessary
+ to provide node identifiers for each of them, as
+ <literal>NodeId1</literal> and <literal>NodeId2</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ShmKey</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-shmkey">
+ <literal>ShmKey</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:shmkey-shm"/>
+
+ <para>
+ When setting up shared memory segments, a node ID, expressed
+ as an integer, is used to identify uniquely the shared
+ memory segment to use for the communication. There is no
+ default value.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ShmSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-shmsize">
+ <literal>ShmSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:shmsize-shm"/>
+
+ <para>
+ Each SHM connection has a shared memory segment where
+ messages between nodes are placed by the sender and read by
+ the reader. The size of this segment is defined by
+ <literal>ShmSize</literal>. The default value is 1MB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendSignalId</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-sendsignalid">
+ <literal>SendSignalId</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:sendsignalid-shm"/>
+
+ <para>
+ To retrace the path of a distributed message, it is
+ necessary to provide each message with a unique identifier.
+ Setting this parameter to <literal>Y</literal> causes these
+ message IDs to be transported over the network as well. This
+ feature is disabled by default in production builds, and
+ enabled in <literal>-debug</literal> builds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Checksum (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-checksum">
+ <literal>Checksum</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:checksum-shm"/>
+
+ <para>
+ This parameter is a boolean
+ (<literal>Y</literal>/<literal>N</literal>) parameter which
+ is disabled by default. When it is enabled, checksums for
+ all messages are calculated before being placed in the send
+ buffer.
+ </para>
+
+ <para>
+ This feature prevents messages from being corrupted while
+ waiting in the send buffer. It also serves as a check
+ against data being corrupted during transport.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SigNum</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-signum">
+ <literal>SigNum</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:signum-shm"/>
+
+ <para>
+ When using the shared memory transporter, a process sends an
+ operating system signal to the other process when there is
+ new data available in the shared memory. Should that signal
+ conflict with with an existing signal, this parameter can be
+ used to change it. This is a possibility when using SHM due
+ to the fact that different operating systems use different
+ signal numbers.
+ </para>
+
+ <para>
+ The default value of <literal>SigNum</literal> is 0;
+ therefore, it must be set to avoid errors in the cluster log
+ when using the shared memory transporter. Typically, this
+ parameter is set to 10 in the <literal>[shm
+ default]</literal> section of the
+ <filename>config.ini</filename> file.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
+ <section id="mysql-cluster-sci-definition">
+
+ <title>SCI Transport Connections in MySQL Cluster</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>networking</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>SCI (Scalable Coherent Interface)</primary>
+<!-- <see>MySQL Cluster</see> -->
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>SCI (Scalable Coherent Interface)</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>transporters</secondary>
+ <tertiary>Scalable Coherent Interface (SCI)</tertiary>
+ </indexterm>
+
+ <para>
+ <literal>[sci]</literal> sections in the
+ <filename>config.ini</filename> file explicitly define SCI
+ (Scalable Coherent Interface) connections between cluster nodes.
+ Using SCI transporters in MySQL Cluster is supported only when
+ the MySQL-Max binaries are built using
+ <option>--with-ndb-sci=<replaceable>/your/path/to/SCI</replaceable></option>.
+ The <replaceable>path</replaceable> should point to a directory
+ that contains at a minimum <filename>lib</filename> and
+ <filename>include</filename> directories containing SISCI
+ libraries and header files. (See
+ <xref linkend="mysql-cluster-interconnects"/> for more
+ information about SCI.)
+ </para>
+
+ <para>
+ In addition, SCI requires specialized hardware.
+ </para>
+
+ <para>
+ It is strongly recommended to use SCI Transporters only for
+ communication between <command>ndbd</command> processes. Note
+ also that using SCI Transporters means that the
+ <command>ndbd</command> processes never sleep. For this reason,
+ SCI Transporters should be used only on machines having at least
+ two CPUs dedicated for use by <command>ndbd</command> processes.
+ There should be at least one CPU per <command>ndbd</command>
+ process, with at least one CPU left in reserve to handle
+ operating system activities.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>node identifiers (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>node identifiers</secondary>
+ </indexterm>
+
+ <para id="ndbparam-sci-nodeids">
+ <literal>NodeId1</literal>, <literal>NodeId2</literal>
+ </para>
+
+ <para>
+ To identify a connection between two nodes it is necessary
+ to provide node identifiers for each of them, as
+ <literal>NodeId1</literal> and <literal>NodeId2</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Host*SciId* parameters</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-host1sciid0">
+ <literal>Host1SciId0</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:host1sciid0-sci"/>
+
+ <para>
+ This identifies the SCI node ID on the first Cluster node
+ (identified by <literal>NodeId1</literal>).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para id="ndbparam-sci-host1sciid1">
+ <literal>Host1SciId1</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:host1sciid1-sci"/>
+
+ <para>
+ It is possible to set up SCI Transporters for failover
+ between two SCI cards which then should use separate
+ networks between the nodes. This identifies the node ID and
+ the second SCI card to be used on the first node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para id="ndbparam-sci-host2sciid0">
+ <literal>Host2SciId0</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:host2sciid0-sci"/>
+
+ <para>
+ This identifies the SCI node ID on the second Cluster node
+ (identified by <literal>NodeId2</literal>).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para id="ndbparam-sci-host2sciid1">
+ <literal>Host2SciId1</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:host2sciid1-sci"/>
+
+ <para>
+ When using two SCI cards to provide failover, this parameter
+ identifies the second SCI card to be used on the second
+ node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SharedBufferSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-sharedbuffersize">
+ <literal>SharedBufferSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:sharedbuffersize-sci"/>
+
+ <para>
+ Each SCI transporter has a shared memory segment used for
+ communication between the two nodes. Setting the size of
+ this segment to the default value of 1MB should be
+ sufficient for most applications. Using a smaller value can
+ lead to problems when performing many parallel inserts; if
+ the shared buffer is too small, this can also result in a
+ crash of the <command>ndbd</command> process.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendLimit</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-sendlimit">
+ <literal>SendLimit</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:sendlimit-sci"/>
+
+ <para>
+ A small buffer in front of the SCI media stores messages
+ before transmitting them over the SCI network. By default,
+ this is set to 8KB. Our benchmarks show that performance is
+ best at 64KB but 16KB reaches within a few percent of this,
+ and there was little if any advantage to increasing it
+ beyond 8KB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendSignalId</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-sendsignalid">
+ <literal>SendSignalId</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:sendsignalid-sci"/>
+
+ <para>
+ To trace a distributed message it is necessary to identify
+ each message uniquely. When this parameter is set to
+ <literal>Y</literal>, message IDs are transported over the
+ network. This feature is disabled by default in production
+ builds, and enabled in <literal>-debug</literal> builds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Checksum (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-checksum">
+ <literal>Checksum</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="4.1:ndb-config-params:checksum-sci"/>
+
+ <para>
+ This parameter is a boolean value, and is disabled by
+ default. When <literal>Checksum</literal> is enabled,
+ checksums are calculated for all messages before they are
+ placed in the send buffer. This feature prevents messages
+ from being corrupted while waiting in the send buffer. It
+ also serves as a check against data being corrupted during
+ transport.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
+ </section>
+
+ <section id="mysql-cluster-config-params-overview">
+
+ <title>Overview of MySQL Cluster Configuration Parameters</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration parameters</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>configuration</primary>
+ <secondary>MySQL Cluster</secondary>
+ </indexterm>
+
+ <remark role="note">
+ [js] Prepared with the assistance of Johan Andersson, Hartmut
+ Holzgraefe, Sergei Kozlov, Jeb Miller, and Bernd Ocklin.
+ </remark>
+
+ <para>
+ The next three sections provide summary tables of MySQL Cluster
+ configuration parameters used in the
+ <filename>config.ini</filename> file to govern the cluster's
+ functioning. Each table lists the parameters for one of the
+ Cluster node process types (<command>ndbd</command>,
+ <command>ndb_mgmd</command>, and <command>mysqld</command>), and
+ includes the parameter's type as well as its default, mimimum, and
+ maximum values as applicable.
+ </para>
+
+ <para>
+ It is also stated what type of restart is required (node restart
+ or system restart) — and whether the restart must be done
+ with <option>--initial</option> — to change the value of a
+ given configuration parameter. This information is provided in
+ each table's <emphasis role="bold">Restart Type</emphasis> column,
+ which contains one of the values shown in this list:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>N</literal>: Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IN</literal>: Initial Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>S</literal>: System Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IS</literal>: Initial System Restart
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ When performing a node restart or an initial node restart, all of
+ the cluster's data nodes must be restarted in turn (also referred
+ to as a <firstterm>rolling restart</firstterm>). It is possible to
+ update cluster configuration parameters marked
+ <literal>N</literal> or <literal>IN</literal> online — that
+ is, without shutting down the cluster — in this fashion. An
+ initial node restart requires restarting each
+ <command>ndbd</command> process with the
+ <option>--initial</option> option.
+ </para>
+
+ <para>
+ A system restart requires a complete shutdown and restart of the
+ entire cluster. An initial system restart requires taking a backup
+ of the cluster, wiping the cluster file system after shutdown, and
+ then restoring from the backup following the restart.
+ </para>
+
+ <para>
+ In any cluster restart, all of the cluster's management servers
+ must be restarted in order for them to read the updated
+ configuration parameter values.
+ </para>
+
+ <important>
+ <para>
+ Values for numeric cluster parameters can generally be increased
+ without any problems, although it is advisable to do so
+ progressively, making such adjustments in relatively small
+ increments. However, decreasing the values of such parameters
+ — particularly those relating to memory usage and disk
+ space — is not to be undertaken lightly, and it is
+ recommended that you do so only following careful planning and
+ testing. In addition, it is the generally the case that
+ parameters relating to memory and disk usage which can be raised
+ using a simple node restart require an initial node restart to
+ be lowered.
+ </para>
+ </important>
+
+ <para>
+ Because some of these parameters can be used for configuring more
+ than one type of cluster node, they may appear in more than one of
+ the tables.
+ </para>
+
+ <note>
+ <para>
+ <literal>4294967039</literal> — which often appears as a
+ maximum value in these tables — is defined in the
+ <literal role="se">NDBCLUSTER</literal> sources as
+ <literal>MAX_INT_RNIL</literal> and is equal to
+ <literal>0xFFFFFEFF</literal>, or
+ <literal>2<superscript>32</superscript> −
+ 2<superscript>8</superscript> − 1</literal>.
+ </para>
+ </note>
+
+ <section id="mysql-cluster-config-params-ndbd">
+
+ <title>MySQL Cluster Data Node Configuration Parameters</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration parameters</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[ndbd] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[ndbd default] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ The following table provides information about parameters used
+ in the <literal>[ndbd]</literal> or <literal>[ndbd
+ default]</literal> sections of a <filename>config.ini</filename>
+ file for configuring MySQL Cluster data nodes. For detailed
+ descriptions and other additional information about each of
+ these parameters, see
+ <xref linkend="mysql-cluster-ndbd-definition"/>.
+ </para>
+
+ <para>
+ <emphasis><emphasis role="bold">Restart Type</emphasis> Column
+ Values</emphasis>
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>N</literal>: Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IN</literal>: Initial Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>S</literal>: System Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IS</literal>: Initial System Restart
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ See <xref linkend="mysql-cluster-config-params-overview"/>, for
+ additional explanations of these abbreviations.
+ </para>
+
+ <table id="mysql-cluster-config-params-ndbd-table">
+ <title>MySQL Cluster Data Node Configuration Parameters</title>
+ <tgroup cols="6">
+ <colspec colwidth="30*"/>
+ <colspec colwidth="5*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="5*"/>
+ <tbody>
+ <row>
+ <entry><emphasis role="bold">Parameter Name</emphasis></entry>
+ <entry><emphasis role="bold">Type/Units</emphasis></entry>
+ <entry><emphasis role="bold">Default Value</emphasis></entry>
+ <entry><emphasis role="bold">Minimum Value</emphasis></entry>
+ <entry><emphasis role="bold">Maximum Value</emphasis></entry>
+ <entry><emphasis role="bold">Restart Type</emphasis></entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-arbitrationtimeout">ArbitrationTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>1000</entry>
+ <entry>10</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupdatabuffersize">BackupDataBufferSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>2M</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupdatadir">BackupDataDir</link></literal></entry>
+ <entry>string</entry>
+ <entry><filename><literal>FileSystemPath</literal>/BACKUP</filename></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backuplogbuffersize">BackupLogBufferSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>2M</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupmemory">BackupMemory</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>4M</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupwritesize">BackupWriteSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>32K</entry>
+ <entry>2K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupmaxwritesize">BackupMaxWriteSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>256K</entry>
+ <entry>2K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-batchsizeperlocalscan">BatchSizePerLocalScan</link></literal></entry>
+ <entry>integer</entry>
+ <entry>64</entry>
+ <entry>1</entry>
+ <entry>992</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-datadir">DataDir</link></literal></entry>
+ <entry>string</entry>
+ <entry><filename>.</filename></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-datamemory">DataMemory</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>80M</entry>
+ <entry>1M</entry>
+ <entry>1024G (subject to available system RAM and size of
+ <literal>IndexMemory</literal>)</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-diskless">Diskless</link></literal></entry>
+ <entry>true|false (<literal>1</literal>|<literal>0</literal>)</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-executeoncomputer">ExecuteOnComputer</link></literal></entry>
+ <entry>integer</entry>
+ <entry/>
+ <entry/>
+ <entry/>
+ <entry/>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-filesystempath">FileSystemPath</link></literal></entry>
+ <entry>string</entry>
+ <entry>value specified for <literal>DataDir</literal></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-heartbeatintervaldbapi">HeartbeatIntervalDbApi</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>1500</entry>
+ <entry>100</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-heartbeatintervaldbdb">HeartbeatIntervalDbDb</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>1500</entry>
+ <entry>10</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-hostname">HostName</link></literal></entry>
+ <entry>string</entry>
+ <entry><literal>localhost</literal></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>S</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-id">Id</link></literal></entry>
+ <entry>integer</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>1</entry>
+ <entry>49</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-indexmemory">IndexMemory</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>18M</entry>
+ <entry>1M</entry>
+ <entry>1024G (subject to available system RAM and size of
+ <literal>DataMemory</literal>)</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-lockpagesinmainmemory">LockPagesInMainMemory</link></literal></entry>
+ <entry>true|false (<literal>1</literal>|<literal>0</literal>)</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelcheckpoint">LogLevelCheckpoint</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelconnection">LogLevelConnection</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelerror">LogLevelError</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelinfo">LogLevelInfo</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelnoderestart">LogLevelNodeRestart</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelshutdown">LogLevelShutdown</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelstartup">LogLevelStartup</link></literal></entry>
+ <entry>integer</entry>
+ <entry>1</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelstatistic">LogLevelStatistic</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-longmessagebuffer">LongMessageBuffer</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>1M</entry>
+ <entry>512K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofattributes">MaxNoOfAttributes</link></literal></entry>
+ <entry>integer</entry>
+ <entry>1000</entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofconcurrentindexoperations">MaxNoOfConcurrentIndexOperations</link></literal></entry>
+ <entry>integer</entry>
+ <entry>8K</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofconcurrentoperations">MaxNoOfConcurrentOperations</link></literal></entry>
+ <entry>integer</entry>
+ <entry>32768</entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofconcurrentscans">MaxNoOfConcurrentScans</link></literal></entry>
+ <entry>integer</entry>
+ <entry>256</entry>
+ <entry>2</entry>
+ <entry>500</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofconcurrenttransactions">MaxNoOfConcurrentTransactions</link></literal></entry>
+ <entry>integer</entry>
+ <entry>4096</entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>S</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooffiredtriggers">MaxNoOfFiredTriggers</link></literal></entry>
+ <entry>integer</entry>
+ <entry>4000</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofindexes">MaxNoOfIndexes</link></literal>
+ (<emphasis>DEPRECATED</emphasis> — use
+ <literal>MaxNoOfOrderedIndexes</literal> or
+ <literal>MaxNoOfUniqueHashIndexes</literal> instead)</entry>
+ <entry>integer</entry>
+ <entry>128</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooflocaloperations">MaxNoOfLocalOperations</link></literal></entry>
+ <entry>integer</entry>
+ <entry><literal>UNDEFINED</literal></entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooflocalscans">MaxNoOfLocalScans</link></literal></entry>
+ <entry>integer</entry>
+ <entry><literal>UNDEFINED</literal> (see
+ <link linkend="ndbparam-ndbd-maxnooflocalscans">description</link>)</entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooforderedindexes">MaxNoOfOrderedIndexes</link></literal></entry>
+ <entry>integer</entry>
+ <entry>128</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofsavedmessages">MaxNoOfSavedMessages</link></literal></entry>
+ <entry>integer</entry>
+ <entry>25</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooftables">MaxNoOfTables</link></literal></entry>
+ <entry>integer</entry>
+ <entry>128</entry>
+ <entry>8</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooftriggers">MaxNoOfTriggers</link></literal></entry>
+ <entry>integer</entry>
+ <entry>768</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofuniquehashindexes">MaxNoOfUniqueHashIndexes</link></literal></entry>
+ <entry>integer</entry>
+ <entry>64</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofdiskpagestodiskafterrestartacc">NoOfDiskPagesToDiskAfterRestartACC</link></literal></entry>
+ <entry>integer (number of 8KB pages per 100 milliseconds)</entry>
+ <entry>20 (= 20 * 80KB = 1.6MB/second)</entry>
+ <entry>1</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofdiskpagestodiskafterrestarttup">NoOfDiskPagesToDiskAfterRestartTUP</link></literal></entry>
+ <entry>integer (number of 8KB pages per 100 milliseconds)</entry>
+ <entry>40 (= 40 * 80KB = 3.2MB/second)</entry>
+ <entry>1</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofdiskpagestodiskduringrestartacc">NoOfDiskPagesToDiskDuringRestartACC</link></literal></entry>
+ <entry>integer (number of 8KB pages per 100 milliseconds)</entry>
+ <entry>20 (= 20 * 80KB = 1.6MB/second)</entry>
+ <entry>1</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofdiskpagestodiskduringrestarttup">NoOfDiskPagesToDiskDuringRestartTUP</link></literal></entry>
+ <entry>integer (number of 8KB pages per 100 milliseconds)</entry>
+ <entry>40 (= 40 * 80KB = 3.2MB/second)</entry>
+ <entry>1</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-nooffragmentlogfiles">NoOfFragmentLogFiles</link></literal></entry>
+ <entry>integer</entry>
+ <entry>8</entry>
+ <entry>1</entry>
+ <entry>4294967039</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofreplicas">NoOfReplicas</link></literal></entry>
+ <entry>integer</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>1</entry>
+ <entry>4 (theoretical); 2 (supported)</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-redobuffer">RedoBuffer</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>8M</entry>
+ <entry>1M</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-restartonerrorinsert">RestartOnErrorInsert</link></literal>
+ (<emphasis>DEBUG BUILDS ONLY</emphasis>)</entry>
+ <entry>true|false (<literal>1</literal>|<literal>0</literal>)</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-serverport">ServerPort</link></literal>
+ (<emphasis>OBSOLETE</emphasis>)</entry>
+ <entry>integer</entry>
+ <entry>1186</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-startfailuretimeout">StartFailureTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-startpartialtimeout">StartPartialTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>30000</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-startpartitionedtimeout">StartPartitionedTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>60000</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-stoponerror">StopOnError</link></literal></entry>
+ <entry>true|false (<literal>1</literal>|<literal>0</literal>)</entry>
+ <entry>1</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweenglobalcheckpoints">TimeBetweenGlobalCheckpoints</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>2000</entry>
+ <entry>10</entry>
+ <entry>32000</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweeninactivetransactionabortcheck">TimeBetweenInactiveTransactionAbortCheck</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>1000</entry>
+ <entry>1000</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweenlocalcheckpoints">TimeBetweenLocalCheckpoints</link></literal></entry>
+ <entry>integer (number of 4-byte words as a base-2 logarithm)</entry>
+ <entry>20 (= <literal>4 * 2<superscript>20</superscript></literal> = 4MB write
+ operations)</entry>
+ <entry>0</entry>
+ <entry>31</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweenwatchdogcheck">TimeBetweenWatchDogCheck</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>4000</entry>
+ <entry>70</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-transactionbuffermemory">TransactionBufferMemory</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>1M</entry>
+ <entry>1K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-transactiondeadlockdetectiontimeout">TransactionDeadlockDetectionTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>1200</entry>
+ <entry>50 (Can actually be set as low as 50, but any value less than 100 is
+ treated as 100.)</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-transactioninactivetimeout">TransactionInactiveTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-undodatabuffer">UndoDataBuffer</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>16M</entry>
+ <entry>1M</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-undoindexbuffer">UndoIndexBuffer</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>2M</entry>
+ <entry>1M</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <note>
+ <para>
+ To add new data nodes to a MySQL Cluster, it is necessary to
+ shut down the cluster completely, update the
+ <filename>config.ini</filename> file, and then restart the
+ cluster (that is, you must perform a system restart). All data
+ node processes must be started with the
+ <option>--initial</option> option.
+ </para>
+
+ <para>
+ We are working to make it possible to add new data node groups
+ to a running cluster online in a future release; however, we
+ do not plan to implement this change in MySQL
+ ¤t-series;.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-config-params-mgm">
+
+ <title>MySQL Cluster Management Node Configuration Parameters</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration parameters</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[ndb_mgmd] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[mgm] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ The following table provides information about parameters used
+ in the <literal>[ndb_mgmd]</literal> or <literal>[mgm]</literal>
+ sections of a <filename>config.ini</filename> file for
+ configuring MySQL Cluster management nodes. For detailed
+ descriptions and other additional information about each of
+ these parameters, see
+ <xref linkend="mysql-cluster-mgm-definition"/>.
+ </para>
+
+ <para>
+ <emphasis><emphasis role="bold">Restart Type</emphasis> Column
+ Values</emphasis>
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>N</literal>: Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IN</literal>: Initial Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>S</literal>: System Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IS</literal>: Initial System Restart
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ See <xref linkend="mysql-cluster-config-params-overview"/>, for
+ additional explanations of these abbreviations.
+ </para>
+
+ <table id="mysql-cluster-config-params-mgm-table">
+ <title>MySQL Cluster Management Node Configuration Parameters</title>
+ <tgroup cols="6">
+ <colspec colwidth="30*"/>
+ <colspec colwidth="5*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="5*"/>
+ <tbody>
+ <row>
+ <entry><emphasis role="bold">Parameter Name</emphasis></entry>
+ <entry><emphasis role="bold">Type/Units</emphasis></entry>
+ <entry><emphasis role="bold">Default Value</emphasis></entry>
+ <entry><emphasis role="bold">Minimum Value</emphasis></entry>
+ <entry><emphasis role="bold">Maximum Value</emphasis></entry>
+ <entry><emphasis role="bold">Restart Type</emphasis></entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-arbitrationdelay">ArbitrationDelay</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-arbitrationrank">ArbitrationRank</link></literal></entry>
+ <entry>integer</entry>
+ <entry>1</entry>
+ <entry>0</entry>
+ <entry>2</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-datadir">DataDir</link></literal></entry>
+ <entry>string</entry>
+ <entry><filename>.</filename> (<command>ndb_mgmd</command> directory)</entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-executeoncomputer">ExecuteOnComputer</link></literal></entry>
+ <entry>integer</entry>
+ <entry/>
+ <entry/>
+ <entry/>
+ <entry/>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-hostname">HostName</link></literal></entry>
+ <entry>string</entry>
+ <entry><literal>localhost</literal></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-id">Id</link></literal></entry>
+ <entry>integer</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>1</entry>
+ <entry>63</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-logdestination">LogDestination</link></literal></entry>
+ <entry><literal>CONSOLE</literal>, <literal>SYSLOG</literal>, or
+ <literal>FILE</literal></entry>
+ <entry><literal>FILE</literal> (see
+ <xref linkend="mysql-cluster-mgm-definition"/>)</entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-portnumber">PortNumber</link></literal></entry>
+ <entry>integer</entry>
+ <entry>1186 (<emphasis>prior to MySQL 4.1.8</emphasis>: 2200)</entry>
+ <entry>1</entry>
+ <entry>65535</entry>
+ <entry>S</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <note>
+ <para>
+ After making changes in a management node's
+ configuration, it is necessary to perform a rolling restart of
+ the cluster in order for the new configuration to take effect.
+ See <xref linkend="mysql-cluster-mgm-definition"/>, for more
+ information.
+ </para>
+
+ <para>
+ To add new management servers to a running MySQL Cluster, it
+ is also necessary perform a rolling restart of all cluster
+ nodes after modifying any existing
+ <filename>config.ini</filename> files. For more information
+ about issues arising when using multiple management nodes, see
+ <xref linkend="mysql-cluster-limitations-multiple-nodes"/>.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-config-params-api">
+
+ <title>MySQL Cluster SQL Node and API Node Configuration Parameters</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration parameters</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[SQL] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[api] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ The following table provides information about parameters used
+ in the <literal>[SQL]</literal> and <literal>[api]</literal>
+ sections of a <filename>config.ini</filename> file for
+ configuring MySQL Cluster SQL nodes and API nodes. For detailed
+ descriptions and other additional information about each of
+ these parameters, see
+ <xref linkend="mysql-cluster-api-definition"/>.
+ </para>
+
+ <note>
+ <para>
+ For a discussion of MySQL server options for MySQL Cluster,
+ see <xref linkend="mysql-cluster-program-options-mysqld"/>;
+ for information about MySQL server system variables relating
+ to MySQL Cluster, see
+ <xref linkend="mysql-cluster-system-variables"/>.
+ </para>
+ </note>
+
+ <para>
+ <emphasis><emphasis role="bold">Restart Type</emphasis> Column
+ Values</emphasis>
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>N</literal>: Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IN</literal>: Initial Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>S</literal>: System Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IS</literal>: Initial System Restart
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ See <xref linkend="mysql-cluster-config-params-overview"/>, for
+ additional explanations of these abbreviations.
+ </para>
+
+ <table id="mysql-cluster-config-params-api-table">
+ <title>MySQL Cluster SQL Node and API Node Configuration Parameters</title>
+ <tgroup cols="6">
+ <colspec colwidth="30*"/>
+ <colspec colwidth="5*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="5*"/>
+ <tbody>
+ <row>
+ <entry><emphasis role="bold">Parameter Name</emphasis></entry>
+ <entry><emphasis role="bold">Type/Units</emphasis></entry>
+ <entry><emphasis role="bold">Default Value</emphasis></entry>
+ <entry><emphasis role="bold">Minimum Value</emphasis></entry>
+ <entry><emphasis role="bold">Maximum Value</emphasis></entry>
+ <entry><emphasis role="bold">Restart Type</emphasis></entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-arbitrationdelay">ArbitrationDelay</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-arbitrationrank">ArbitrationRank</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>2</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-batchbytesize">BatchByteSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>32K</entry>
+ <entry>1K</entry>
+ <entry>1M</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-batchsize">BatchSize</link></literal></entry>
+ <entry>integer</entry>
+ <entry>64</entry>
+ <entry>1</entry>
+ <entry>992</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-executeoncomputer">ExecuteOnComputer</link></literal></entry>
+ <entry>integer</entry>
+ <entry/>
+ <entry/>
+ <entry/>
+ <entry/>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-hostname">HostName</link></literal></entry>
+ <entry>string</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-id">Id</link></literal></entry>
+ <entry>integer</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>1</entry>
+ <entry>63</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-maxscanbatchsize">MaxScanBatchSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>256K</entry>
+ <entry>32K</entry>
+ <entry>16M</entry>
+ <entry>N</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <note>
+ <para>
+ To add new SQL or API nodes to the configuration of a running
+ MySQL Cluster, it is necessary to perform a rolling restart of
+ all cluster nodes after adding new <literal>[mysqld]</literal>
+ or <literal>[api]</literal> sections to the
+ <filename>config.ini</filename> file (or files, if you are
+ using more than one management server). This must be done
+ before the new SQL or API nodes can connect to the cluster.
+ </para>
+
+ <para>
+ It is <emphasis>not</emphasis> necessary to perform any
+ restart of the cluster if new SQL or API nodes can employ
+ previously unused API slots in the cluster configuration to
+ connect to the cluster.
+ </para>
+ </note>
+
+ </section>
+
+ </section>
+
+ <section id="mysql-cluster-config-lcp-params">
+
+ <title>Configuring MySQL Cluster Parameters for Local Checkpoints</title>
+
+ <indexterm>
+ <primary>DataMemory</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>IndexMemory</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskAfterRestartACC</primary>
+ <secondary>calculating</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskAfterRestartTUP</primary>
+ <secondary>calculating</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>NoOfFragmentLogFiles</primary>
+ <secondary>calculating</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>local checkpoints (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <remark role="note">
+ [js] Adapted by Jon Stephens from an item in Mikael Ronström's
+ blog, 2006-07-11.
+ </remark>
+
+ <para>
+ The parameters discussed in
+ <link linkend="mysql-cluster-logging-and-checkpointing">Logging
+ and Checkpointing</link> and in
+ <link linkend="mysql-cluster-data-memory-index-memory-string-memory">Data
+ Memory, Index Memory, and String Memory</link> that are used to
+ configure local checkpoints for a MySQL Cluster do not exist in
+ isolation, but rather are very much interdepedent on each other.
+ In this section, we illustrate how these parameters —
+ including <literal>DataMemory</literal>,
+ <literal>IndexMemory</literal>,
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal>,
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal>, and
+ <literal>NoOfFragmentLogFiles</literal> — relate to one
+ another in a working Cluster.
+ </para>
+
+ <para>
+ In this example, we assume that our application performs the
+ following numbers of types of operations per hour:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ 50000 selects
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 inserts
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 updates
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 deletes
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ We also make the following assumptions about the data used in the
+ application:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ We are working with a single table having 40 columns.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Each column can hold up to 32 bytes of data.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A typical <literal role="stmt">UPDATE</literal> run by the
+ application affects the values of 5 columns.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ No <literal>NULL</literal> values are inserted by the
+ application.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ A good starting point is to determine the amount of time that
+ should elapse between local checkpoints (LCPs). It is worth noting
+ that, in the event of a system restart, it takes 40-60 percent of
+ this interval to execute the REDO log — for example, if the
+ time between LCPs is 5 minutes (300 seconds), then it should take
+ 2 to 3 minutes (120 to 180 seconds) for the REDO log to be read.
+ </para>
+
+ <para>
+ The maximum amount of data per node can be assumed to be the size
+ of the <literal>DataMemory</literal> parameter. In this example,
+ we assume that this is 2 GB. The
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> parameter
+ represents the amount of data to be checkpointed per unit time
+ — however, this parameter is actually expressed as the
+ number of 8K memory pages to be checkpointed per 100 milliseconds.
+ 2 GB per 300 seconds is approximately 6.8 MB per second, or 700 KB
+ per 100 milliseconds, which works out to roughly 85 pages per 100
+ milliseconds.
+ </para>
+
+ <para>
+ Similarly, we can calculate
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal> in terms of
+ the time for local checkpoints and the amount of memory required
+ for indexes — that is, the <literal>IndexMemory</literal>.
+ Assuming that we allow 512 MB for indexes, this works out to
+ approximately 20 8-KB pages per 100 milliseconds for this
+ parameter.
+ </para>
+
+ <para>
+ Next, we need to determine the number of REDO log files required
+ — that is, fragment log files — the corresponding
+ parameter being <literal>NoOfFragmentLogFiles</literal>. We need
+ to make sure that there are sufficient REDO log files for keeping
+ records for at least 3 local checkpoints. In a production setting,
+ there are always uncertainties — for instance, we cannot be
+ sure that disks always operate at top speed or with maximum
+ throughput. For this reason, it is best to err on the side of
+ caution, so we double our requirement and calculate a number of
+ fragment log files which should be enough to keep records covering
+ 6 local checkpoints.
+ </para>
+
+ <para>
+ It is also important to remember that the disk also handles writes
+ to the REDO log and UNDO log, so if you find that the amount of
+ data being written to disk as determined by the values of
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal> and
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> is
+ approaching the amount of disk bandwidth available, you may wish
+ to increase the time between local checkpoints.
+ </para>
+
+ <para>
+ Given 5 minutes (300 seconds) per local checkpoint, this means
+ that we need to support writing log records at maximum speed for 6
+ * 300 = 1800 seconds. The size of a REDO log record is 72 bytes
+ plus 4 bytes per updated column value plus the maximum size of the
+ updated column, and there is one REDO log record for each table
+ record updated in a transaction, on each node where the data
+ reside. Using the numbers of operations set out previously in this
+ section, we derive the following:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ 50000 select operations per hour yields 0 log records (and
+ thus 0 bytes), since <literal role="stmt">SELECT</literal>
+ statements are not recorded in the REDO log.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 <literal role="stmt">DELETE</literal> statements per
+ hour is approximately 5 delete operations per second. (Since
+ we wish to be conservative in our estimate, we round up here
+ and in the following calculations.) No columns are updated by
+ deletes, so these statements consume only 5 operations * 72
+ bytes per operation = 360 bytes per second.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 <literal role="stmt">UPDATE</literal> statements per
+ hour is roughly the same as 5 updates per second. Each update
+ uses 72 bytes, plus 4 bytes per column * 5 columns updated,
+ plus 32 bytes per column * 5 columns — this works out to
+ 72 + 20 + 160 = 252 bytes per operation, and multiplying this
+ by 5 operation per second yields 1260 bytes per second.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 <literal role="stmt">INSERT</literal> statements per
+ hour is equivalent to 5 insert operations per second. Each
+ insert requires REDO log space of 72 bytes, plus 4 bytes per
+ record * 40 columns, plus 32 bytes per column * 40 columns,
+ which is 72 + 160 + 1280 = 1512 bytes per operation. This
+ times 5 operations per second yields 7560 bytes per second.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ So the total number of REDO log bytes being written per second is
+ approximately 0 + 360 + 1260 + 7560 = 9180 bytes. Multiplied by
+ 1800 seconds, this yields 16524000 bytes required for REDO
+ logging, or approximately 15.75 MB. The unit used for
+ <literal>NoOfFragmentLogFiles</literal> represents a set of 4
+ 16-MB log files — that is, 64 MB. Thus, the minimum value
+ (3) for this parameter is sufficient for the scenario envisioned
+ in this example, since 3 times 64 = 192 MB, or about 12 times what
+ is required; the default value of 8 (or 512 MB) is more than ample
+ in this case.
+ </para>
+
+ <para>
+ A copy of each altered table record is kept in the UNDO log. In
+ the scenario discussed above, the UNDO log would not require any
+ more space than what is provided by the default seetings. However,
+ given the size of disks, it is sensible to allocate at least 1 GB
+ for it.
+ </para>
+
+ </section>
+
+</section>
Modified: trunk/refman-4.1/mysql-cluster.xml
===================================================================
--- trunk/refman-4.1/mysql-cluster.xml 2009-07-30 17:01:52 UTC (rev 15883)
+++ trunk/refman-4.1/mysql-cluster.xml 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 694 bytes
@@ -145,7 +145,7 @@
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="mysql-cluster-multi-computer.xml"/>
- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="mysql-cluster-configuration.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dynxml-local-mysql-cluster-configuration.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dynxml-local-mysql-cluster-optvar.xml"/>
Modified: trunk/refman-5.0/Makefile.depends
===================================================================
--- trunk/refman-5.0/mysql-cluster-configuration-core.xml (rev 0)
+++ trunk/refman-5.0/mysql-cluster-configuration-core.xml 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 28, Lines Added: 6530, Lines Deleted: 50; 251949 bytes
@@ -1250,7 +1250,7 @@
metadata/internationalization.idmap \
metadata/introduction.idmap \
metadata/language-structure-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-programs-core.idmap \
metadata/news-5.0-core.idmap \
metadata/news.idmap \
@@ -1670,6 +1670,38 @@
dynxml-local-manual-index-manprepped.xml: $(dynxml_local_manual_index_SOURCES) $(dynxml_local_manual_index_IDMAPS)
dynxml-local-manual-index-remprepped.xml: $(dynxml_local_manual_index_SOURCES) $(dynxml_local_manual_index_IDMAPS)
dynxml-local-manual-index.xml: $(dynxml_local_manual_index_INCLUDES)
+dynxml_local_mysql_cluster_configuration_INCLUDES = \
+ ../../mysqldoc/dynamic-docs/command-optvars/ndb-config-params.xml \
+ ../../mysqldoc/dynamic-docs/metadata-titles.en.xml \
+ ../common/fixedchars.ent \
+ ../common/phrases.ent \
+ ../mysql-monitor-2.0/version.ent \
+ ../mysql-monitor-common/enterprise.ent \
+ ../refman-common/urls.ent \
+ all-entities.ent \
+ mysql-cluster-configuration-core.xml \
+ versions.ent
+dynxml_local_mysql_cluster_configuration_IMAGES =
+dynxml_local_mysql_cluster_configuration_SOURCES = dynxml-local-mysql-cluster-configuration.xml $(dynxml_local_mysql_cluster_configuration_INCLUDES)
+dynxml_local_mysql_cluster_configuration_IDMAPS = \
+ ../refman-common/metadata/bug-reports.idmap \
+ metadata/dba-mysqld-server-core.idmap \
+ metadata/installing-core.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
+ metadata/mysql-cluster-interconnects.idmap \
+ metadata/mysql-cluster-limitations.idmap \
+ metadata/mysql-cluster-management.idmap \
+ metadata/mysql-cluster-optvar-core.idmap \
+ metadata/mysql-cluster-programs-core.idmap
+dynxml-local-mysql-cluster-configuration.validpure: $(dynxml_local_mysql_cluster_configuration_SOURCES)
+dynxml-local-mysql-cluster-configuration.titles: $(dynxml_local_mysql_cluster_configuration_SOURCES)
+dynxml-local-mysql-cluster-configuration.useless: $(dynxml_local_mysql_cluster_configuration_SOURCES)
+dynxml-local-mysql-cluster-configuration.valid: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration.validwarn: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration-prepped.xml: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration-manprepped.xml: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration-remprepped.xml: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration.xml: $(dynxml_local_mysql_cluster_configuration_INCLUDES)
dynxml_local_mysql_cluster_optvar_INCLUDES = \
../../mysqldoc/dynamic-docs/command-optvars/mysqld.xml \
../../mysqldoc/dynamic-docs/metadata-titles.en.xml \
@@ -1685,7 +1717,7 @@
dynxml_local_mysql_cluster_optvar_SOURCES = dynxml-local-mysql-cluster-optvar.xml $(dynxml_local_mysql_cluster_optvar_INCLUDES)
dynxml_local_mysql_cluster_optvar_IDMAPS = \
metadata/dba-mysqld-server-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-optvar-core.idmap \
metadata/mysql-cluster-programs-core.idmap
dynxml-local-mysql-cluster-optvar.validpure: $(dynxml_local_mysql_cluster_optvar_SOURCES)
@@ -1724,7 +1756,7 @@
../ndbapi/metadata/ndb-errors.idmap \
../ndbapi/metadata/ndb-internals.idmap \
../refman-4.1/metadata/mysql-cluster-programs-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-glossary.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-management.idmap \
@@ -1768,7 +1800,7 @@
metadata/information-schema.idmap \
metadata/installing-core.idmap \
metadata/internationalization.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-interconnects.idmap \
metadata/mysql-cluster-management.idmap \
metadata/mysql-cluster-programs-core.idmap \
@@ -2158,7 +2190,7 @@
metadata/installing-core.idmap \
metadata/installing-cs.idmap \
metadata/internationalization.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/programs-admin-util-core.idmap \
metadata/programs-using.idmap \
metadata/replication-notes.idmap \
@@ -2251,7 +2283,7 @@
metadata/information-schema.idmap \
metadata/installing-core.idmap \
metadata/internationalization.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-interconnects.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-management.idmap \
@@ -2559,6 +2591,7 @@
../../mysqldoc/dynamic-docs/command-optvars/mysqlhotcopy.xml \
../../mysqldoc/dynamic-docs/command-optvars/mysqlimport.xml \
../../mysqldoc/dynamic-docs/command-optvars/mysqlshow.xml \
+ ../../mysqldoc/dynamic-docs/command-optvars/ndb-config-params.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_common.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_config.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_error_reporter.xml \
@@ -2975,6 +3008,7 @@
dynxml-local-manual-index-stmt.xml \
dynxml-local-manual-index-sysvar.xml \
dynxml-local-manual-index.xml \
+ dynxml-local-mysql-cluster-configuration.xml \
dynxml-local-mysql-cluster-optvar.xml \
dynxml-local-mysql-cluster-programs.xml \
dynxml-local-news-5.0.xml \
@@ -3028,7 +3062,7 @@
monitor-refman-chapter-aspec.xml.mem-query-analyzer.none.section.xml \
monitor-refman-chapter-aspec.xml.mem-replication.none.section.xml \
monitor-refman-chapter-base.xml \
- mysql-cluster-configuration.xml \
+ mysql-cluster-configuration-core.xml \
mysql-cluster-glossary.xml \
mysql-cluster-interconnects.xml \
mysql-cluster-limitations.xml \
@@ -3316,6 +3350,7 @@
../mysql-monitor-common/metadata/install-agent-core.idmap \
../mysql-monitor-common/metadata/install-unattended-core.idmap \
../mysql-monitor-common/metadata/install-upgrades-core.idmap \
+ ../mysql-monitor-common/metadata/mem-reference-core.idmap \
../ndbapi/metadata/getting-started.idmap \
../ndbapi/metadata/mgm-api.idmap \
../ndbapi/metadata/ndb-errors.idmap \
@@ -3400,7 +3435,7 @@
metadata/internationalization.idmap \
metadata/introduction.idmap \
metadata/language-structure-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-glossary.idmap \
metadata/mysql-cluster-interconnects.idmap \
metadata/mysql-cluster-limitations.idmap \
@@ -3848,34 +3883,18 @@
monitor-refman-chapter-manprepped.xml: $(monitor_refman_chapter_SOURCES) $(monitor_refman_chapter_IDMAPS)
monitor-refman-chapter-remprepped.xml: $(monitor_refman_chapter_SOURCES) $(monitor_refman_chapter_IDMAPS)
-mysql_cluster_configuration_INCLUDES = \
- ../common/fixedchars.ent \
- ../common/phrases.ent \
- ../mysql-monitor-2.0/version.ent \
- ../mysql-monitor-common/enterprise.ent \
- ../refman-common/urls.ent \
- all-entities.ent \
- versions.ent
-mysql_cluster_configuration_IMAGES =
-mysql_cluster_configuration_SOURCES = mysql-cluster-configuration.xml $(mysql_cluster_configuration_INCLUDES)
-mysql_cluster_configuration_IDMAPS = \
- ../refman-common/metadata/bug-reports.idmap \
- metadata/dba-mysqld-server-core.idmap \
- metadata/installing-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
- metadata/mysql-cluster-interconnects.idmap \
- metadata/mysql-cluster-limitations.idmap \
- metadata/mysql-cluster-management.idmap \
- metadata/mysql-cluster-optvar-core.idmap \
- metadata/mysql-cluster-programs-core.idmap
-mysql-cluster-configuration.validpure: $(mysql_cluster_configuration_SOURCES)
-mysql-cluster-configuration.titles: $(mysql_cluster_configuration_SOURCES)
-mysql-cluster-configuration.useless: $(mysql_cluster_configuration_SOURCES)
-mysql-cluster-configuration.valid: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
-mysql-cluster-configuration.validwarn: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
-mysql-cluster-configuration-prepped.xml: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
-mysql-cluster-configuration-manprepped.xml: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
-mysql-cluster-configuration-remprepped.xml: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
+mysql_cluster_configuration_core_INCLUDES =
+mysql_cluster_configuration_core_IMAGES =
+mysql_cluster_configuration_core_SOURCES = mysql-cluster-configuration-core.xml $(mysql_cluster_configuration_core_INCLUDES)
+mysql_cluster_configuration_core_IDMAPS =
+mysql-cluster-configuration-core.validpure: $(mysql_cluster_configuration_core_SOURCES)
+mysql-cluster-configuration-core.titles: $(mysql_cluster_configuration_core_SOURCES)
+mysql-cluster-configuration-core.useless: $(mysql_cluster_configuration_core_SOURCES)
+mysql-cluster-configuration-core.valid: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
+mysql-cluster-configuration-core.validwarn: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
+mysql-cluster-configuration-core-prepped.xml: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
+mysql-cluster-configuration-core-manprepped.xml: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
+mysql-cluster-configuration-core-remprepped.xml: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
mysql_cluster_glossary_INCLUDES = \
../common/fixedchars.ent \
@@ -3889,7 +3908,7 @@
mysql_cluster_glossary_SOURCES = mysql-cluster-glossary.xml $(mysql_cluster_glossary_INCLUDES)
mysql_cluster_glossary_IDMAPS = \
../refman-5.1/metadata/mysql-cluster-disk-data.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-interconnects.idmap \
metadata/mysql-cluster-management.idmap \
metadata/mysql-cluster-overview.idmap \
@@ -3914,7 +3933,7 @@
mysql_cluster_interconnects_IMAGES =
mysql_cluster_interconnects_SOURCES = mysql-cluster-interconnects.xml $(mysql_cluster_interconnects_INCLUDES)
mysql_cluster_interconnects_IDMAPS = \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-interconnects.idmap
mysql-cluster-interconnects.validpure: $(mysql_cluster_interconnects_SOURCES)
mysql-cluster-interconnects.titles: $(mysql_cluster_interconnects_SOURCES)
@@ -3937,7 +3956,7 @@
mysql_cluster_limitations_SOURCES = mysql-cluster-limitations.xml $(mysql_cluster_limitations_INCLUDES)
mysql_cluster_limitations_IDMAPS = \
../refman-common/metadata/bug-reports.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-management.idmap \
metadata/mysql-cluster-upgrade-downgrade.idmap \
@@ -3967,7 +3986,7 @@
../ndbapi/metadata/ndb-errors.idmap \
../ndbapi/metadata/ndb-internals.idmap \
metadata/dba-mysqld-server-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-management.idmap \
metadata/mysql-cluster-optvar-core.idmap \
metadata/mysql-cluster-programs-core.idmap \
@@ -3996,7 +4015,7 @@
mysql_cluster_multi_computer_SOURCES = mysql-cluster-multi-computer.xml $(mysql_cluster_multi_computer_INCLUDES)
mysql_cluster_multi_computer_IDMAPS = \
metadata/installing-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-interconnects.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-management.idmap \
@@ -4045,7 +4064,7 @@
mysql_cluster_overview_IDMAPS = \
../ndbapi/metadata/getting-started.idmap \
../ndbapi/metadata/mgm-api.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-overview.idmap
mysql-cluster-overview.validpure: $(mysql_cluster_overview_SOURCES)
@@ -4111,7 +4130,7 @@
mysql_cluster_security_SOURCES = mysql-cluster-security.xml $(mysql_cluster_security_INCLUDES)
mysql_cluster_security_IDMAPS = \
metadata/dba-security-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-programs-core.idmap \
metadata/mysql-cluster-security.idmap
mysql-cluster-security.validpure: $(mysql_cluster_security_SOURCES)
@@ -4139,7 +4158,7 @@
mysql_cluster_upgrade_downgrade_SOURCES = mysql-cluster-upgrade-downgrade.xml $(mysql_cluster_upgrade_downgrade_INCLUDES)
mysql_cluster_upgrade_downgrade_IDMAPS = \
metadata/installing-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-upgrade-downgrade.idmap
mysql-cluster-upgrade-downgrade.validpure: $(mysql_cluster_upgrade_downgrade_SOURCES)
mysql-cluster-upgrade-downgrade.titles: $(mysql_cluster_upgrade_downgrade_SOURCES)
@@ -4152,6 +4171,7 @@
mysql_cluster_INCLUDES = \
../../mysqldoc/dynamic-docs/command-optvars/mysqld.xml \
+ ../../mysqldoc/dynamic-docs/command-optvars/ndb-config-params.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_common.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_config.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_error_reporter.xml \
@@ -4178,9 +4198,10 @@
../refman-common/images/published/rolling-restarts.png \
../refman-common/urls.ent \
all-entities.ent \
+ dynxml-local-mysql-cluster-configuration.xml \
dynxml-local-mysql-cluster-optvar.xml \
dynxml-local-mysql-cluster-programs.xml \
- mysql-cluster-configuration.xml \
+ mysql-cluster-configuration-core.xml \
mysql-cluster-glossary.xml \
mysql-cluster-interconnects.xml \
mysql-cluster-limitations.xml \
@@ -4218,7 +4239,7 @@
metadata/dba-security-core.idmap \
metadata/faqs.idmap \
metadata/installing-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-glossary.idmap \
metadata/mysql-cluster-interconnects.idmap \
metadata/mysql-cluster-limitations.idmap \
@@ -4394,7 +4415,7 @@
metadata/installing-core.idmap \
metadata/installing-version.idmap \
metadata/internationalization.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-interconnects.idmap \
metadata/mysql-cluster-management.idmap \
metadata/mysql-cluster-programs-core.idmap \
@@ -4650,7 +4671,7 @@
metadata/dba-mysqld-server-core.idmap \
metadata/dba-user-management-core.idmap \
metadata/installing-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-multi-computer.idmap \
metadata/programs-using.idmap \
metadata/sql-syntax-server-administration.idmap
@@ -4709,7 +4730,7 @@
metadata/information-schema.idmap \
metadata/installing-core.idmap \
metadata/internationalization.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-multi-computer.idmap \
metadata/mysql-cluster.idmap \
metadata/optimization.idmap \
Copied: trunk/refman-5.0/mysql-cluster-configuration-core.xml (from rev 15880, trunk/refman-5.0/mysql-cluster-configuration.xml)
===================================================================
--- trunk/refman-5.0/mysql-cluster-configuration-core.xml (rev 0)
+++ trunk/refman-5.0/mysql-cluster-configuration-core.xml 2009-07-30 19:12:22 UTC (rev 15884)
@@ -0,0 +1,6459 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY % all.entities SYSTEM "all-entities.ent">
+ %all.entities;
+]>
+<section id="mysql-cluster-configuration">
+
+ <title>MySQL Cluster Configuration</title>
+
+ <indexterm>
+ <primary>configuring MySQL Cluster</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <remark role="dynamic-dependency-list"/>
+
+ <para>
+ A MySQL server that is part of a MySQL Cluster differs in one chief
+ respect from a normal (nonclustered) MySQL server, in that it
+ employs the <literal role="se">NDBCLUSTER</literal> storage engine.
+ This engine is also referred to simply as
+ <literal role="se">NDB</literal>, and the two forms of the name are
+ synonymous.
+ </para>
+
+ <para>
+ To avoid unnecessary allocation of resources, the server is
+ configured by default with the <literal role="se">NDB</literal>
+ storage engine disabled. To enable <literal role="se">NDB</literal>,
+ you must modify the server's <filename>my.cnf</filename>
+ configuration file, or start the server with the
+ <option role="mysqld">--ndbcluster</option> option.
+ </para>
+
+ <para>
+ For more information about
+ <option role="mysqld">--ndbcluster</option> and other MySQL server
+ options specific to MySQL Cluster, see
+ <xref linkend="mysql-cluster-program-options-mysqld"/>.
+ </para>
+
+ <para>
+ The MySQL server is a part of the cluster, so it also must know how
+ to access an MGM node to obtain the cluster configuration data. The
+ default behavior is to look for the MGM node on
+ <literal>localhost</literal>. However, should you need to specify
+ that its location is elsewhere, this can be done in
+ <filename>my.cnf</filename> or on the MySQL server command line.
+ Before the <literal role="se">NDB</literal> storage engine can be
+ used, at least one MGM node must be operational, as well as any
+ desired data nodes.
+ </para>
+
+ <section id="mysql-cluster-building">
+
+ <title>Building MySQL Cluster from Source Code</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>compiling from source</secondary>
+ </indexterm>
+
+ <para>
+ <literal role="se">NDB</literal>, the Cluster storage engine, is
+ available in binary distributions for Linux, Mac OS X, and
+ Solaris. We are working to make Cluster run on all operating
+ systems supported by MySQL, including Windows.
+ </para>
+
+ <para>
+ If you choose to build from a source tarball or one of the MySQL
+ Cluster public development trees, be sure to use the
+ <option>--with-ndbcluster</option> option when running
+ <command>configure</command>. You can also use the
+ <command>BUILD/compile-pentium-max</command> build script. Note
+ that this script includes OpenSSL, so you must either have or
+ obtain OpenSSL to build successfully, or else modify
+ <command>compile-pentium-max</command> to exclude this
+ requirement. Of course, you can also just follow the standard
+ instructions for compiling your own binaries, and then perform the
+ usual tests and installation procedure. See
+ <xref linkend="installing-source-tree"/>.
+ </para>
+
+ <para>
+ You should also note that <command>compile-pentium-max</command>
+ installs MySQL to the directory
+ <filename>/usr/local/mysql</filename>, placing all MySQL Cluster
+ executables, scripts, databases, and support files in
+ subdirectories under this directory. If this is not what you
+ desire, be sure to modify the script accordingly.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-installing">
+
+ <title>Installing MySQL Cluster Software</title>
+
+ <indexterm>
+ <primary>installing MySQL Cluster</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>installation</secondary>
+ </indexterm>
+
+ <para>
+ In the next few sections, we assume that you are already familiar
+ with installing MySQL, and here we cover only the differences
+ between configuring MySQL Cluster and configuring MySQL without
+ clustering. (See <xref linkend="installing"/>, if you require more
+ information about the latter.)
+ </para>
+
+ <para>
+ You will find Cluster configuration easiest if you have already
+ have all management and data nodes running first; this is likely
+ to be the most time-consuming part of the configuration. Editing
+ the <filename>my.cnf</filename> file is fairly straightforward,
+ and this section will cover only any differences from configuring
+ MySQL without clustering.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-quick">
+
+ <title>Quick Test Setup of MySQL Cluster</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>"quick" configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>starting</secondary>
+ </indexterm>
+
+ <para>
+ To familiarize you with the basics, we will describe the simplest
+ possible configuration for a functional MySQL Cluster. After this,
+ you should be able to design your desired setup from the
+ information provided in the other relevant sections of this
+ chapter.
+ </para>
+
+ <para>
+ First, you need to create a configuration directory such as
+ <filename>/var/lib/mysql-cluster</filename>, by executing the
+ following command as the system <literal>root</literal> user:
+ </para>
+
+<programlisting>
+shell> <userinput>mkdir /var/lib/mysql-cluster</userinput>
+</programlisting>
+
+ <para>
+ In this directory, create a file named
+ <filename>config.ini</filename> that contains the following
+ information. Substitute appropriate values for
+ <literal>HostName</literal> and <literal>DataDir</literal> as
+ necessary for your system.
+ </para>
+
+<programlisting>
+# file "config.ini" - showing minimal setup consisting of 1 data node,
+# 1 management server, and 3 MySQL servers.
+# The empty default sections are not required, and are shown only for
+# the sake of completeness.
+# Data nodes must provide a hostname but MySQL Servers are not required
+# to do so.
+# If you don't know the hostname for your machine, use localhost.
+# The DataDir parameter also has a default value, but it is recommended to
+# set it explicitly.
+# Note: [db], [api], and [mgm] are aliases for [ndbd], [mysqld], and [ndb_mgmd],
+# respectively. [db] is deprecated and should not be used in new installations.
+
+[ndbd default]
+NoOfReplicas= 1
+
+[mysqld default]
+[ndb_mgmd default]
+[tcp default]
+
+[ndb_mgmd]
+HostName= myhost.example.com
+
+[ndbd]
+HostName= myhost.example.com
+DataDir= /var/lib/mysql-cluster
+
+[mysqld]
+[mysqld]
+[mysqld]
+</programlisting>
+
+ <para>
+ You can now start the <command>ndb_mgmd</command> management
+ server. By default, it attempts to read the
+ <filename>config.ini</filename> file in its current working
+ directory, so change location into the directory where the file is
+ located and then invoke <command>ndb_mgmd</command>:
+ </para>
+
+<programlisting>
+shell> <userinput>cd /var/lib/mysql-cluster</userinput>
+shell> <userinput>ndb_mgmd</userinput>
+</programlisting>
+
+ <para>
+ Then start a single data node by running <command>ndbd</command>:
+ </para>
+
+<programlisting>
+shell> <userinput>ndbd</userinput>
+</programlisting>
+
+ <para>
+ For command-line options which can be used when starting
+ <command>ndbd</command>, see
+ <xref linkend="mysql-cluster-program-options-common"/>.
+ </para>
+
+ <para>
+ By default, <command>ndbd</command> looks for the management
+ server at <literal>localhost</literal> on port 1186.
+ </para>
+
+ <note>
+ <para>
+ If you have installed MySQL from a binary tarball, you will need
+ to specify the path of the <command>ndb_mgmd</command> and
+ <command>ndbd</command> servers explicitly. (Normally, these
+ will be found in <filename>/usr/local/mysql/bin</filename>.)
+ </para>
+ </note>
+
+ <para>
+ Finally, change location to the MySQL data directory (usually
+ <filename>/var/lib/mysql</filename> or
+ <filename>/usr/local/mysql/data</filename>), and make sure that
+ the <filename>my.cnf</filename> file contains the option necessary
+ to enable the NDB storage engine:
+ </para>
+
+<programlisting>
+[mysqld]
+ndbcluster
+</programlisting>
+
+ <para>
+ You can now start the MySQL server as usual:
+ </para>
+
+<programlisting>
+shell> <userinput>mysqld_safe --user=mysql &</userinput>
+</programlisting>
+
+ <para>
+ Wait a moment to make sure the MySQL server is running properly.
+ If you see the notice <literal>mysql ended</literal>, check the
+ server's <filename>.err</filename> file to find out what went
+ wrong.
+ </para>
+
+ <para>
+ If all has gone well so far, you now can start using the cluster.
+ Connect to the server and verify that the
+ <literal role="se">NDBCLUSTER</literal> storage engine is enabled:
+ </para>
+
+<programlisting>
+shell> <userinput>mysql</userinput>
+Welcome to the MySQL monitor. Commands end with ; or \g.
+Your MySQL connection id is 1 to server version: ¤t-version;
+
+Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
+
+mysql> <userinput>SHOW ENGINES\G</userinput>
+...
+*************************** 12. row ***************************
+Engine: NDBCLUSTER
+Support: YES
+Comment: Clustered, fault-tolerant, memory-based tables
+*************************** 13. row ***************************
+Engine: NDB
+Support: YES
+Comment: Alias for NDBCLUSTER
+...
+</programlisting>
+
+ <para>
+ The row numbers shown in the preceding example output may be
+ different from those shown on your system, depending upon how your
+ server is configured.
+ </para>
+
+ <para>
+ Try to create an <literal role="se">NDBCLUSTER</literal> table:
+ </para>
+
+<programlisting>
+shell> <userinput>mysql</userinput>
+mysql> <userinput>USE test;</userinput>
+Database changed
+
+mysql> <userinput>CREATE TABLE ctest (i INT) ENGINE=NDBCLUSTER;</userinput>
+Query OK, 0 rows affected (0.09 sec)
+
+mysql> <userinput>SHOW CREATE TABLE ctest \G</userinput>
+*************************** 1. row ***************************
+ Table: ctest
+Create Table: CREATE TABLE `ctest` (
+ `i` int(11) default NULL
+) ENGINE=ndbcluster DEFAULT CHARSET=latin1
+1 row in set (0.00 sec)
+</programlisting>
+
+ <para>
+ To check that your nodes were set up properly, start the
+ management client:
+ </para>
+
+<programlisting>
+shell> <userinput>ndb_mgm</userinput>
+</programlisting>
+
+ <indexterm>
+ <primary>SHOW</primary>
+ <secondary>in MySQL Cluster management client</secondary>
+ </indexterm>
+
+ <para>
+ Use the <command>SHOW</command> command from within the management
+ client to obtain a report on the cluster's status:
+ </para>
+
+<programlisting>
+ndb_mgm> <userinput>SHOW</userinput>
+Cluster Configuration
+---------------------
+[ndbd(NDB)] 1 node(s)
+id=2 @127.0.0.1 (Version: 3.5.3, Nodegroup: 0, Master)
+
+[ndb_mgmd(MGM)] 1 node(s)
+id=1 @127.0.0.1 (Version: 3.5.3)
+
+[mysqld(API)] 3 node(s)
+id=3 @127.0.0.1 (Version: 3.5.3)
+id=4 (not connected, accepting connect from any host)
+id=5 (not connected, accepting connect from any host)
+</programlisting>
+
+ <para>
+ At this point, you have successfully set up a working MySQL
+ Cluster. You can now store data in the cluster by using any table
+ created with <literal>ENGINE=NDBCLUSTER</literal> or its alias
+ <literal>ENGINE=NDB</literal>.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-config-file">
+
+ <title>MySQL Cluster Configuration Files</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration files</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>my.cnf</primary>
+ <secondary>and MySQL Cluster</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>config.ini (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ Configuring MySQL Cluster requires working with two files:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <filename>my.cnf</filename>: Specifies options for all MySQL
+ Cluster executables. This file, with which you should be
+ familiar with from previous work with MySQL, must be
+ accessible by each executable running in the cluster.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>config.ini</filename>: This file, sometimes known as
+ the <firstterm>global configuration file</firstterm>, is read
+ only by the MySQL Cluster management server, which then
+ distributes the information contained therein to all processes
+ participating in the cluster. <filename>config.ini</filename>
+ contains a description of each node involved in the cluster.
+ This includes configuration parameters for data nodes and
+ configuration parameters for connections between all nodes in
+ the cluster. For a quick reference to the sections that can
+ appear in this file, and what sorts of configuration
+ parameters may be placed in each section, see
+ <link linkend="mysql-cluster-config-ini-sections">Sections of
+ the <filename>config.ini</filename> File</link>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ We are continuously making improvements in Cluster configuration
+ and attempting to simplify this process. Although we strive to
+ maintain backward compatibility, there may be times when introduce
+ an incompatible change. In such cases we will try to let Cluster
+ users know in advance if a change is not backward compatible. If
+ you find such a change and we have not documented it, please
+ report it in the MySQL bugs database using the instructions given
+ in <xref linkend="bug-reports"/>.
+ </para>
+
+ <section id="mysql-cluster-config-example">
+
+ <title>MySQL Cluster Configuration — Basic Example</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration (example)</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>my.cnf</primary>
+ <secondary>and MySQL Cluster</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>config.ini (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ To support MySQL Cluster, you will need to update
+ <filename>my.cnf</filename> as shown in the following example.
+ You may also specify these parameters on the command line when
+ invoking the executables.
+ </para>
+
+ <note>
+ <para>
+ The options shown here should not be confused with those that
+ are used in <filename>config.ini</filename> global
+ configuration files. Global configuration options are
+ discussed later in this section.
+ </para>
+ </note>
+
+<programlisting>
+# my.cnf
+# example additions to my.cnf for MySQL Cluster
+# (valid in MySQL ¤t-series;)
+
+# enable ndbcluster storage engine, and provide connectstring for
+# management server host (default port is 1186)
+[mysqld]
+ndbcluster
+ndb-connectstring=ndb_mgmd.mysql.com
+
+
+# provide connectstring for management server host (default port: 1186)
+[ndbd]
+connect-string=ndb_mgmd.mysql.com
+
+# provide connectstring for management server host (default port: 1186)
+[ndb_mgm]
+connect-string=ndb_mgmd.mysql.com
+
+# provide location of cluster configuration file
+[ndb_mgmd]
+config-file=/etc/config.ini
+</programlisting>
+
+ <para>
+ (For more information on connectstrings, see
+ <xref linkend="mysql-cluster-connectstring"/>.)
+ </para>
+
+<programlisting>
+# my.cnf
+# example additions to my.cnf for MySQL Cluster
+# (will work on all versions)
+
+# enable ndbcluster storage engine, and provide connectstring for management
+# server host to the default port 1186
+[mysqld]
+ndbcluster
+ndb-connectstring=ndb_mgmd.mysql.com:1186
+</programlisting>
+
+ <important>
+ <para>
+ Once you have started a <command>mysqld</command> process with
+ the <literal role="se">NDBCLUSTER</literal> and
+ <literal>ndb-connectstring</literal> parameters in the
+ <literal>[mysqld]</literal> in the <filename>my.cnf</filename>
+ file as shown previously, you cannot execute any
+ <literal role="stmt">CREATE TABLE</literal> or
+ <literal role="stmt">ALTER TABLE</literal> statements without
+ having actually started the cluster. Otherwise, these
+ statements will fail with an error. <emphasis>This is by
+ design</emphasis>.
+ </para>
+ </important>
+
+ <para>
+ You may also use a separate <literal>[mysql_cluster]</literal>
+ section in the cluster <filename>my.cnf</filename> file for
+ settings to be read and used by all executables:
+ </para>
+
+<programlisting>
+# cluster-specific settings
+[mysql_cluster]
+ndb-connectstring=ndb_mgmd.mysql.com:1186
+</programlisting>
+
+ <para>
+ For additional <literal role="se">NDB</literal> variables that
+ can be set in the <filename>my.cnf</filename> file, see
+ <xref linkend="mysql-cluster-system-variables"/>.
+ </para>
+
+ <para>
+ The MySQL Cluster global configuration file is named
+ <filename>config.ini</filename> by default. It is read by
+ <command>ndb_mgmd</command> at startup and can be placed
+ anywhere. Its location and name are specified by using
+ <option>--config-file=<replaceable>path_name</replaceable></option>
+ on the <command>ndb_mgmd</command> command line. If the
+ configuration file is not specified, <command>ndb_mgmd</command>
+ by default tries to read a file named
+ <filename>config.ini</filename> located in the current working
+ directory.
+ </para>
+
+ <para>
+ The global configuration file for MySQL Cluster uses INI format,
+ which consists of sections preceded by section headings
+ (surrounded by square brackets), followed by the appropriate
+ parameter names and values. One deviation from the standard INI
+ format is that the parameter name and value can be separated by
+ a colon (<quote><literal>:</literal></quote>) as well as the
+ equals sign (<quote><literal>=</literal></quote>); however, the
+ equals sign is preferred. Another deviation is that sections are
+ not uniquely identified by section name. Instead, unique
+ sections (such as two different nodes of the same type) are
+ identified by a unique ID specified as a parameter within the
+ section.
+ </para>
+
+ <para>
+ Default values are defined for most parameters, and can also be
+ specified in <filename>config.ini</filename>.
+ (<emphasis>Exception</emphasis>: The
+ <literal>NoOfReplicas</literal> configuration parameter has no
+ default value, and must always be specified explicitly in the
+ <literal>[ndbd default]</literal> section.) To create a default
+ value section, simply add the word <literal>default</literal> to
+ the section name. For example, an <literal>[ndbd]</literal>
+ section contains parameters that apply to a particular data
+ node, whereas an <literal>[ndbd default]</literal> section
+ contains parameters that apply to all data nodes. Suppose that
+ all data nodes should use the same data memory size. To
+ configure them all, create an <literal>[ndbd default]</literal>
+ section that contains a <literal>DataMemory</literal> line to
+ specify the data memory size.
+ </para>
+
+ <para>
+ The global configuration file must define the computers and
+ nodes involved in the cluster and on which computers these nodes
+ are located. An example of a simple configuration file for a
+ cluster consisting of one management server, two data nodes and
+ two MySQL servers is shown here:
+ </para>
+
+<programlisting>
+# file "config.ini" - 2 data nodes and 2 SQL nodes
+# This file is placed in the startup directory of ndb_mgmd (the
+# management server)
+# The first MySQL Server can be started from any host. The second
+# can be started only on the host mysqld_5.mysql.com
+
+[ndbd default]
+NoOfReplicas= 2
+DataDir= /var/lib/mysql-cluster
+
+[ndb_mgmd]
+Hostname= ndb_mgmd.mysql.com
+DataDir= /var/lib/mysql-cluster
+
+[ndbd]
+HostName= ndbd_2.mysql.com
+
+[ndbd]
+HostName= ndbd_3.mysql.com
+
+[mysqld]
+[mysqld]
+HostName= mysqld_5.mysql.com
+</programlisting>
+
+ <para>
+ Each node has its own section in the
+ <filename>config.ini</filename> file. For example, this cluster
+ has two data nodes, so the preceding configuration file contains
+ two <literal>[ndbd]</literal> sections defining these nodes.
+ </para>
+
+ <note>
+ <para>
+ Do not place comments on the same line as a section heading in
+ the <filename>config.ini</filename> file; this causes the
+ management server not to start because it cannot parse the
+ configuration file in such cases.
+ </para>
+ </note>
+
+ <para id="mysql-cluster-config-ini-sections">
+ <emphasis role="bold">Sections of the
+ <filename>config.ini</filename> File</emphasis>
+ </para>
+
+ <para>
+ There are six different sections that you can use in the
+ <filename>config.ini</filename> configuration file, as described
+ in the following list:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>[computer]</literal>: Defines cluster hosts. This
+ is not required to configure a viable MySQL Cluster, but be
+ may used as a convenience when setting up a large cluster.
+ See <xref linkend="mysql-cluster-computer-definition"/>, for
+ more information.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[ndbd]</literal>: Defines a cluster data node
+ (<command>ndbd</command> process). See
+ <xref linkend="mysql-cluster-ndbd-definition"/>, for
+ details.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[mysqld]</literal>: Defines the cluster's MySQL
+ server nodes (also called SQL or API nodes). For a
+ discussion of SQL node configuration, see
+ <xref linkend="mysql-cluster-api-definition"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[mgm]</literal> or <literal>[ndb_mgmd]</literal>:
+ Defines a cluster management server (MGM) node. For
+ information concerning the configuration of MGM nodes, see
+ <xref linkend="mysql-cluster-mgm-definition"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[tcp]</literal>: Defines a TCP/IP connection
+ between cluster nodes, with TCP/IP being the default
+ connection protocol. Normally, <literal>[tcp]</literal> or
+ <literal>[tcp default]</literal> sections are not required
+ to set up a MySQL Cluster, as the cluster handles this
+ automatically; however, it may be necessary in some
+ situations to override the defaults provided by the cluster.
+ See <xref linkend="mysql-cluster-tcp-definition"/>, for
+ information about available TCP/IP configuration parameters
+ and how to use them. (You may also find
+ <xref linkend="mysql-cluster-tcp-definition-direct"/> to be
+ of interest in some cases.)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[shm]</literal>: Defines shared-memory connections
+ between nodes. In MySQL ¤t-series;, it is enabled by
+ default, but should still be considered experimental. For a
+ discussion of SHM interconnects, see
+ <xref linkend="mysql-cluster-shm-definition"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[sci]</literal>:Defines <firstterm>Scalable
+ Coherent Interface</firstterm> connections between cluster
+ data nodes. Such connections require software which, while
+ freely available, is not part of the MySQL Cluster
+ distribution, as well as specialised hardware. See
+ <xref linkend="mysql-cluster-sci-definition"/> for detailed
+ information about SCI interconnects.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ You can define <literal>default</literal> values for each
+ section. All Cluster parameter names are case-insensitive, which
+ differs from parameters specified in <filename>my.cnf</filename>
+ or <filename>my.ini</filename> files.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-connectstring">
+
+ <title>The MySQL Cluster Connectstring</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>connectstring</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>connectstring</primary>
+ <see>MySQL Cluster</see>
+ </indexterm>
+
+ <para>
+ With the exception of the MySQL Cluster management server
+ (<command>ndb_mgmd</command>), each node that is part of a MySQL
+ Cluster requires a <firstterm>connectstring</firstterm> that
+ points to the management server's location. This connectstring
+ is used in establishing a connection to the management server as
+ well as in performing other tasks depending on the node's role
+ in the cluster. The syntax for a connectstring is as follows:
+ </para>
+
+<programlisting>
+[nodeid=<replaceable>node_id</replaceable>, ]<replaceable>host-definition</replaceable>[, <replaceable>host-definition</replaceable>[, ...]]
+
+<replaceable>host-definition</replaceable>:
+ <replaceable>host_name</replaceable>[:<replaceable>port_number</replaceable>]
+</programlisting>
+
+ <para>
+ <literal>node_id</literal> is an integer larger than 1 which
+ identifies a node in <filename>config.ini</filename>.
+ <replaceable>host_name</replaceable> is a string representing a
+ valid Internet host name or IP address.
+ <replaceable>port_number</replaceable> is an integer referring
+ to a TCP/IP port number.
+ </para>
+
+<programlisting>
+example 1 (long): "nodeid=2,myhost1:1100,myhost2:1100,192.168.0.3:1200"
+example 2 (short): "myhost1"
+</programlisting>
+
+ <para>
+ <literal>localhost:1186</literal> is used as the default
+ connectstring value if none is provided. If
+ <replaceable>port_num</replaceable> is omitted from the
+ connectstring, the default port is 1186. This port should always
+ be available on the network because it has been assigned by IANA
+ for this purpose (see
+ <ulink url="http://www.iana.org/assignments/port-numbers"/> for
+ details).
+ </para>
+
+ <para>
+ By listing multiple host definitions, it is possible to
+ designate several redundant management servers. A MySQL Cluster
+ data or API node attempts to contact successive management
+ servers on each host in the order specified, until a successful
+ connection has been established.
+ </para>
+
+ <para>
+ There are a number of different ways to specify the
+ connectstring:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Each executable has its own command-line option which
+ enables specifying the management server at startup. (See
+ the documentation for the respective executable.)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ It is also possible to set the connectstring for all nodes
+ in the cluster at once by placing it in a
+ <literal>[mysql_cluster]</literal> section in the management
+ server's <filename>my.cnf</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ For backward compatibility, two other options are available,
+ using the same syntax:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Set the <envar>NDB_CONNECTSTRING</envar> environment
+ variable to contain the connectstring.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Write the connectstring for each executable into a text
+ file named <filename>Ndb.cfg</filename> and place this
+ file in the executable's startup directory.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ <para>
+ However, these are now deprecated and should not be used for
+ new installations.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The recommended method for specifying the connectstring is to
+ set it on the command line or in the <filename>my.cnf</filename>
+ file for each executable.
+ </para>
+
+ <para>
+ The maximum length of a connectstring is 1024 characters.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-computer-definition">
+
+ <title>Defining Computers in a MySQL Cluster</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>defining node hosts</secondary>
+ </indexterm>
+
+ <para>
+ The <literal>[computer]</literal> section has no real
+ significance other than serving as a way to avoid the need of
+ defining host names for each node in the system. All parameters
+ mentioned here are required.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para id="ndbparam-computer-id">
+ <literal>Id</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:id-computer"/>
+
+ <para>
+ This is an integer value, used to refer to the host computer
+ elsewhere in the configuration file. This is not the same as
+ the node ID.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para id="ndbaparam-computer-hostname">
+ <literal>HostName</literal>
+ </para>
+
+ <para>
+ This is the computer's host name or IP address.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
+ <section id="mysql-cluster-mgm-definition">
+
+ <title>Defining a MySQL Cluster Management Server</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>management node</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <para>
+ The <literal>[ndb_mgmd]</literal> section is used to configure
+ the behavior of the management server. <literal>[mgm]</literal>
+ can be used as an alias; the two section names are equivalent.
+ All parameters in the following list are optional and assume
+ their default values if omitted.
+ </para>
+
+ <note>
+ <para>
+ If neither the <literal>ExecuteOnComputer</literal> nor the
+ <literal>HostName</literal> parameter is present, the default
+ value <literal>localhost</literal> will be assumed for both.
+ </para>
+ </note>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>Id</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-id">
+ <literal>Id</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:id-mgm"/>
+
+ <para>
+ Each node in the cluster has a unique identity, which is
+ represented by an integer value in the range 1 to 63
+ inclusive. This ID is used by all internal cluster messages
+ for addressing the node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ExecuteOnComputer</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-executeoncomputer">
+ <literal>ExecuteOnComputer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:executeoncomputer-mgm"/>
+
+ <para>
+ This refers to the <literal>Id</literal> set for one of the
+ computers defined in a <literal>[computer]</literal> section
+ of the <filename>config.ini</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>PortNumber</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-portnumber">
+ <literal>PortNumber</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:portnumber-mgm"/>
+
+ <para>
+ This is the port number on which the management server
+ listens for configuration requests and management commands.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HostName</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-hostname">
+ <literal>HostName</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:hostname-mgm"/>
+
+ <para>
+ Specifying this parameter defines the host name of the
+ computer on which the management node is to reside. To
+ specify a host name other than <literal>localhost</literal>,
+ either this parameter or
+ <literal>ExecuteOnComputer</literal> is required.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogDestination</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-logdestination">
+ <literal>LogDestination</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:logdestination-mgm"/>
+
+ <para>
+ This parameter specifies where to send cluster logging
+ information. There are three options in this regard —
+ <literal>CONSOLE</literal>, <literal>SYSLOG</literal>, and
+ <literal>FILE</literal> — with <literal>FILE</literal>
+ being the default:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>CONSOLE</literal> outputs the log to
+ <literal>stdout</literal>:
+ </para>
+
+<programlisting>
+CONSOLE
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>SYSLOG</literal> sends the log to a
+ <literal>syslog</literal> facility, possible values
+ being one of <literal>auth</literal>,
+ <literal>authpriv</literal>, <literal>cron</literal>,
+ <literal>daemon</literal>, <literal>ftp</literal>,
+ <literal>kern</literal>, <literal>lpr</literal>,
+ <literal>mail</literal>, <literal>news</literal>,
+ <literal>syslog</literal>, <literal>user</literal>,
+ <literal>uucp</literal>, <literal>local0</literal>,
+ <literal>local1</literal>, <literal>local2</literal>,
+ <literal>local3</literal>, <literal>local4</literal>,
+ <literal>local5</literal>, <literal>local6</literal>, or
+ <literal>local7</literal>.
+ </para>
+
+ <note>
+ <para>
+ Not every facility is necessarily supported by every
+ operating system.
+ </para>
+ </note>
+
+<programlisting>
+SYSLOG:facility=syslog
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>FILE</literal> pipes the cluster log output to
+ a regular file on the same machine. The following values
+ can be specified:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>filename</literal>: The name of the log
+ file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>maxsize</literal>: The maximum size (in
+ bytes) to which the file can grow before logging
+ rolls over to a new file. When this occurs, the old
+ log file is renamed by appending
+ <replaceable>.N</replaceable> to the file name,
+ where <replaceable>N</replaceable> is the next
+ number not yet used with this name.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>maxfiles</literal>: The maximum number of
+ log files.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+<programlisting>
+FILE:filename=cluster.log,maxsize=1000000,maxfiles=6
+</programlisting>
+
+ <para>
+ The default value for the <literal>FILE</literal>
+ parameter is
+ <literal>FILE:filename=ndb_<replaceable>node_id</replaceable>_cluster.log,maxsize=1000000,maxfiles=6</literal>,
+ where <replaceable>node_id</replaceable> is the ID of
+ the node.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ It is possible to specify multiple log destinations
+ separated by semicolons as shown here:
+ </para>
+
+<programlisting>
+CONSOLE;SYSLOG:facility=local0;FILE:filename=/var/log/mgmd
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationRank</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-arbitrationrank">
+ <literal>ArbitrationRank</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:arbitrationrank-mgm"/>
+
+ <para>
+ This parameter is used to define which nodes can act as
+ arbitrators. Only management nodes and SQL nodes can be
+ arbitrators. <literal>ArbitrationRank</literal> can take one
+ of the following values:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>0</literal>: The node will never be used as an
+ arbitrator.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>1</literal>: The node has high priority; that
+ is, it will be preferred as an arbitrator over
+ low-priority nodes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>2</literal>: Indicates a low-priority node
+ which be used as an arbitrator only if a node with a
+ higher priority is not available for that purpose.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ Normally, the management server should be configured as an
+ arbitrator by setting its <literal>ArbitrationRank</literal>
+ to 1 (the default value) and that of all SQL nodes to 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationDelay</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-arbitrationdelay">
+ <literal>ArbitrationDelay</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:arbitrationdelay-mgm"/>
+
+ <para>
+ An integer value which causes the management server's
+ responses to arbitration requests to be delayed by that
+ number of milliseconds. By default, this value is 0; it is
+ normally not necessary to change it.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>DataDir</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-datadir">
+ <literal>DataDir</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:datadir-mgm"/>
+
+ <para>
+ This specifies the directory where output files from the
+ management server will be placed. These files include
+ cluster log files, process output files, and the daemon's
+ process ID (PID) file. (For log files, this location can be
+ overridden by setting the <literal>FILE</literal> parameter
+ for <literal>LogDestination</literal> as discussed
+ previously in this section.)
+ </para>
+
+ <para>
+ The default value for this parameter is the directory in
+ which <command>ndb_mgmd</command> is located.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <note>
+ <para>
+ After making changes in a management node's
+ configuration, it is necessary to perform a rolling restart of
+ the cluster in order for the new configuration to take effect.
+ </para>
+
+ <para>
+ To add new management servers to a running MySQL Cluster, it
+ is also necessary to perform a rolling restart of all cluster
+ nodes after modifying any existing
+ <filename>config.ini</filename> files. For more information
+ about issues arising when using multiple management nodes, see
+ <xref linkend="mysql-cluster-limitations-multiple-nodes"/>.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-ndbd-definition">
+
+ <title>Defining MySQL Cluster Data Nodes</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>data node</secondary>
+ </indexterm>
+
+ <para>
+ The <literal>[ndbd]</literal> and <literal>[ndbd
+ default]</literal> sections are used to configure the behavior
+ of the cluster's data nodes.
+ </para>
+
+ <para>
+ There are many parameters which control buffer sizes, pool
+ sizes, timeouts, and so forth. The only mandatory parameters
+ are:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Either <literal>ExecuteOnComputer</literal> or
+ <literal>HostName</literal>, which must be defined in the
+ local <literal>[ndbd]</literal> section.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The parameter <literal>NoOfReplicas</literal>, which must be
+ defined in the<literal>[ndbd default]</literal>section, as
+ it is common to all Cluster data nodes.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ Most data node parameters are set in the <literal>[ndbd
+ default]</literal> section. Only those parameters explicitly
+ stated as being able to set local values are allowed to be
+ changed in the <literal>[ndbd]</literal> section. Where present,
+ <literal>HostName</literal>, <literal>Id</literal> and
+ <literal>ExecuteOnComputer</literal> <emphasis>must</emphasis>
+ be defined in the local <literal>[ndbd]</literal> section, and
+ not in any other section of <filename>config.ini</filename>. In
+ other words, settings for these parameters are specific to one
+ data node.
+ </para>
+
+ <para>
+ For those parameters affecting memory usage or buffer sizes, it
+ is possible to use <literal>K</literal>, <literal>M</literal>,
+ or <literal>G</literal> as a suffix to indicate units of 1024,
+ 1024×1024, or 1024×1024×1024. (For example,
+ <literal>100K</literal> means 100 × 1024 = 102400.)
+ Parameter names and values are currently case-sensitive.
+ </para>
+
+ <formalpara>
+
+ <title>Identifying data nodes</title>
+
+ <para id="mysql-cluster-identifying-data-nodes">
+ The <literal>Id</literal> value (that is, the data node
+ identifier) can be allocated on the command line when the node
+ is started or in the configuration file.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>Id</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-id">
+ <literal>Id</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:id-ndbd"/>
+
+ <para>
+ This is the node ID used as the address of the node for all
+ cluster internal messages. For data nodes, this is an
+ integer in the range 1 to 49 inclusive. Each node in the
+ cluster must have a unique identity.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ExecuteOnComputer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-executeoncomputer">
+ <literal>ExecuteOnComputer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:executeoncomputer-ndbd"/>
+
+ <para>
+ This refers to the <literal>Id</literal> set for one of the
+ computers defined in a <literal>[computer]</literal>
+ section.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HostName</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-hostname">
+ <literal>HostName</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:hostname-ndbd"/>
+
+ <para>
+ Specifying this parameter defines the host name of the
+ computer on which the data node is to reside. To specify a
+ host name other than <literal>localhost</literal>, either
+ this parameter or <literal>ExecuteOnComputer</literal> is
+ required.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ServerPort</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-serverport">
+ <literal>ServerPort</literal>
+ (<emphasis>OBSOLETE</emphasis>)
+ </para>
+
+ <para>
+ Each node in the cluster uses a port to connect to other
+ nodes. This port is used also for non-TCP transporters in
+ the connection setup phase. The default port is allocated
+ dynamically in such a way as to ensure that no two nodes on
+ the same computer receive the same port number, so it should
+ not normally be necessary to specify a value for this
+ parameter.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfReplicas</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofreplicas">
+ <literal>NoOfReplicas</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:noofreplicas-ndbd"/>
+
+ <para>
+ This global parameter can be set only in the <literal>[ndbd
+ default]</literal> section, and defines the number of
+ replicas for each table stored in the cluster. This
+ parameter also specifies the size of node groups. A node
+ group is a set of nodes all storing the same information.
+ </para>
+
+ <para>
+ Node groups are formed implicitly. The first node group is
+ formed by the set of data nodes with the lowest node IDs,
+ the next node group by the set of the next lowest node
+ identities, and so on. By way of example, assume that we
+ have 4 data nodes and that <literal>NoOfReplicas</literal>
+ is set to 2. The four data nodes have node IDs 2, 3, 4 and
+ 5. Then the first node group is formed from nodes 2 and 3,
+ and the second node group by nodes 4 and 5. It is important
+ to configure the cluster in such a manner that nodes in the
+ same node groups are not placed on the same computer because
+ a single hardware failure would cause the entire cluster to
+ fail.
+ </para>
+
+ <para>
+ If no node IDs are provided, the order of the data nodes
+ will be the determining factor for the node group. Whether
+ or not explicit assignments are made, they can be viewed in
+ the output of the management client's
+ <literal role="ndb_mgm_cmd">SHOW</literal> command.
+ </para>
+
+ <para>
+ There is no default value for
+ <literal>NoOfReplicas</literal>; the maximum possible value
+ is 4. Currently, only the values 1 and 2 are actually
+ supported (see Bug#18621).
+ </para>
+
+ <important>
+ <para>
+ Setting <literal>NoOfReplicas</literal> to 1 means that
+ there is only a single copy of all Cluster data; in this
+ case, the loss of a single data node causes the cluster to
+ fail because there are no additional copies of the data
+ stored by that node.
+ </para>
+ </important>
+
+ <para>
+ The value for this parameter must divide evenly into the
+ number of data nodes in the cluster. For example, if there
+ are two data nodes, then <literal>NoOfReplicas</literal>
+ must be equal to either 1 or 2, since 2/3 and 2/4 both yield
+ fractional values; if there are four data nodes, then
+ <literal>NoOfReplicas</literal> must be equal to 1, 2, or 4.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>DataDir</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-datadir">
+ <literal>DataDir</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:datadir-ndbd"/>
+
+ <para>
+ This parameter specifies the directory where trace files,
+ log files, pid files and error logs are placed.
+ </para>
+
+ <para>
+ The default is the data node process working directory.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>FileSystemPath</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-filesystempath">
+ <literal>FileSystemPath</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:filesystempath-ndbd"/>
+
+ <para>
+ This parameter specifies the directory where all files
+ created for metadata, REDO logs, UNDO logs and data files
+ are placed. The default is the directory specified by
+ <literal>DataDir</literal>.
+ </para>
+
+ <note>
+ <para>
+ This directory must exist before the
+ <command>ndbd</command> process is initiated.
+ </para>
+ </note>
+
+ <para>
+ The recommended directory hierarchy for MySQL Cluster
+ includes <filename>/var/lib/mysql-cluster</filename>, under
+ which a directory for the node's file system is created. The
+ name of this subdirectory contains the node ID. For example,
+ if the node ID is 2, this subdirectory is named
+ <filename>ndb_2_fs</filename>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupDataDir</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupdatadir">
+ <literal>BackupDataDir</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:backupdatadir-ndbd"/>
+
+ <para>
+ This parameter specifies the directory in which backups are
+ placed. If omitted, the default backup location is the
+ directory named <filename>BACKUP</filename> under the
+ location specified by the <literal>FileSystemPath</literal>
+ parameter. (See above.)
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para id="mysql-cluster-data-memory-index-memory-string-memory">
+ <emphasis role="bold">Data Memory, Index Memory, and String
+ Memory</emphasis>
+ </para>
+
+ <para>
+ <literal>DataMemory</literal> and <literal>IndexMemory</literal>
+ are <literal>[ndbd]</literal> parameters specifying the size of
+ memory segments used to store the actual records and their
+ indexes. In setting values for these, it is important to
+ understand how <literal>DataMemory</literal> and
+ <literal>IndexMemory</literal> are used, as they usually need to
+ be updated to reflect actual usage by the cluster:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>DataMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-datamemory">
+ <literal>DataMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:datamemory-ndbd"/>
+
+ <para>
+ This parameter defines the amount of space (in bytes)
+ available for storing database records. The entire amount
+ specified by this value is allocated in memory, so it is
+ extremely important that the machine has sufficient physical
+ memory to accommodate it.
+ </para>
+
+ <para>
+ The memory allocated by <literal>DataMemory</literal> is
+ used to store both the actual records and indexes. Each
+ record is currently of fixed size. (Even
+ <literal role="type">VARCHAR</literal> columns are stored as
+ fixed-width columns.) There is a 16-byte overhead on each
+ record; an additional amount for each record is incurred
+ because it is stored in a 32KB page with 128 byte page
+ overhead (see below). There is also a small amount wasted
+ per page due to the fact that each record is stored in only
+ one page.
+ </para>
+
+ <para>
+ The maximum record size is currently 8052 bytes.
+ </para>
+
+ <para>
+ The memory space defined by <literal>DataMemory</literal> is
+ also used to store ordered indexes, which use about 10 bytes
+ per record. Each table row is represented in the ordered
+ index. A common error among users is to assume that all
+ indexes are stored in the memory allocated by
+ <literal>IndexMemory</literal>, but this is not the case:
+ Only primary key and unique hash indexes use this memory;
+ ordered indexes use the memory allocated by
+ <literal>DataMemory</literal>. However, creating a primary
+ key or unique hash index also creates an ordered index on
+ the same keys, unless you specify <literal>USING
+ HASH</literal> in the index creation statement. This can be
+ verified by running <command>ndb_desc -d
+ <replaceable>db_name</replaceable>
+ <replaceable>table_name</replaceable></command> in the
+ management client.
+ </para>
+
+ <para>
+ The memory space allocated by <literal>DataMemory</literal>
+ consists of 32KB pages, which are allocated to table
+ fragments. Each table is normally partitioned into the same
+ number of fragments as there are data nodes in the cluster.
+ Thus, for each node, there are the same number of fragments
+ as are set in <literal>NoOfReplicas</literal>.
+ </para>
+
+ <para>
+ In addition, due to the way in which new pages are allocated
+ when the capacity of the current page is exhausted, there is
+ an additional overhead of approximately 18.75%. When more
+ <literal>DataMemory</literal> is required, more than one new
+ page is allocated, according to the following formula:
+
+<programlisting>
+number of new pages = FLOOR(number of current pages × 0.1875) + 1
+</programlisting>
+
+ For example, if 15 pages are currently allocated to a given
+ table and an insert to this table requires additional
+ storage space, the number of new pages allocated to the
+ table is <literal>FLOOR(15 × 0.1875) + 1 =
+ FLOOR(2.8125) + 1 = 2 + 1 =
+ 3</literal>. Now 15 + 3 = 18 memory pages are
+ allocated to the table. When the last of these 18 pages
+ becomes full, <literal>FLOOR(18 × 0.1875) + 1
+ = FLOOR(3.3750) + 1 = 3 + 1 =
+ 4</literal> new pages are allocated, so the total number of
+ pages allocated to the table is now 22.
+ </para>
+
+ <para>
+ Once a page has been allocated, it is currently not possible
+ to return it to the pool of free pages, except by deleting
+ the table. (This also means that
+ <literal>DataMemory</literal> pages, once allocated to a
+ given table, cannot be used by other tables.) Performing a
+ node recovery also compresses the partition because all
+ records are inserted into empty partitions from other live
+ nodes.
+ </para>
+
+ <para>
+ The <literal>DataMemory</literal> memory space also contains
+ UNDO information: For each update, a copy of the unaltered
+ record is allocated in the <literal>DataMemory</literal>.
+ There is also a reference to each copy in the ordered table
+ indexes. Unique hash indexes are updated only when the
+ unique index columns are updated, in which case a new entry
+ in the index table is inserted and the old entry is deleted
+ upon commit. For this reason, it is also necessary to
+ allocate enough memory to handle the largest transactions
+ performed by applications using the cluster. In any case,
+ performing a few large transactions holds no advantage over
+ using many smaller ones, for the following reasons:
+ </para>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>transactions</secondary>
+ </indexterm>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Large transactions are not any faster than smaller ones
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Large transactions increase the number of operations
+ that are lost and must be repeated in event of
+ transaction failure
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Large transactions use more memory
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The default value for <literal>DataMemory</literal> is 80MB;
+ the minimum is 1MB. There is no maximum size, but in reality
+ the maximum size has to be adapted so that the process does
+ not start swapping when the limit is reached. This limit is
+ determined by the amount of physical RAM available on the
+ machine and by the amount of memory that the operating
+ system may commit to any one process. 32-bit operating
+ systems are generally limited to 2−4GB per process;
+ 64-bit operating systems can use more. For large databases,
+ it may be preferable to use a 64-bit operating system for
+ this reason.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>IndexMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-indexmemory">
+ <literal>IndexMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:indexmemory-ndbd"/>
+
+ <para>
+ This parameter controls the amount of storage used for hash
+ indexes in MySQL Cluster. Hash indexes are always used for
+ primary key indexes, unique indexes, and unique constraints.
+ Note that when defining a primary key and a unique index,
+ two indexes will be created, one of which is a hash index
+ used for all tuple accesses as well as lock handling. It is
+ also used to enforce unique constraints.
+ </para>
+
+ <para>
+ The size of the hash index is 25 bytes per record, plus the
+ size of the primary key. For primary keys larger than 32
+ bytes another 8 bytes is added.
+ </para>
+
+ <para>
+ The default value for <literal>IndexMemory</literal> is
+ 18MB. The minimum is 1MB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StringMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-stringmemory">
+ <literal>StringMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:stringmemory-ndbd"/>
+
+ <para>
+ This parameter determines how much memory is allocated for
+ strings such as table names, and is specified in an
+ <literal>[ndbd]</literal> or <literal>[ndbd
+ default]</literal> section of the
+ <filename>config.ini</filename> file. A value between
+ <literal>0</literal> and <literal>100</literal> inclusive is
+ interpreted as a percent of the maximum default value, which
+ is calculated based on a number of factors including the
+ number of tables, maximum table name size, maximum size of
+ <filename>.FRM</filename> files,
+ <literal>MaxNoOfTriggers</literal>, maximum column name
+ size, and maximum default column value. In general it is
+ safe to assume that the maximum default value is
+ approximately 5 MB for a MySQL Cluster having 1000 tables.
+ </para>
+
+ <para>
+ A value greater than <literal>100</literal> is interpreted
+ as a number of bytes.
+ </para>
+
+ <para>
+ In MySQL ¤t-series;, the default value is
+ <literal>100</literal> — that is, 100 percent of the
+ default maximum, or roughly 5 MB. It is possible to reduce
+ this value safely, but it should never be less than 5
+ percent. If you encounter Error 773 <errortext>Out of string
+ memory, please modify StringMemory config parameter:
+ Permanent error: Schema error</errortext>, this means that
+ means that you have set the <literal>StringMemory</literal>
+ value too low. <literal>25</literal> (25 percent) is not
+ excessive, and should prevent this error from recurring in
+ all but the most extreme conditions, as when there are
+ hundreds or thousands of <literal role="se">NDB</literal>
+ tables with names whose lengths and columns whose number
+ approach their permitted maximums.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The following example illustrates how memory is used for a
+ table. Consider this table definition:
+ </para>
+
+<programlisting>
+CREATE TABLE example (
+ a INT NOT NULL,
+ b INT NOT NULL,
+ c INT NOT NULL,
+ PRIMARY KEY(a),
+ UNIQUE(b)
+) ENGINE=NDBCLUSTER;
+</programlisting>
+
+ <para>
+ For each record, there are 12 bytes of data plus 12 bytes
+ overhead. Having no nullable columns saves 4 bytes of overhead.
+ In addition, we have two ordered indexes on columns
+ <literal>a</literal> and <literal>b</literal> consuming roughly
+ 10 bytes each per record. There is a primary key hash index on
+ the base table using roughly 29 bytes per record. The unique
+ constraint is implemented by a separate table with
+ <literal>b</literal> as primary key and <literal>a</literal> as
+ a column. This other table consumes an additional 29 bytes of
+ index memory per record in the <literal>example</literal> table
+ as well 8 bytes of record data plus 12 bytes of overhead.
+ </para>
+
+ <para>
+ Thus, for one million records, we need 58MB for index memory to
+ handle the hash indexes for the primary key and the unique
+ constraint. We also need 64MB for the records of the base table
+ and the unique index table, plus the two ordered index tables.
+ </para>
+
+ <para>
+ You can see that hash indexes takes up a fair amount of memory
+ space; however, they provide very fast access to the data in
+ return. They are also used in MySQL Cluster to handle uniqueness
+ constraints.
+ </para>
+
+ <para>
+ Currently, the only partitioning algorithm is hashing and
+ ordered indexes are local to each node. Thus, ordered indexes
+ cannot be used to handle uniqueness constraints in the general
+ case.
+ </para>
+
+ <para>
+ An important point for both <literal>IndexMemory</literal> and
+ <literal>DataMemory</literal> is that the total database size is
+ the sum of all data memory and all index memory for each node
+ group. Each node group is used to store replicated information,
+ so if there are four nodes with two replicas, there will be two
+ node groups. Thus, the total data memory available is 2 ×
+ <literal>DataMemory</literal> for each data node.
+ </para>
+
+ <para>
+ It is highly recommended that <literal>DataMemory</literal> and
+ <literal>IndexMemory</literal> be set to the same values for all
+ nodes. Data distribution is even over all nodes in the cluster,
+ so the maximum amount of space available for any node can be no
+ greater than that of the smallest node in the cluster.
+ </para>
+
+ <para>
+ <literal>DataMemory</literal> and <literal>IndexMemory</literal>
+ can be changed, but decreasing either of these can be risky;
+ doing so can easily lead to a node or even an entire MySQL
+ Cluster that is unable to restart due to there being
+ insufficient memory space. Increasing these values should be
+ acceptable, but it is recommended that such upgrades are
+ performed in the same manner as a software upgrade, beginning
+ with an update of the configuration file, and then restarting
+ the management server followed by restarting each data node in
+ turn.
+ </para>
+
+ <para>
+ Updates do not increase the amount of index memory used. Inserts
+ take effect immediately; however, rows are not actually deleted
+ until the transaction is committed.
+ </para>
+
+ <formalpara>
+
+ <title>Transaction parameters</title>
+
+ <para id="mysql-cluster-transaction-parameters">
+ The next three <literal>[ndbd]</literal> parameters that we
+ discuss are important because they affect the number of
+ parallel transactions and the sizes of transactions that can
+ be handled by the system.
+ <literal>MaxNoOfConcurrentTransactions</literal> sets the
+ number of parallel transactions possible in a node.
+ <literal>MaxNoOfConcurrentOperations</literal> sets the number
+ of records that can be in update phase or locked
+ simultaneously.
+ </para>
+
+ </formalpara>
+
+ <para>
+ Both of these parameters (especially
+ <literal>MaxNoOfConcurrentOperations</literal>) are likely
+ targets for users setting specific values and not using the
+ default value. The default value is set for systems using small
+ transactions, to ensure that these do not use excessive memory.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfConcurrentTransactions</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofconcurrenttransactions">
+ <literal>MaxNoOfConcurrentTransactions</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnoofconcurrenttransactions-ndbd"/>
+
+ <para>
+ Each cluster data node requires a transaction record for
+ each active transaction in the cluster. The task of
+ coordinating transactions is distributed among all of the
+ data nodes. The total number of transaction records in the
+ cluster is the number of transactions in any given node
+ times the number of nodes in the cluster.
+ </para>
+
+ <para>
+ Transaction records are allocated to individual MySQL
+ servers. Each connection to a MySQL server requires at least
+ one transaction record, plus an additional transaction
+ object per table accessed by that connection. This means
+ that a reasonable minimum for this parameter is
+
+<programlisting>
+MaxNoOfConcurrentTransactions =
+ (maximum number of tables accessed in any single transaction + 1)
+ * number of cluster SQL nodes
+</programlisting>
+
+ For example, suppose that there are 4 SQL nodes using the
+ cluster. A single join involving 5 tables requires 6
+ transaction records; if there are 5 such joins in a
+ transaction, then 5 * 6 = 30 transaction records are
+ required for this transaction, per MySQL server, or 30 * 4 =
+ 120 transaction records total.
+ </para>
+
+ <para>
+ This parameter must be set to the same value for all cluster
+ data nodes. This is due to the fact that, when a data node
+ fails, the oldest surviving node re-creates the transaction
+ state of all transactions that were ongoing in the failed
+ node.
+ </para>
+
+ <para>
+ Changing the value of
+ <literal>MaxNoOfConcurrentTransactions</literal> requires a
+ complete shutdown and restart of the cluster.
+ </para>
+
+ <para>
+ The default value is 4096.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfConcurrentOperations</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofconcurrentoperations">
+ <literal>MaxNoOfConcurrentOperations</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnoofconcurrentoperations-ndbd"/>
+
+ <para>
+ It is a good idea to adjust the value of this parameter
+ according to the size and number of transactions. When
+ performing transactions of only a few operations each and
+ not involving a great many records, there is no need to set
+ this parameter very high. When performing large transactions
+ involving many records need to set this parameter higher.
+ </para>
+
+ <para>
+ Records are kept for each transaction updating cluster data,
+ both in the transaction coordinator and in the nodes where
+ the actual updates are performed. These records contain
+ state information needed to find UNDO records for rollback,
+ lock queues, and other purposes.
+ </para>
+
+ <para>
+ This parameter should be set to the number of records to be
+ updated simultaneously in transactions, divided by the
+ number of cluster data nodes. For example, in a cluster
+ which has four data nodes and which is expected to handle
+ 1,000,000 concurrent updates using transactions, you should
+ set this value to 1000000 / 4 = 250000.
+ </para>
+
+ <para>
+ Read queries which set locks also cause operation records to
+ be created. Some extra space is allocated within individual
+ nodes to accommodate cases where the distribution is not
+ perfect over the nodes.
+ </para>
+
+ <para>
+ When queries make use of the unique hash index, there are
+ actually two operation records used per record in the
+ transaction. The first record represents the read in the
+ index table and the second handles the operation on the base
+ table.
+ </para>
+
+ <para>
+ The default value is 32768.
+ </para>
+
+ <para>
+ This parameter actually handles two values that can be
+ configured separately. The first of these specifies how many
+ operation records are to be placed with the transaction
+ coordinator. The second part specifies how many operation
+ records are to be local to the database.
+ </para>
+
+ <para>
+ A very large transaction performed on an eight-node cluster
+ requires as many operation records in the transaction
+ coordinator as there are reads, updates, and deletes
+ involved in the transaction. However, the operation records
+ of the are spread over all eight nodes. Thus, if it is
+ necessary to configure the system for one very large
+ transaction, it is a good idea to configure the two parts
+ separately. <literal>MaxNoOfConcurrentOperations</literal>
+ will always be used to calculate the number of operation
+ records in the transaction coordinator portion of the node.
+ </para>
+
+ <para>
+ It is also important to have an idea of the memory
+ requirements for operation records. These consume about 1KB
+ per record.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfLocalOperations</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooflocaloperations">
+ <literal>MaxNoOfLocalOperations</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnooflocaloperations-ndbd"/>
+
+ <para>
+ By default, this parameter is calculated as 1.1 ×
+ <literal>MaxNoOfConcurrentOperations</literal>. This fits
+ systems with many simultaneous transactions, none of them
+ being very large. If there is a need to handle one very
+ large transaction at a time and there are many nodes, it is
+ a good idea to override the default value by explicitly
+ specifying this parameter.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Transaction temporary storage</title>
+
+ <para id="mysql-cluster-transaction-temporary-storage">
+ The next set of <literal>[ndbd]</literal> parameters is used
+ to determine temporary storage when executing a statement that
+ is part of a Cluster transaction. All records are released
+ when the statement is completed and the cluster is waiting for
+ the commit or rollback.
+ </para>
+
+ </formalpara>
+
+ <para>
+ The default values for these parameters are adequate for most
+ situations. However, users with a need to support transactions
+ involving large numbers of rows or operations may need to
+ increase these values to enable better parallelism in the
+ system, whereas users whose applications require relatively
+ small transactions can decrease the values to save memory.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfConcurrentIndexOperations</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofconcurrentindexoperations">
+ <literal>MaxNoOfConcurrentIndexOperations</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnoofconcurrentindexoperations-ndbd"/>
+
+ <para>
+ For queries using a unique hash index, another temporary set
+ of operation records is used during a query's execution
+ phase. This parameter sets the size of that pool of records.
+ Thus, this record is allocated only while executing a part
+ of a query. As soon as this part has been executed, the
+ record is released. The state needed to handle aborts and
+ commits is handled by the normal operation records, where
+ the pool size is set by the parameter
+ <literal>MaxNoOfConcurrentOperations</literal>.
+ </para>
+
+ <para>
+ The default value of this parameter is 8192. Only in rare
+ cases of extremely high parallelism using unique hash
+ indexes should it be necessary to increase this value. Using
+ a smaller value is possible and can save memory if the DBA
+ is certain that a high degree of parallelism is not required
+ for the cluster.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfFiredTriggers</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooffiredtriggers">
+ <literal>MaxNoOfFiredTriggers</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnooffiredtriggers-ndbd"/>
+
+ <para>
+ The default value of <literal>MaxNoOfFiredTriggers</literal>
+ is 4000, which is sufficient for most situations. In some
+ cases it can even be decreased if the DBA feels certain the
+ need for parallelism in the cluster is not high.
+ </para>
+
+ <para>
+ A record is created when an operation is performed that
+ affects a unique hash index. Inserting or deleting a record
+ in a table with unique hash indexes or updating a column
+ that is part of a unique hash index fires an insert or a
+ delete in the index table. The resulting record is used to
+ represent this index table operation while waiting for the
+ original operation that fired it to complete. This operation
+ is short-lived but can still require a large number of
+ records in its pool for situations with many parallel write
+ operations on a base table containing a set of unique hash
+ indexes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TransactionBufferMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-transactionbuffermemory">
+ <literal>TransactionBufferMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:transactionbuffermemory-ndbd"/>
+
+ <para>
+ The memory affected by this parameter is used for tracking
+ operations fired when updating index tables and reading
+ unique indexes. This memory is used to store the key and
+ column information for these operations. It is only very
+ rarely that the value for this parameter needs to be altered
+ from the default.
+ </para>
+
+ <para>
+ The default value for
+ <literal>TransactionBufferMemory</literal> is 1MB.
+ </para>
+
+ <para>
+ Normal read and write operations use a similar buffer, whose
+ usage is even more short-lived. The compile-time parameter
+ <literal>ZATTRBUF_FILESIZE</literal> (found in
+ <filename>ndb/src/kernel/blocks/Dbtc/Dbtc.hpp</filename>)
+ set to 4000 × 128 bytes (500KB). A similar buffer for
+ key information, <literal>ZDATABUF_FILESIZE</literal> (also
+ in <filename>Dbtc.hpp</filename>) contains 4000 × 16 =
+ 62.5KB of buffer space. <literal>Dbtc</literal> is the
+ module that handles transaction coordination.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Scans and buffering</title>
+
+ <para id="mysql-cluster-scans-and-buffering">
+ There are additional <literal>[ndbd]</literal> parameters in
+ the <literal>Dblqh</literal> module (in
+ <filename>ndb/src/kernel/blocks/Dblqh/Dblqh.hpp</filename>)
+ that affect reads and updates. These include
+ <literal>ZATTRINBUF_FILESIZE</literal>, set by default to
+ 10000 × 128 bytes (1250KB) and
+ <literal>ZDATABUF_FILE_SIZE</literal>, set by default to
+ 10000*16 bytes (roughly 156KB) of buffer space. To date, there
+ have been neither any reports from users nor any results from
+ our own extensive tests suggesting that either of these
+ compile-time limits should be increased.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfConcurrentScans</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofconcurrentscans">
+ <literal>MaxNoOfConcurrentScans</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnoofconcurrentscans-ndbd"/>
+
+ <para>
+ This parameter is used to control the number of parallel
+ scans that can be performed in the cluster. Each transaction
+ coordinator can handle the number of parallel scans defined
+ for this parameter. Each scan query is performed by scanning
+ all partitions in parallel. Each partition scan uses a scan
+ record in the node where the partition is located, the
+ number of records being the value of this parameter times
+ the number of nodes. The cluster should be able to sustain
+ <literal>MaxNoOfConcurrentScans</literal> scans concurrently
+ from all nodes in the cluster.
+ </para>
+
+ <para>
+ Scans are actually performed in two cases. The first of
+ these cases occurs when no hash or ordered indexes exists to
+ handle the query, in which case the query is executed by
+ performing a full table scan. The second case is encountered
+ when there is no hash index to support the query but there
+ is an ordered index. Using the ordered index means executing
+ a parallel range scan. The order is kept on the local
+ partitions only, so it is necessary to perform the index
+ scan on all partitions.
+ </para>
+
+ <para>
+ The default value of
+ <literal>MaxNoOfConcurrentScans</literal> is 256. The
+ maximum value is 500.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfLocalScans</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooflocalscans">
+ <literal>MaxNoOfLocalScans</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnooflocalscans-ndbd"/>
+
+ <para>
+ Specifies the number of local scan records if many scans are
+ not fully parallelized. If the number of local scan records
+ is not provided, it is calculated as the product of
+ <literal>MaxNoOfConcurrentScans</literal> and the number of
+ data nodes in the system. The minimum value is 32.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BatchSizePerLocalScan</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-batchsizeperlocalscan">
+ <literal>BatchSizePerLocalScan</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:batchsizeperlocalscan-ndbd"/>
+
+ <para>
+ This parameter is used to calculate the number of lock
+ records used to handle concurrent scan operations.
+ </para>
+
+ <para>
+ The default value is 64; this value has a strong connection
+ to the <literal>ScanBatchSize</literal> defined in the SQL
+ nodes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LongMessageBuffer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-longmessagebuffer">
+ <literal>LongMessageBuffer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:longmessagebuffer-ndbd"/>
+
+ <para>
+ This is an internal buffer used for passing messages within
+ individual nodes and between nodes. Although it is highly
+ unlikely that this would need to be changed, it is
+ configurable. By default, it is set to 1MB.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para id="mysql-cluster-logging-and-checkpointing">
+ <emphasis role="bold">Logging and checkpointing</emphasis>
+ </para>
+
+ <para>
+ The following <literal>[ndbd]</literal> parameters control log
+ and checkpoint behavior.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfFragmentLogFiles</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-nooffragmentlogfiles">
+ <literal>NoOfFragmentLogFiles</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:nooffragmentlogfiles-ndbd"/>
+
+ <para>
+ This parameter sets the number of REDO log files for the
+ node, and thus the amount of space allocated to REDO
+ logging. Because the REDO log files are organized in a ring,
+ it is extremely important that the first and last log files
+ in the set (sometimes referred to as the <quote>head</quote>
+ and <quote>tail</quote> log files, respectively) do not
+ meet. When these approach one another too closely, the node
+ begins aborting all transactions encompassing updates due to
+ a lack of room for new log records.
+ </para>
+
+ <para>
+ A <literal>REDO</literal> log record is not removed until
+ three local checkpoints have been completed since that log
+ record was inserted. Checkpointing frequency is determined
+ by its own set of configuration parameters discussed
+ elsewhere in this chapter.
+ </para>
+
+ <para>
+ How these parameters interact and proposals for how to
+ configure them are discussed in
+ <xref linkend="mysql-cluster-config-lcp-params"/>.
+ </para>
+
+ <para>
+ The default parameter value is 8, which means 8 sets of 4
+ 16MB files for a total of 512MB. In other words, REDO log
+ space is always allocated in blocks of 64MB. In scenarios
+ requiring a great many updates, the value for
+ <literal>NoOfFragmentLogFiles</literal> may need to be set
+ as high as 300 or even higher to provide sufficient space
+ for REDO logs.
+ </para>
+
+ <para>
+ If the checkpointing is slow and there are so many writes to
+ the database that the log files are full and the log tail
+ cannot be cut without jeopardizing recovery, all updating
+ transactions are aborted with internal error code 410
+ (<literal>Out of log file space temporarily</literal>). This
+ condition prevails until a checkpoint has completed and the
+ log tail can be moved forward.
+ </para>
+
+ <important>
+ <para>
+ This parameter cannot be changed <quote>on the
+ fly</quote>; you must restart the node using
+ <option>--initial</option>. If you wish to change this
+ value for all data nodes in a running cluster, you can do
+ so via a rolling node restart (using
+ <option>--initial</option> when starting each data node).
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfOpenFiles</primary>
+ </indexterm>
+
+ <remark role="todo">
+ If this doesn't ever need to be changed, then why is it even
+ mentioned? [js]
+ </remark>
+
+ <para id="ndbparam-ndbd-maxnoofopenfiles">
+ <literal>MaxNoOfOpenFiles</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnoofopenfiles-ndbd"/>
+
+ <para>
+ This parameter sets a ceiling on how many internal threads
+ to allocate for open files. <emphasis>Any situation
+ requiring a change in this parameter should be reported as a
+ bug</emphasis>.
+ </para>
+
+ <para>
+ The default value is 40.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfSavedMessages</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofsavedmessages">
+ <literal>MaxNoOfSavedMessages</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnoofsavedmessages-ndbd"/>
+
+ <para>
+ This parameter sets the maximum number of trace files that
+ are kept before overwriting old ones. Trace files are
+ generated when, for whatever reason, the node crashes.
+ </para>
+
+ <para>
+ The default is 25 trace files.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Metadata objects</title>
+
+ <para id="mysql-cluster-metadata-objects">
+ The next set of <literal>[ndbd]</literal> parameters defines
+ pool sizes for metadata objects, used to define the maximum
+ number of attributes, tables, indexes, and trigger objects
+ used by indexes, events, and replication between clusters.
+ Note that these act merely as <quote>suggestions</quote> to
+ the cluster, and any that are not specified revert to the
+ default values shown.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfAttributes</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofattributes">
+ <literal>MaxNoOfAttributes</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnoofattributes-ndbd"/>
+
+ <para>
+ Defines the number of attributes that can be defined in the
+ cluster.
+ </para>
+
+ <para>
+ The default value is 1000, with the minimum possible value
+ being 32. The maximum is 4294967039. Each attribute consumes
+ around 200 bytes of storage per node due to the fact that
+ all metadata is fully replicated on the servers.
+ </para>
+
+ <para>
+ When setting <literal>MaxNoOfAttributes</literal>, it is
+ important to prepare in advance for any
+ <literal role="stmt">ALTER TABLE</literal> statements that
+ you might want to perform in the future. This is due to the
+ fact, during the execution of <literal role="stmt">ALTER
+ TABLE</literal> on a Cluster table, 3 times the number of
+ attributes as in the original table are used, and a good
+ practice is to allow double this amount. For example, if the
+ MySQL Cluster table having the greatest number of attributes
+ (<replaceable>greatest_number_of_attributes</replaceable>)
+ has 100 attributes, a good starting point for the value of
+ <literal>MaxNoOfAttributes</literal> would be <literal>6 *
+ <replaceable>greatest_number_of_attributes</replaceable> =
+ 600</literal>.
+ </para>
+
+ <para>
+ You should also estimate the average number of attributes
+ per table and multiply this by the total number of MySQL
+ Cluster tables. If this value is larger than the value
+ obtained in the previous paragraph, you should use the
+ larger value instead.
+ </para>
+
+ <para>
+ Assuming that you can create all desired tables without any
+ problems, you should also verify that this number is
+ sufficient by trying an actual <literal role="stmt">ALTER
+ TABLE</literal> after configuring the parameter. If this is
+ not successful, increase
+ <literal>MaxNoOfAttributes</literal> by another multiple of
+ <literal>MaxNoOfTables</literal> and test it again.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfTables</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooftables">
+ <literal>MaxNoOfTables</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnooftables-ndbd"/>
+
+ <para>
+ A table object is allocated for each table, unique hash
+ index, and ordered index. This parameter sets the maximum
+ number of table objects for the cluster as a whole.
+ </para>
+
+ <para>
+ For each attribute that has a
+ <literal role="type">BLOB</literal> data type an extra table
+ is used to store most of the
+ <literal role="type">BLOB</literal> data. These tables also
+ must be taken into account when defining the total number of
+ tables.
+ </para>
+
+ <para>
+ The default value of this parameter is 128. The minimum is 8
+ and the maximum is 1600. Each table object consumes
+ approximately 20KB per node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfOrderedIndexes</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooforderedindexes">
+ <literal>MaxNoOfOrderedIndexes</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnooforderedindexes-ndbd"/>
+
+ <para>
+ For each ordered index in the cluster, an object is
+ allocated describing what is being indexed and its storage
+ segments. By default, each index so defined also defines an
+ ordered index. Each unique index and primary key has both an
+ ordered index and a hash index.
+ <literal>MaxNoOfOrderedIndexes</literal> sets the total
+ number of hash indexes that can be in use in the system at
+ any one time.
+ </para>
+
+ <para>
+ The default value of this parameter is 128. Each hash index
+ object consumes approximately 10KB of data per node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfUniqueHashIndexes</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofuniquehashindexes">
+ <literal>MaxNoOfUniqueHashIndexes</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnoofuniquehashindexes-ndbd"/>
+
+ <para>
+ For each unique index that is not a primary key, a special
+ table is allocated that maps the unique key to the primary
+ key of the indexed table. By default, an ordered index is
+ also defined for each unique index. To prevent this, you
+ must specify the <literal>USING HASH</literal> option when
+ defining the unique index.
+ </para>
+
+ <para>
+ The default value is 64. Each index consumes approximately
+ 15KB per node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfTriggers</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooftriggers">
+ <literal>MaxNoOfTriggers</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnooftriggers-ndbd"/>
+
+ <para>
+ Internal update, insert, and delete triggers are allocated
+ for each unique hash index. (This means that three triggers
+ are created for each unique hash index.) However, an
+ <emphasis>ordered</emphasis> index requires only a single
+ trigger object. Backups also use three trigger objects for
+ each normal table in the cluster.
+ </para>
+
+ <para>
+ This parameter sets the maximum number of trigger objects in
+ the cluster.
+ </para>
+
+ <para>
+ The default value is 768.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfIndexes</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofindexes">
+ <literal>MaxNoOfIndexes</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxnoofindexes-ndbd"/>
+
+ <para>
+ This parameter is deprecated in MySQL ¤t-series;; you
+ should use <literal>MaxNoOfOrderedIndexes</literal> and
+ <literal>MaxNoOfUniqueHashIndexes</literal> instead.
+ </para>
+
+ <para>
+ This parameter is used only by unique hash indexes. There
+ needs to be one record in this pool for each unique hash
+ index defined in the cluster.
+ </para>
+
+ <para>
+ The default value of this parameter is 128.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Boolean parameters</title>
+
+ <para id="mysql-cluster-boolean-parameters">
+ The behavior of data nodes is also affected by a set of
+ <literal>[ndbd]</literal> parameters taking on boolean values.
+ These parameters can each be specified as
+ <literal>TRUE</literal> by setting them equal to
+ <literal>1</literal> or <literal>Y</literal>, and as
+ <literal>FALSE</literal> by setting them equal to
+ <literal>0</literal> or <literal>N</literal>.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>LockPagesInMainMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-lockpagesinmainmemory">
+ <literal>LockPagesInMainMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:lockpagesinmainmemory-ndbd"/>
+
+ <para>
+ For a number of operating systems, including Solaris and
+ Linux, it is possible to lock a process into memory and so
+ avoid any swapping to disk. This can be used to help
+ guarantee the cluster's real-time characteristics.
+ </para>
+
+ <para>
+ Beginning with MySQL 5.0.36, this parameter takes one of the
+ integer values <literal>0</literal>, <literal>1</literal>,
+ or <literal>2</literal>, which act as follows:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>0</literal>: Disables locking. This is the
+ default value.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>1</literal>: Performs the lock after allocating
+ memory for the process.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>2</literal>: Performs the lock before memory
+ for the process is allocated.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ Previously, this parameter was a Boolean.
+ <literal>0</literal> or <literal>false</literal> was the
+ default setting, and disabled locking. <literal>1</literal>
+ or <literal>true</literal> enabled locking of the process
+ after its memory was allocated.
+
+ <important>
+ <para>
+ Beginning with MySQL 5.0.36, it is no longer possible to
+ use <literal>true</literal> or <literal>false</literal>
+ for the value of this parameter; when upgrading from a
+ previous version, you must change the value to
+ <literal>0</literal>, <literal>1</literal>, or
+ <literal>2</literal>.
+ </para>
+ </important>
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StopOnError</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-stoponerror">
+ <literal>StopOnError</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:stoponerror-ndbd"/>
+
+ <para>
+ This parameter specifies whether an <command>ndbd</command>
+ process should exit or perform an automatic restart when an
+ error condition is encountered.
+ </para>
+
+ <para>
+ This feature is enabled by default.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Diskless</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-diskless">
+ <literal>Diskless</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:diskless-ndbd"/>
+
+ <para>
+ It is possible to specify MySQL Cluster tables as
+ <firstterm>diskless</firstterm>, meaning that tables are not
+ checkpointed to disk and that no logging occurs. Such tables
+ exist only in main memory. A consequence of using diskless
+ tables is that neither the tables nor the records in those
+ tables survive a crash. However, when operating in diskless
+ mode, it is possible to run <command>ndbd</command> on a
+ diskless computer.
+ </para>
+
+ <important>
+ <para>
+ This feature causes the <emphasis>entire</emphasis>
+ cluster to operate in diskless mode.
+ </para>
+ </important>
+
+ <para>
+ When this feature is enabled, Cluster online backup is
+ disabled. In addition, a partial start of the cluster is not
+ possible.
+ </para>
+
+ <para>
+ <literal>Diskless</literal> is disabled by default.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>RestartOnErrorInsert</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-restartonerrorinsert">
+ <literal>RestartOnErrorInsert</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:restartonerrorinsert-ndbd"/>
+
+ <para>
+ This feature is accessible only when building the debug
+ version where it is possible to insert errors in the
+ execution of individual blocks of code as part of testing.
+ </para>
+
+ <para>
+ This feature is disabled by default.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para id="mysql-cluster-timeouts-intervals-disk-paging">
+ <emphasis role="bold">Controlling Timeouts, Intervals, and Disk
+ Paging</emphasis>
+ </para>
+
+ <para>
+ There are a number of <literal>[ndbd]</literal> parameters
+ specifying timeouts and intervals between various actions in
+ Cluster data nodes. Most of the timeout values are specified in
+ milliseconds. Any exceptions to this are mentioned where
+ applicable.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenWatchDogCheck</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweenwatchdogcheck">
+ <literal>TimeBetweenWatchDogCheck</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:timebetweenwatchdogcheck-ndbd"/>
+
+ <para>
+ To prevent the main thread from getting stuck in an endless
+ loop at some point, a <quote>watchdog</quote> thread checks
+ the main thread. This parameter specifies the number of
+ milliseconds between checks. If the process remains in the
+ same state after three checks, the watchdog thread
+ terminates it.
+ </para>
+
+ <para>
+ This parameter can easily be changed for purposes of
+ experimentation or to adapt to local conditions. It can be
+ specified on a per-node basis although there seems to be
+ little reason for doing so.
+ </para>
+
+ <para>
+ The default timeout is 4000 milliseconds (4 seconds).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StartPartialTimeout</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-startpartialtimeout">
+ <literal>StartPartialTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:startpartialtimeout-ndbd"/>
+
+ <para>
+ This parameter specifies how long the Cluster waits for all
+ data nodes to come up before the cluster initialization
+ routine is invoked. This timeout is used to avoid a partial
+ Cluster startup whenever possible.
+ </para>
+
+ <para>
+ The default value is 30000 milliseconds (30 seconds). 0
+ disables the timeout, in which case the cluster may start
+ only if all nodes are available.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StartPartitionedTimeout</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-startpartitionedtimeout">
+ <literal>StartPartitionedTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:startpartitionedtimeout-ndbd"/>
+
+ <para>
+ If the cluster is ready to start after waiting for
+ <literal>StartPartialTimeout</literal> milliseconds but is
+ still possibly in a partitioned state, the cluster waits
+ until this timeout has also passed.
+ </para>
+
+ <para>
+ The default timeout is 60000 milliseconds (60 seconds).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StartFailureTimeout</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-startfailuretimeout">
+ <literal>StartFailureTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:startfailuretimeout-ndbd"/>
+
+ <para>
+ If a data node has not completed its startup sequence within
+ the time specified by this parameter, the node startup
+ fails. Setting this parameter to 0 (the default value) means
+ that no data node timeout is applied.
+ </para>
+
+ <para>
+ For nonzero values, this parameter is measured in
+ milliseconds. For data nodes containing extremely large
+ amounts of data, this parameter should be increased. For
+ example, in the case of a data node containing several
+ gigabytes of data, a period as long as 10−15 minutes
+ (that is, 600000 to 1000000 milliseconds) might be required
+ to perform a node restart.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HeartbeatIntervalDbDb</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-heartbeatintervaldbdb">
+ <literal>HeartbeatIntervalDbDb</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:heartbeatintervaldbdb-ndbd"/>
+
+ <para>
+ One of the primary methods of discovering failed nodes is by
+ the use of heartbeats. This parameter states how often
+ heartbeat signals are sent and how often to expect to
+ receive them. After missing three heartbeat intervals in a
+ row, the node is declared dead. Thus, the maximum time for
+ discovering a failure through the heartbeat mechanism is
+ four times the heartbeat interval.
+ </para>
+
+ <para>
+ The default heartbeat interval is 1500 milliseconds (1.5
+ seconds). This parameter must not be changed drastically and
+ should not vary widely between nodes. If one node uses 5000
+ milliseconds and the node watching it uses 1000
+ milliseconds, obviously the node will be declared dead very
+ quickly. This parameter can be changed during an online
+ software upgrade, but only in small increments.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HeartbeatIntervalDbApi</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-heartbeatintervaldbapi">
+ <literal>HeartbeatIntervalDbApi</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:heartbeatintervaldbapi-ndbd"/>
+
+ <para>
+ Each data node sends heartbeat signals to each MySQL server
+ (SQL node) to ensure that it remains in contact. If a MySQL
+ server fails to send a heartbeat in time it is declared
+ <quote>dead,</quote> in which case all ongoing transactions
+ are completed and all resources released. The SQL node
+ cannot reconnect until all activities initiated by the
+ previous MySQL instance have been completed. The
+ three-heartbeat criteria for this determination are the same
+ as described for <literal>HeartbeatIntervalDbDb</literal>.
+ </para>
+
+ <para>
+ The default interval is 1500 milliseconds (1.5 seconds).
+ This interval can vary between individual data nodes because
+ each data node watches the MySQL servers connected to it,
+ independently of all other data nodes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenLocalCheckpoints</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweenlocalcheckpoints">
+ <literal>TimeBetweenLocalCheckpoints</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:timebetweenlocalcheckpoints-ndbd"/>
+
+ <para>
+ This parameter is an exception in that it does not specify a
+ time to wait before starting a new local checkpoint; rather,
+ it is used to ensure that local checkpoints are not
+ performed in a cluster where relatively few updates are
+ taking place. In most clusters with high update rates, it is
+ likely that a new local checkpoint is started immediately
+ after the previous one has been completed.
+ </para>
+
+ <para>
+ The size of all write operations executed since the start of
+ the previous local checkpoints is added. This parameter is
+ also exceptional in that it is specified as the base-2
+ logarithm of the number of 4-byte words, so that the default
+ value 20 means 4MB (4 ×
+ 2<superscript>20</superscript>) of write operations, 21
+ would mean 8MB, and so on up to a maximum value of 31, which
+ equates to 8GB of write operations.
+ </para>
+
+ <para>
+ All the write operations in the cluster are added together.
+ Setting <literal>TimeBetweenLocalCheckpoints</literal> to 6
+ or less means that local checkpoints will be executed
+ continuously without pause, independent of the cluster's
+ workload.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenGlobalCheckpoints</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweenglobalcheckpoints">
+ <literal>TimeBetweenGlobalCheckpoints</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:timebetweenglobalcheckpoints-ndbd"/>
+
+ <para>
+ When a transaction is committed, it is committed in main
+ memory in all nodes on which the data is mirrored. However,
+ transaction log records are not flushed to disk as part of
+ the commit. The reasoning behind this behavior is that
+ having the transaction safely committed on at least two
+ autonomous host machines should meet reasonable standards
+ for durability.
+ </para>
+
+ <para>
+ It is also important to ensure that even the worst of cases
+ — a complete crash of the cluster — is handled
+ properly. To guarantee that this happens, all transactions
+ taking place within a given interval are put into a global
+ checkpoint, which can be thought of as a set of committed
+ transactions that has been flushed to disk. In other words,
+ as part of the commit process, a transaction is placed in a
+ global checkpoint group. Later, this group's log records are
+ flushed to disk, and then the entire group of transactions
+ is safely committed to disk on all computers in the cluster.
+ </para>
+
+ <para>
+ This parameter defines the interval between global
+ checkpoints. The default is 2000 milliseconds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenInactiveTransactionAbortCheck</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweeninactivetransactionabortcheck">
+ <literal>TimeBetweenInactiveTransactionAbortCheck</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:timebetweeninactivetransactionabortcheck-ndbd"/>
+
+ <para>
+ Timeout handling is performed by checking a timer on each
+ transaction once for every interval specified by this
+ parameter. Thus, if this parameter is set to 1000
+ milliseconds, every transaction will be checked for timing
+ out once per second.
+ </para>
+
+ <para>
+ The default value is 1000 milliseconds (1 second).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TransactionInactiveTimeout (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-transactioninactivetimeout">
+ <literal>TransactionInactiveTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:transactioninactivetimeout-ndbd"/>
+
+ <para>
+ This parameter states the maximum time that is permitted to
+ lapse between operations in the same transaction before the
+ transaction is aborted.
+ </para>
+
+ <para>
+ The default for this parameter is zero (no timeout). For a
+ real-time database that needs to ensure that no transaction
+ keeps locks for too long, this parameter should be set to a
+ relatively small value. The unit is milliseconds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TransactionDeadlockDetectionTimeout</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-transactiondeadlockdetectiontimeout">
+ <literal>TransactionDeadlockDetectionTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:transactiondeadlockdetectiontimeout-ndbd"/>
+
+ <para>
+ When a node executes a query involving a transaction, the
+ node waits for the other nodes in the cluster to respond
+ before continuing. A failure to respond can occur for any of
+ the following reasons:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The node is <quote>dead</quote>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The operation has entered a lock queue
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The node requested to perform the action could be
+ heavily overloaded.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ This timeout parameter states how long the transaction
+ coordinator waits for query execution by another node before
+ aborting the transaction, and is important for both node
+ failure handling and deadlock detection. In MySQL 5.0.20 and
+ earlier versions, setting it too high could cause
+ undesirable behavior in situations involving deadlocks and
+ node failure. Beginning with MySQL 5.0.21, active
+ transactions occurring during node failures are actively
+ aborted by the MySQL Cluster Transaction Coordinator, and so
+ high settings are no longer an issue with this parameter.
+ </para>
+
+ <para>
+ The default timeout value is 1200 milliseconds (1.2
+ seconds). The effective minimum value is 100 milliseconds;
+ it is possible to set it as low as 50 milliseconds, but any
+ such value is treated as 100 ms. (Bug#44099)
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskAfterRestartTUP</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofdiskpagestodiskafterrestarttup">
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:noofdiskpagestodiskafterrestarttup-ndbd"/>
+
+ <para>
+ When executing a local checkpoint, the algorithm flushes all
+ data pages to disk. Merely doing so as quickly as possible
+ without any moderation is likely to impose excessive loads
+ on processors, networks, and disks. To control the write
+ speed, this parameter specifies how many pages per 100
+ milliseconds are to be written. In this context, a
+ <quote>page</quote> is defined as 8KB. This parameter is
+ specified in units of 80KB per second, so setting
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> to a
+ value of <literal>20</literal> entails writing 1.6MB in data
+ pages to disk each second during a local checkpoint. This
+ value includes the writing of UNDO log records for data
+ pages. That is, this parameter handles the limitation of
+ writes from data memory. UNDO log records for index pages
+ are handled by the parameter
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal>. (See
+ the entry for <literal>IndexMemory</literal> for information
+ about index pages.)
+ </para>
+
+ <para>
+ In short, this parameter specifies how quickly to execute
+ local checkpoints. It operates in conjunction with
+ <literal>NoOfFragmentLogFiles</literal>,
+ <literal>DataMemory</literal>, and
+ <literal>IndexMemory</literal>.
+ </para>
+
+ <para>
+ For more information about the interaction between these
+ parameters and possible strategies for choosing appropriate
+ values for them, see
+ <xref linkend="mysql-cluster-config-lcp-params"/>.
+ </para>
+
+ <para>
+ The default value is 40 (3.2MB of data pages per second).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskAfterRestartACC</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofdiskpagestodiskafterrestartacc">
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:noofdiskpagestodiskafterrestartacc-ndbd"/>
+
+ <para>
+ This parameter uses the same units as
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> and
+ acts in a similar fashion, but limits the speed of writing
+ index pages from index memory.
+ </para>
+
+ <para>
+ The default value of this parameter is 20 (1.6MB of index
+ memory pages per second).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskDuringRestartTUP</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofdiskpagestodiskduringrestarttup">
+ <literal>NoOfDiskPagesToDiskDuringRestartTUP</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:noofdiskpagestodiskduringrestarttup-ndbd"/>
+
+ <para>
+ This parameter is used in a fashion similar to
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> and
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal>, only
+ it does so with regard to local checkpoints executed in the
+ node when a node is restarting. A local checkpoint is always
+ performed as part of all node restarts. During a node
+ restart it is possible to write to disk at a higher speed
+ than at other times, because fewer activities are being
+ performed in the node.
+ </para>
+
+ <para>
+ This parameter covers pages written from data memory.
+ </para>
+
+ <para>
+ The default value is 40 (3.2MB per second).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskDuringRestartACC</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofdiskpagestodiskduringrestartacc">
+ <literal>NoOfDiskPagesToDiskDuringRestartACC</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:noofdiskpagestodiskduringrestartacc-ndbd"/>
+
+ <para>
+ Controls the number of index memory pages that can be
+ written to disk during the local checkpoint phase of a node
+ restart.
+ </para>
+
+ <para>
+ As with
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> and
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal>,
+ values for this parameter are expressed in terms of 8KB
+ pages written per 100 milliseconds (80KB/second).
+ </para>
+
+ <para>
+ The default value is 20 (1.6MB per second).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationTimeout</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-arbitrationtimeout">
+ <literal>ArbitrationTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:arbitrationtimeout-ndbd"/>
+
+ <para>
+ This parameter specifies how long data nodes wait for a
+ response from the arbitrator to an arbitration message. If
+ this is exceeded, the network is assumed to have split.
+ </para>
+
+ <para>
+ The default value is 1000 milliseconds (1 second).
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Buffering and logging</title>
+
+ <para id="mysql-cluster-buffering-and-logging">
+ Several <literal>[ndbd]</literal> configuration parameters
+ corresponding to former compile-time parameters were
+ introduced in MySQL 4.1.5. These enable the advanced user to
+ have more control over the resources used by node processes
+ and to adjust various buffer sizes at need.
+ </para>
+
+ </formalpara>
+
+ <para>
+ These buffers are used as front ends to the file system when
+ writing log records to disk. If the node is running in diskless
+ mode, these parameters can be set to their minimum values
+ without penalty due to the fact that disk writes are
+ <quote>faked</quote> by the <literal role="se">NDB</literal>
+ storage engine's file system abstraction layer.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>UndoIndexBuffer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-undoindexbuffer">
+ <literal>UndoIndexBuffer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:undoindexbuffer-ndbd"/>
+
+ <para>
+ The UNDO index buffer, whose size is set by this parameter,
+ is used during local checkpoints. The
+ <literal role="se">NDB</literal> storage engine uses a
+ recovery scheme based on checkpoint consistency in
+ conjunction with an operational REDO log. To produce a
+ consistent checkpoint without blocking the entire system for
+ writes, UNDO logging is done while performing the local
+ checkpoint. UNDO logging is activated on a single table
+ fragment at a time. This optimization is possible because
+ tables are stored entirely in main memory.
+ </para>
+
+ <para>
+ The UNDO index buffer is used for the updates on the primary
+ key hash index. Inserts and deletes rearrange the hash
+ index; the NDB storage engine writes UNDO log records that
+ map all physical changes to an index page so that they can
+ be undone at system restart. It also logs all active insert
+ operations for each fragment at the start of a local
+ checkpoint.
+ </para>
+
+ <para>
+ Reads and updates set lock bits and update a header in the
+ hash index entry. These changes are handled by the
+ page-writing algorithm to ensure that these operations need
+ no UNDO logging.
+ </para>
+
+ <para>
+ This buffer is 2MB by default. The minimum value is 1MB,
+ which is sufficient for most applications. For applications
+ doing extremely large or numerous inserts and deletes
+ together with large transactions and large primary keys, it
+ may be necessary to increase the size of this buffer. If
+ this buffer is too small, the NDB storage engine issues
+ internal error code 677 (<literal>Index UNDO buffers
+ overloaded</literal>).
+ </para>
+
+ <important>
+ <para>
+ It is not safe to decrease the value of this parameter
+ during a rolling restart.
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>UndoDataBuffer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-undodatabuffer">
+ <literal>UndoDataBuffer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:undodatabuffer-ndbd"/>
+
+ <para>
+ This parameter sets the size of the UNDO data buffer, which
+ performs a function similar to that of the UNDO index
+ buffer, except the UNDO data buffer is used with regard to
+ data memory rather than index memory. This buffer is used
+ during the local checkpoint phase of a fragment for inserts,
+ deletes, and updates.
+ </para>
+
+ <para>
+ Because UNDO log entries tend to grow larger as more
+ operations are logged, this buffer is also larger than its
+ index memory counterpart, with a default value of 16MB.
+ </para>
+
+ <para>
+ This amount of memory may be unnecessarily large for some
+ applications. In such cases, it is possible to decrease this
+ size to a minimum of 1MB.
+ </para>
+
+ <para>
+ It is rarely necessary to increase the size of this buffer.
+ If there is such a need, it is a good idea to check whether
+ the disks can actually handle the load caused by database
+ update activity. A lack of sufficient disk space cannot be
+ overcome by increasing the size of this buffer.
+ </para>
+
+ <para>
+ If this buffer is too small and gets congested, the NDB
+ storage engine issues internal error code 891
+ (<errortext>Data UNDO buffers overloaded</errortext>).
+ </para>
+
+ <important>
+ <para>
+ It is not safe to decrease the value of this parameter
+ during a rolling restart.
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>RedoBuffer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-redobuffer">
+ <literal>RedoBuffer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:redobuffer-ndbd"/>
+
+ <para>
+ All update activities also need to be logged. The REDO log
+ makes it possible to replay these updates whenever the
+ system is restarted. The NDB recovery algorithm uses a
+ <quote>fuzzy</quote> checkpoint of the data together with
+ the UNDO log, and then applies the REDO log to play back all
+ changes up to the restoration point.
+ </para>
+
+ <para>
+ <literal>RedoBuffer</literal> sets the size of the buffer in
+ which the REDO log is written, and is 8MB by default. The
+ minimum value is 1MB.
+ </para>
+
+ <para>
+ If this buffer is too small, the NDB storage engine issues
+ error code 1221 (<literal>REDO log buffers
+ overloaded</literal>).
+ </para>
+
+ <important>
+ <para>
+ It is not safe to decrease the value of this parameter
+ during a rolling restart.
+ </para>
+ </important>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Controlling log messages</title>
+
+ <para id="mysql-cluster-controlling-log-messages">
+ In managing the cluster, it is very important to be able to
+ control the number of log messages sent for various event
+ types to <literal>stdout</literal>. For each event category,
+ there are 16 possible event levels (numbered 0 through 15).
+ Setting event reporting for a given event category to level 15
+ means all event reports in that category are sent to
+ <literal>stdout</literal>; setting it to 0 means that there
+ will be no event reports made in that category.
+ </para>
+
+ </formalpara>
+
+ <para>
+ By default, only the startup message is sent to
+ <literal>stdout</literal>, with the remaining event reporting
+ level defaults being set to 0. The reason for this is that these
+ messages are also sent to the management server's cluster log.
+ </para>
+
+ <para>
+ An analogous set of levels can be set for the management client
+ to determine which event levels to record in the cluster log.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelStartup</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelstartup">
+ <literal>LogLevelStartup</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:loglevelstartup-ndbd"/>
+
+ <para>
+ The reporting level for events generated during startup of
+ the process.
+ </para>
+
+ <para>
+ The default level is 1.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelShutdown</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelshutdown">
+ <literal>LogLevelShutdown</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:loglevelshutdown-ndbd"/>
+
+ <para>
+ The reporting level for events generated as part of graceful
+ shutdown of a node.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelStatistic (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelstatistic">
+ <literal>LogLevelStatistic</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:loglevelstatistic-ndbd"/>
+
+ <para>
+ The reporting level for statistical events such as number of
+ primary key reads, number of updates, number of inserts,
+ information relating to buffer usage, and so on.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelCheckpoint (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelcheckpoint">
+ <literal>LogLevelCheckpoint</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:loglevelcheckpoint-ndbd"/>
+
+ <para>
+ The reporting level for events generated by local and global
+ checkpoints.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelNodeRestart (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelnoderestart">
+ <literal>LogLevelNodeRestart</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:loglevelnoderestart-ndbd"/>
+
+ <para>
+ The reporting level for events generated during node
+ restart.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelConnection (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelconnection">
+ <literal>LogLevelConnection</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:loglevelconnection-ndbd"/>
+
+ <para>
+ The reporting level for events generated by connections
+ between cluster nodes.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelError</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelerror">
+ <literal>LogLevelError</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:loglevelerror-ndbd"/>
+
+ <para>
+ The reporting level for events generated by errors and
+ warnings by the cluster as a whole. These errors do not
+ cause any node failure but are still considered worth
+ reporting.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelCongestion</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelcongestion">
+ <literal>LogLevelCongestion</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:loglevelcongestion-ndbd"/>
+
+ <para>
+ The reporting level for events generated by congestion.
+ These errors do not cause node failure but are still
+ considered worth reporting.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelInfo</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelinfo">
+ <literal>LogLevelInfo</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:loglevelinfo-ndbd"/>
+
+ <para>
+ The reporting level for events generated for information
+ about the general state of the cluster.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Backup parameters</title>
+
+ <para id="mysql-cluster-backup-parameters">
+ The <literal>[ndbd]</literal> parameters discussed in this
+ section define memory buffers set aside for execution of
+ online backups.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupDataBufferSize (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupdatabuffersize">
+ <literal>BackupDataBufferSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:backupdatabuffersize-ndbd"/>
+
+ <para>
+ In creating a backup, there are two buffers used for sending
+ data to the disk. The backup data buffer is used to fill in
+ data recorded by scanning a node's tables. Once this buffer
+ has been filled to the level specified as
+ <literal>BackupWriteSize</literal> (see below), the pages
+ are sent to disk. While flushing data to disk, the backup
+ process can continue filling this buffer until it runs out
+ of space. When this happens, the backup process pauses the
+ scan and waits until some disk writes have completed freed
+ up memory so that scanning may continue.
+ </para>
+
+ <para>
+ The default value is 2MB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupLogBufferSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backuplogbuffersize">
+ <literal>BackupLogBufferSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:backuplogbuffersize-ndbd"/>
+
+ <para>
+ The backup log buffer fulfills a role similar to that played
+ by the backup data buffer, except that it is used for
+ generating a log of all table writes made during execution
+ of the backup. The same principles apply for writing these
+ pages as with the backup data buffer, except that when there
+ is no more space in the backup log buffer, the backup fails.
+ For that reason, the size of the backup log buffer must be
+ large enough to handle the load caused by write activities
+ while the backup is being made. See
+ <xref linkend="mysql-cluster-backup-configuration"/>.
+ </para>
+
+ <para>
+ The default value for this parameter should be sufficient
+ for most applications. In fact, it is more likely for a
+ backup failure to be caused by insufficient disk write speed
+ than it is for the backup log buffer to become full. If the
+ disk subsystem is not configured for the write load caused
+ by applications, the cluster is unlikely to be able to
+ perform the desired operations.
+ </para>
+
+ <para>
+ It is preferable to configure cluster nodes in such a manner
+ that the processor becomes the bottleneck rather than the
+ disks or the network connections.
+ </para>
+
+ <para>
+ The default value is 2MB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupmemory">
+ <literal>BackupMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:backupmemory-ndbd"/>
+
+ <para>
+ This parameter is simply the sum of
+ <literal>BackupDataBufferSize</literal> and
+ <literal>BackupLogBufferSize</literal>.
+ </para>
+
+ <para>
+ The default value is 2MB + 2MB = 4MB.
+ </para>
+
+ <important>
+ <para>
+ If <literal>BackupDataBufferSize</literal> and
+ <literal>BackupLogBufferSize</literal> taken together
+ exceed 4MB, then this parameter must be set explicitly in
+ the <filename>config.ini</filename> file to their sum.
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupWriteSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupwritesize">
+ <literal>BackupWriteSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:backupwritesize-ndbd"/>
+
+ <para>
+ This parameter specifies the default size of messages
+ written to disk by the backup log and backup data buffers.
+ </para>
+
+ <para>
+ The default value is 32KB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupMaxWriteSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupmaxwritesize">
+ <literal>BackupMaxWriteSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:backupmaxwritesize-ndbd"/>
+
+ <para>
+ This parameter specifies the maximum size of messages
+ written to disk by the backup log and backup data buffers.
+ </para>
+
+ <para>
+ The default value is 256KB.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <important>
+ <para>
+ When specifying these parameters, the following relationships
+ must hold true. Otherwise, the data node will be unable to
+ start.
+ </para>
+ </important>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>BackupDataBufferSize >= BackupWriteSize +
+ 188KB</literal>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>BackupLogBufferSize >= BackupWriteSize +
+ 16KB</literal>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>BackupMaxWriteSize >= BackupWriteSize</literal>
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <note>
+ <para>
+ To add new data nodes to a MySQL Cluster, it is necessary to
+ shut down the cluster completely, update the
+ <filename>config.ini</filename> file, and then restart the
+ cluster (that is, you must perform a system restart). All data
+ node processes must be started with the
+ <option>--initial</option> option.
+ </para>
+
+ <para>
+ We are working to make it possible to add new data node groups
+ to a running cluster online in a future release; however, we
+ do not plan to implement this change in MySQL
+ ¤t-series;.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-api-definition">
+
+ <title>Defining SQL and Other API Nodes in a MySQL Cluster</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>SQL node</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>API node</secondary>
+ </indexterm>
+
+ <para>
+ The <literal>[mysqld]</literal> and <literal>[api]</literal>
+ sections in the <filename>config.ini</filename> file define the
+ behavior of the MySQL servers (SQL nodes) and other applications
+ (API nodes) used to access cluster data. None of the parameters
+ shown is required. If no computer or host name is provided, any
+ host can use this SQL or API node.
+ </para>
+
+ <para>
+ Generally speaking, a <literal>[mysqld]</literal> section is
+ used to indicate a MySQL server providing an SQL interface to
+ the cluster, and an <literal>[api]</literal> section is used for
+ applications other than <command>mysqld</command> processes
+ accessing cluster data, but the two designations are actually
+ synonomous; you can, for instance, list parameters for a MySQL
+ server acting as an SQL node in an <literal>[api]</literal>
+ section.
+ </para>
+
+ <note>
+ <para>
+ For a discussion of MySQL server options for MySQL Cluster,
+ see <xref linkend="mysql-cluster-program-options-mysqld"/>;
+ for information about MySQL server system variables relating
+ to MySQL Cluster, see
+ <xref linkend="mysql-cluster-system-variables"/>.
+ </para>
+ </note>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>Id</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-id">
+ <literal>Id</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:id-api"/>
+
+ <para>
+ The <literal>Id</literal> value is used to identify the node
+ in all cluster internal messages. It must be an integer in
+ the range 1 to 63 inclusive, and must be unique among all
+ node IDs within the cluster.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ExecuteOnComputer</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-executeoncomputer">
+ <literal>ExecuteOnComputer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:executeoncomputer-api"/>
+
+ <para>
+ This refers to the <literal>Id</literal> set for one of the
+ computers (hosts) defined in a <literal>[computer]</literal>
+ section of the configuration file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HostName</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-hostname">
+ <literal>HostName</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:hostname-api"/>
+
+ <para>
+ Specifying this parameter defines the host name of the
+ computer on which the SQL node (API node) is to reside. To
+ specify a host name, either this parameter or
+ <literal>ExecuteOnComputer</literal> is required.
+ </para>
+
+ <para>
+ If no <literal>HostName</literal> or
+ <literal>ExecuteOnComputer</literal> is specified in a given
+ <literal>[mysql]</literal> or <literal>[api]</literal>
+ section of the <filename>config.ini</filename> file, then an
+ SQL or API node may connect using the corresponding
+ <quote>slot</quote> from any host which can establish a
+ network connection to the management server host machine.
+ <emphasis>This differs from the default behavior for data
+ nodes, where <literal>localhost</literal> is assumed for
+ <literal>HostName</literal> unless otherwise
+ specified</emphasis>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationRank</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-arbitrationrank">
+ <literal>ArbitrationRank</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:arbitrationrank-api"/>
+
+ <para>
+ This parameter defines which nodes can act as arbitrators.
+ Both MGM nodes and SQL nodes can be arbitrators. A value of
+ 0 means that the given node is never used as an arbitrator,
+ a value of 1 gives the node high priority as an arbitrator,
+ and a value of 2 gives it low priority. A normal
+ configuration uses the management server as arbitrator,
+ setting its <literal>ArbitrationRank</literal> to 1 (the
+ default) and those for all SQL nodes to 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationDelay</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-arbitrationdelay">
+ <literal>ArbitrationDelay</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:arbitrationdelay-api"/>
+
+ <para>
+ Setting this parameter to any other value than 0 (the
+ default) means that responses by the arbitrator to
+ arbitration requests will be delayed by the stated number of
+ milliseconds. It is usually not necessary to change this
+ value.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BatchByteSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-batchbytesize">
+ <literal>BatchByteSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:batchbytesize-api"/>
+
+ <remark role="todo">
+ Add pointers to discussions of table scans and range scans
+ in Optimization chapter. [js]
+ </remark>
+
+ <para>
+ For queries that are translated into full table scans or
+ range scans on indexes, it is important for best performance
+ to fetch records in properly sized batches. It is possible
+ to set the proper size both in terms of number of records
+ (<literal>BatchSize</literal>) and in terms of bytes
+ (<literal>BatchByteSize</literal>). The actual batch size is
+ limited by both parameters.
+ </para>
+
+ <para>
+ The speed at which queries are performed can vary by more
+ than 40% depending upon how this parameter is set. In future
+ releases, MySQL Server will make educated guesses on how to
+ set parameters relating to batch size, based on the query
+ type.
+ </para>
+
+ <para>
+ This parameter is measured in bytes and by default is equal
+ to 32KB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BatchSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-batchsize">
+ <literal>BatchSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:batchsize-api"/>
+
+ <para>
+ This parameter is measured in number of records and is by
+ default set to 64. The maximum size is 992.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxScanBatchSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-maxscanbatchsize">
+ <literal>MaxScanBatchSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:maxscanbatchsize-api"/>
+
+ <para>
+ The batch size is the size of each batch sent from each data
+ node. Most scans are performed in parallel to protect the
+ MySQL Server from receiving too much data from many nodes in
+ parallel; this parameter sets a limit to the total batch
+ size over all nodes.
+ </para>
+
+ <para>
+ The default value of this parameter is set to 256KB. Its
+ maximum size is 16MB.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ You can obtain some information from a MySQL server running as a
+ Cluster SQL node using <literal role="stmt">SHOW
+ STATUS</literal> in the <literal>mysql</literal> client, as
+ shown here:
+ </para>
+
+<programlisting>
+mysql> <userinput>SHOW STATUS LIKE 'ndb%';</userinput>
++-----------------------------+---------------+
+| Variable_name | Value |
++-----------------------------+---------------+
+| Ndb_cluster_node_id | 5 |
+| Ndb_config_from_host | 192.168.0.112 |
+| Ndb_config_from_port | 1186 |
+| Ndb_number_of_storage_nodes | 4 |
++-----------------------------+---------------+
+4 rows in set (0.02 sec)
+</programlisting>
+
+ <para>
+ For information about these Cluster system status variables, see
+ <xref linkend="server-status-variables"/>.
+ </para>
+
+ <note>
+ <para>
+ To add new SQL or API nodes to the configuration of a running
+ MySQL Cluster, it is necessary to perform a rolling restart of
+ all cluster nodes after adding new <literal>[mysqld]</literal>
+ or <literal>[api]</literal> sections to the
+ <filename>config.ini</filename> file (or files, if you are
+ using more than one management server). This must be done
+ before the new SQL or API nodes can connect to the cluster.
+ </para>
+
+ <para>
+ It is <emphasis>not</emphasis> necessary to perform any
+ restart of the cluster if new SQL or API nodes can employ
+ previously unused API slots in the cluster configuration to
+ connect to the cluster.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-tcp-definition">
+
+ <title>MySQL Cluster TCP/IP Connections</title>
+
+ <para>
+ TCP/IP is the default transport mechanism for all connections
+ between nodes in a MySQL Cluster. Normally it is not necessary
+ to define TCP/IP connections; MySQL Cluster automatically sets
+ up such connections for all data nodes, management nodes, and
+ SQL or API nodes.
+ </para>
+
+ <note>
+ <para>
+ For an exception to this rule, see
+ <xref linkend="mysql-cluster-tcp-definition-direct"/>.
+ </para>
+ </note>
+
+ <para>
+ To override the default connection parameters, it is necessary
+ to define a connection using one or more
+ <literal>[tcp]</literal> sections in the
+ <filename>config.ini</filename> file. Each
+ <literal>[tcp]</literal> section explicitly defines a TCP/IP
+ connection between two MySQL Cluster nodes, and must contain at
+ a minimum the parameters <literal>NodeId1</literal> and
+ <literal>NodeId2</literal>, as well as any connection parameters
+ to override.
+ </para>
+
+ <para>
+ It is also possible to change the default values for these
+ parameters by setting them in the <literal>[tcp
+ default]</literal> section.
+ </para>
+
+ <important>
+ <para>
+ Any <literal>[tcp]</literal> sections in the
+ <filename>config.ini</filename> file should be listed
+ <emphasis>last</emphasis>, following all other sections in the
+ file. However, this is not required for a <literal>[tcp
+ default]</literal> section. This requirement is a known issue
+ with the way in which the <filename>config.ini</filename> file
+ is read by the MySQL Cluster management server.
+ </para>
+ </important>
+
+ <para>
+ Connection parameters which can be set in
+ <literal>[tcp]</literal> and <literal>[tcp default]</literal>
+ sections of the <filename>config.ini</filename> file are listed
+ here:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para id="ndbparam-tcp-nodeid">
+ <literal>NodeId1</literal>, <literal>NodeId2</literal>
+ </para>
+
+ <para>
+ To identify a connection between two nodes it is necessary
+ to provide their node IDs in the <literal>[tcp]</literal>
+ section of the configuration file. These are the same unique
+ <literal>Id</literal> values for each of these nodes as
+ described in <xref linkend="mysql-cluster-api-definition"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendBufferMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-sendbuffermemory">
+ <literal>SendBufferMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:sendbuffermemory-tcp"/>
+
+ <para>
+ TCP transporters use a buffer to store all messages before
+ performing the send call to the operating system. When this
+ buffer reaches 64KB its contents are sent; these are also
+ sent when a round of messages have been executed. To handle
+ temporary overload situations it is also possible to define
+ a bigger send buffer.
+ </para>
+
+ <para>
+ The default size of the send buffer is 256 KB; 2MB is
+ recommended in most situations in which it is necessary to
+ set this parameter. The minimum size is 64 KB; the
+ theoretical maximum is 4 GB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendSignalId</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-sendsignalid">
+ <literal>SendSignalId</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:sendsignalid-tcp"/>
+
+ <para>
+ To be able to retrace a distributed message datagram, it is
+ necessary to identify each message. When this parameter is
+ set to <literal>Y</literal>, message IDs are transported
+ over the network. This feature is disabled by default in
+ production builds, and enabled in <literal>-debug</literal>
+ builds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Checksum</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-checksum">
+ <literal>Checksum</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:checksum-tcp"/>
+
+ <para>
+ This parameter is a boolean parameter (enabled by setting it
+ to <literal>Y</literal> or <literal>1</literal>, disabled by
+ setting it to <literal>N</literal> or <literal>0</literal>).
+ It is disabled by default. When it is enabled, checksums for
+ all messages are calculated before they placed in the send
+ buffer. This feature ensures that messages are not corrupted
+ while waiting in the send buffer, or by the transport
+ mechanism.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>PortNumber</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-portnumber">
+ <literal>PortNumber</literal>
+ (<emphasis>OBSOLETE</emphasis>)
+ </para>
+
+ <para>
+ This formerly specified the port number to be used for
+ listening for connections from other nodes. This parameter
+ should no longer be used.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ReceiveBufferMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-receivebuffermemory">
+ <literal>ReceiveBufferMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:receivebuffermemory-tcp"/>
+
+ <para>
+ Specifies the size of the buffer used when receiving data
+ from the TCP/IP socket.
+ </para>
+
+ <para>
+ The default value of this parameter from its of 64 KB; 1M is
+ recommended in most situations where the size of the receive
+ buffer needs to be set. The minimum possible value is 16K;
+ theoretical maximum is 4G.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
+ <section id="mysql-cluster-tcp-definition-direct">
+
+ <title>MySQL Cluster TCP/IP Connections Using Direct Connections</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>networking</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>transporters</secondary>
+ <tertiary>TCP/IP</tertiary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>direct connections between nodes</secondary>
+ </indexterm>
+
+ <para>
+ Setting up a cluster using direct connections between data nodes
+ requires specifying explicitly the crossover IP addresses of the
+ data nodes so connected in the <literal>[tcp]</literal> section
+ of the cluster <filename>config.ini</filename> file.
+ </para>
+
+ <para>
+ In the following example, we envision a cluster with at least
+ four hosts, one each for a management server, an SQL node, and
+ two data nodes. The cluster as a whole resides on the
+ <literal>172.23.72.*</literal> subnet of a LAN. In addition to
+ the usual network connections, the two data nodes are connected
+ directly using a standard crossover cable, and communicate with
+ one another directly using IP addresses in the
+ <literal>1.1.0.*</literal> address range as shown:
+ </para>
+
+<programlisting>
+# Management Server
+[ndb_mgmd]
+Id=1
+HostName=172.23.72.20
+
+# SQL Node
+[mysqld]
+Id=2
+HostName=172.23.72.21
+
+# Data Nodes
+[ndbd]
+Id=3
+HostName=172.23.72.22
+
+[ndbd]
+Id=4
+HostName=172.23.72.23
+
+# TCP/IP Connections
+[tcp]
+NodeId1=3
+NodeId2=4
+HostName1=1.1.0.1
+HostName2=1.1.0.2
+</programlisting>
+
+ <para>
+ The <literal>HostName<replaceable>N</replaceable></literal>
+ parameter, where <replaceable>N</replaceable> is an integer, is
+ used only when specifying direct TCP/IP connections.
+ </para>
+
+ <para>
+ The use of direct connections between data nodes can improve the
+ cluster's overall efficiency by allowing the data nodes to
+ bypass an Ethernet device such as a switch, hub, or router, thus
+ cutting down on the cluster's latency. It is important to note
+ that to take the best advantage of direct connections in this
+ fashion with more than two data nodes, you must have a direct
+ connection between each data node and every other data node in
+ the same node group.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-shm-definition">
+
+ <title>MySQL Cluster Shared-Memory Connections</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>networking</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>shared memory transporter</primary>
+ <see>MySQL Cluster</see>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>shared memory transport</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>transporters</secondary>
+ <tertiary>shared memory (SHM)</tertiary>
+ </indexterm>
+
+ <para>
+ MySQL Cluster attempts to use the shared memory transporter and
+ configure it automatically where possible. (In very early
+ versions of MySQL Cluster, shared memory segments functioned
+ only when the server binary was built using
+ <option>--with-ndb-shm</option>.) <literal>[shm]</literal>
+ sections in the <filename>config.ini</filename> file explicitly
+ define shared-memory connections between nodes in the cluster.
+ When explicitly defining shared memory as the connection method,
+ it is necessary to define at least <literal>NodeId1</literal>,
+ <literal>NodeId2</literal> and <literal>ShmKey</literal>. All
+ other parameters have default values that should work well in
+ most cases.
+ </para>
+
+ <important>
+ <para>
+ <emphasis>SHM functionality is considered experimental
+ only</emphasis>. It is not officially supported in any current
+ MySQL Cluster release, and testing results indicate that SHM
+ performance is not appreciably greater than when using TCP/IP
+ for the transporter.
+ </para>
+
+ <para>
+ For these reasons, you must determine for yourself or by using
+ our free resources (forums, mailing lists) whether SHM can be
+ made to work correctly in your specific case.
+ </para>
+ </important>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>node identifiers (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>node identifiers</secondary>
+ </indexterm>
+
+ <para id="ndbparam-shm-nodeids">
+ <literal>NodeId1</literal>, <literal>NodeId2</literal>
+ </para>
+
+ <para>
+ To identify a connection between two nodes it is necessary
+ to provide node identifiers for each of them, as
+ <literal>NodeId1</literal> and <literal>NodeId2</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ShmKey</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-shmkey">
+ <literal>ShmKey</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:shmkey-shm"/>
+
+ <para>
+ When setting up shared memory segments, a node ID, expressed
+ as an integer, is used to identify uniquely the shared
+ memory segment to use for the communication. There is no
+ default value.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ShmSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-shmsize">
+ <literal>ShmSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:shmsize-shm"/>
+
+ <para>
+ Each SHM connection has a shared memory segment where
+ messages between nodes are placed by the sender and read by
+ the reader. The size of this segment is defined by
+ <literal>ShmSize</literal>. The default value is 1MB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendSignalId</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-sendsignalid">
+ <literal>SendSignalId</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:sendsignalid-shm"/>
+
+ <para>
+ To retrace the path of a distributed message, it is
+ necessary to provide each message with a unique identifier.
+ Setting this parameter to <literal>Y</literal> causes these
+ message IDs to be transported over the network as well. This
+ feature is disabled by default in production builds, and
+ enabled in <literal>-debug</literal> builds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Checksum (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-checksum">
+ <literal>Checksum</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:checksum-shm"/>
+
+ <para>
+ This parameter is a boolean
+ (<literal>Y</literal>/<literal>N</literal>) parameter which
+ is disabled by default. When it is enabled, checksums for
+ all messages are calculated before being placed in the send
+ buffer.
+ </para>
+
+ <para>
+ This feature prevents messages from being corrupted while
+ waiting in the send buffer. It also serves as a check
+ against data being corrupted during transport.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SigNum</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-signum">
+ <literal>SigNum</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:signum-shm"/>
+
+ <para>
+ When using the shared memory transporter, a process sends an
+ operating system signal to the other process when there is
+ new data available in the shared memory. Should that signal
+ conflict with with an existing signal, this parameter can be
+ used to change it. This is a possibility when using SHM due
+ to the fact that different operating systems use different
+ signal numbers.
+ </para>
+
+ <para>
+ The default value of <literal>SigNum</literal> is 0;
+ therefore, it must be set to avoid errors in the cluster log
+ when using the shared memory transporter. Typically, this
+ parameter is set to 10 in the <literal>[shm
+ default]</literal> section of the
+ <filename>config.ini</filename> file.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
+ <section id="mysql-cluster-sci-definition">
+
+ <title>SCI Transport Connections in MySQL Cluster</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>networking</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>SCI (Scalable Coherent Interface)</primary>
+ <see>MySQL Cluster</see>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>SCI (Scalable Coherent Interface)</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>transporters</secondary>
+ <tertiary>Scalable Coherent Interface (SCI)</tertiary>
+ </indexterm>
+
+ <para>
+ <literal>[sci]</literal> sections in the
+ <filename>config.ini</filename> file explicitly define SCI
+ (Scalable Coherent Interface) connections between cluster nodes.
+ Using SCI transporters in MySQL Cluster is supported only when
+ the MySQL binaries are built using
+ <option>--with-ndb-sci=<replaceable>/your/path/to/SCI</replaceable></option>.
+ The <replaceable>path</replaceable> should point to a directory
+ that contains at a minimum <filename>lib</filename> and
+ <filename>include</filename> directories containing SISCI
+ libraries and header files. (See
+ <xref linkend="mysql-cluster-interconnects"/> for more
+ information about SCI.)
+ </para>
+
+ <para>
+ In addition, SCI requires specialized hardware.
+ </para>
+
+ <para>
+ It is strongly recommended to use SCI Transporters only for
+ communication between <command>ndbd</command> processes. Note
+ also that using SCI Transporters means that the
+ <command>ndbd</command> processes never sleep. For this reason,
+ SCI Transporters should be used only on machines having at least
+ two CPUs dedicated for use by <command>ndbd</command> processes.
+ There should be at least one CPU per <command>ndbd</command>
+ process, with at least one CPU left in reserve to handle
+ operating system activities.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>node identifiers (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>node identifiers</secondary>
+ </indexterm>
+
+ <para id="ndbparam-sci-nodeids">
+ <literal>NodeId1</literal>, <literal>NodeId2</literal>
+ </para>
+
+ <para>
+ To identify a connection between two nodes it is necessary
+ to provide node identifiers for each of them, as
+ <literal>NodeId1</literal> and <literal>NodeId2</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Host*SciId* parameters</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-host1sciid0">
+ <literal>Host1SciId0</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:host1sciid0-sci"/>
+
+ <para>
+ This identifies the SCI node ID on the first Cluster node
+ (identified by <literal>NodeId1</literal>).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para id="ndbparam-sci-host1sciid1">
+ <literal>Host1SciId1</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:host1sciid1-sci"/>
+
+ <para>
+ It is possible to set up SCI Transporters for failover
+ between two SCI cards which then should use separate
+ networks between the nodes. This identifies the node ID and
+ the second SCI card to be used on the first node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para id="ndbparam-sci-host2sciid0">
+ <literal>Host2SciId0</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:host2sciid0-sci"/>
+
+ <para>
+ This identifies the SCI node ID on the second Cluster node
+ (identified by <literal>NodeId2</literal>).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para id="ndbparam-sci-host2sciid1">
+ <literal>Host2SciId1</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:host2sciid1-sci"/>
+
+ <para>
+ When using two SCI cards to provide failover, this parameter
+ identifies the second SCI card to be used on the second
+ node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SharedBufferSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-sharedbuffersize">
+ <literal>SharedBufferSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:sharedbuffersize-sci"/>
+
+ <para>
+ Each SCI transporter has a shared memory segment used for
+ communication between the two nodes. Setting the size of
+ this segment to the default value of 1MB should be
+ sufficient for most applications. Using a smaller value can
+ lead to problems when performing many parallel inserts; if
+ the shared buffer is too small, this can also result in a
+ crash of the <command>ndbd</command> process.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendLimit</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-sendlimit">
+ <literal>SendLimit</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:sendlimit-sci"/>
+
+ <para>
+ A small buffer in front of the SCI media stores messages
+ before transmitting them over the SCI network. By default,
+ this is set to 8KB. Our benchmarks show that performance is
+ best at 64KB but 16KB reaches within a few percent of this,
+ and there was little if any advantage to increasing it
+ beyond 8KB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendSignalId</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-sendsignalid">
+ <literal>SendSignalId</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:sendsignalid-sci"/>
+
+ <para>
+ To trace a distributed message it is necessary to identify
+ each message uniquely. When this parameter is set to
+ <literal>Y</literal>, message IDs are transported over the
+ network. This feature is disabled by default in production
+ builds, and enabled in <literal>-debug</literal> builds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Checksum (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-checksum">
+ <literal>Checksum</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.0:ndb-config-params:checksum-sci"/>
+
+ <para>
+ This parameter is a boolean value, and is disabled by
+ default. When <literal>Checksum</literal> is enabled,
+ checksums are calculated for all messages before they are
+ placed in the send buffer. This feature prevents messages
+ from being corrupted while waiting in the send buffer. It
+ also serves as a check against data being corrupted during
+ transport.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
+ </section>
+
+ <section id="mysql-cluster-config-params-overview">
+
+ <title>Overview of MySQL Cluster Configuration Parameters</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration parameters</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>configuration</primary>
+ <secondary>MySQL Cluster</secondary>
+ </indexterm>
+
+ <remark role="note">
+ [js] Prepared with the assistance of Johan Andersson, Hartmut
+ Holzgraefe, Sergei Kozlov, Jeb Miller, and Bernd Ocklin.
+ </remark>
+
+ <para>
+ The next three sections provide summary tables of MySQL Cluster
+ configuration parameters used in the
+ <filename>config.ini</filename> file to govern the cluster's
+ functioning. Each table lists the parameters for one of the
+ Cluster node process types (<command>ndbd</command>,
+ <command>ndb_mgmd</command>, and <command>mysqld</command>), and
+ includes the parameter's type as well as its default, mimimum, and
+ maximum values as applicable.
+ </para>
+
+ <para>
+ It is also stated what type of restart is required (node restart
+ or system restart) — and whether the restart must be done
+ with <option>--initial</option> — to change the value of a
+ given configuration parameter. This information is provided in
+ each table's <emphasis role="bold">Restart Type</emphasis> column,
+ which contains one of the values shown in this list:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>N</literal>: Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IN</literal>: Initial Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>S</literal>: System Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IS</literal>: Initial System Restart
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ When performing a node restart or an initial node restart, all of
+ the cluster's data nodes must be restarted in turn (also referred
+ to as a <firstterm>rolling restart</firstterm>). It is possible to
+ update cluster configuration parameters marked
+ <literal>N</literal> or <literal>IN</literal> online — that
+ is, without shutting down the cluster — in this fashion. An
+ initial node restart requires restarting each
+ <command>ndbd</command> process with the
+ <option>--initial</option> option.
+ </para>
+
+ <para>
+ A system restart requires a complete shutdown and restart of the
+ entire cluster. An initial system restart requires taking a backup
+ of the cluster, wiping the cluster file system after shutdown, and
+ then restoring from the backup following the restart.
+ </para>
+
+ <para>
+ In any cluster restart, all of the cluster's management servers
+ must be restarted in order for them to read the updated
+ configuration parameter values.
+ </para>
+
+ <important>
+ <para>
+ Values for numeric cluster parameters can generally be increased
+ without any problems, although it is advisable to do so
+ progressively, making such adjustments in relatively small
+ increments. However, decreasing the values of such parameters
+ — particularly those relating to memory usage and disk
+ space — is not to be undertaken lightly, and it is
+ recommended that you do so only following careful planning and
+ testing. In addition, it is the generally the case that
+ parameters relating to memory and disk usage which can be raised
+ using a simple node restart require an initial node restart to
+ be lowered.
+ </para>
+ </important>
+
+ <para>
+ Because some of these parameters can be used for configuring more
+ than one type of cluster node, they may appear in more than one of
+ the tables.
+ </para>
+
+ <note>
+ <para>
+ <literal>4294967039</literal> — which often appears as a
+ maximum value in these tables — is defined in the
+ <literal role="se">NDBCLUSTER</literal> sources as
+ <literal>MAX_INT_RNIL</literal> and is equal to
+ <literal>0xFFFFFEFF</literal>, or
+ <literal>2<superscript>32</superscript> −
+ 2<superscript>8</superscript> − 1</literal>.
+ </para>
+ </note>
+
+ <section id="mysql-cluster-config-params-ndbd">
+
+ <title>MySQL Cluster Data Node Configuration Parameters</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration parameters</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[ndbd] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[ndbd default] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ The following table provides information about parameters used
+ in the <literal>[ndbd]</literal> or <literal>[ndbd
+ default]</literal> sections of a <filename>config.ini</filename>
+ file for configuring MySQL Cluster data nodes. For detailed
+ descriptions and other additional information about each of
+ these parameters, see
+ <xref linkend="mysql-cluster-ndbd-definition"/>.
+ </para>
+
+ <para>
+ <emphasis><emphasis role="bold">Restart Type</emphasis> Column
+ Values</emphasis>
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>N</literal>: Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IN</literal>: Initial Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>S</literal>: System Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IS</literal>: Initial System Restart
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ See <xref linkend="mysql-cluster-config-params-overview"/>, for
+ additional explanations of these abbreviations.
+ </para>
+
+ <table id="mysql-cluster-config-params-ndbd-table">
+ <title>MySQL Cluster Data Node Configuration Parameters</title>
+ <tgroup cols="6">
+ <colspec colwidth="30*"/>
+ <colspec colwidth="5*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="5*"/>
+ <tbody>
+ <row>
+ <entry><emphasis role="bold">Parameter Name</emphasis></entry>
+ <entry><emphasis role="bold">Type/Units</emphasis></entry>
+ <entry><emphasis role="bold">Default Value</emphasis></entry>
+ <entry><emphasis role="bold">Minimum Value</emphasis></entry>
+ <entry><emphasis role="bold">Maximum Value</emphasis></entry>
+ <entry><emphasis role="bold">Restart Type</emphasis></entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-arbitrationtimeout">ArbitrationTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>1000</entry>
+ <entry>10</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupdatabuffersize">BackupDataBufferSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>2M</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupdatadir">BackupDataDir</link></literal></entry>
+ <entry>string</entry>
+ <entry><filename><literal>FileSystemPath</literal>/BACKUP</filename></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backuplogbuffersize">BackupLogBufferSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>2M</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupmemory">BackupMemory</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>4M</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupwritesize">BackupWriteSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>32K</entry>
+ <entry>2K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupmaxwritesize">BackupMaxWriteSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>256K</entry>
+ <entry>2K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-batchsizeperlocalscan">BatchSizePerLocalScan</link></literal></entry>
+ <entry>integer</entry>
+ <entry>64</entry>
+ <entry>1</entry>
+ <entry>992</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-datadir">DataDir</link></literal></entry>
+ <entry>string</entry>
+ <entry><filename>.</filename></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-datamemory">DataMemory</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>80M</entry>
+ <entry>1M</entry>
+ <entry>1024G (subject to available system RAM and size of
+ <literal>IndexMemory</literal>)</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-diskless">Diskless</link></literal></entry>
+ <entry>true|false (<literal>1</literal>|<literal>0</literal>)</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-executeoncomputer">ExecuteOnComputer</link></literal></entry>
+ <entry>integer</entry>
+ <entry/>
+ <entry/>
+ <entry/>
+ <entry/>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-filesystempath">FileSystemPath</link></literal></entry>
+ <entry>string</entry>
+ <entry>value specified for <literal>DataDir</literal></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-heartbeatintervaldbapi">HeartbeatIntervalDbApi</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>1500</entry>
+ <entry>100</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-heartbeatintervaldbdb">HeartbeatIntervalDbDb</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>1500</entry>
+ <entry>10</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-hostname">HostName</link></literal></entry>
+ <entry>string</entry>
+ <entry><literal>localhost</literal></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>S</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-id">Id</link></literal></entry>
+ <entry>integer</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>1</entry>
+ <entry>48</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-indexmemory">IndexMemory</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>18M</entry>
+ <entry>1M</entry>
+ <entry>1024G (subject to available system RAM and size of
+ <literal>DataMemory</literal>)</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-lockpagesinmainmemory">LockPagesInMainMemory</link></literal></entry>
+ <entry><emphasis>As of MySQL 5.0.36</emphasis>: integer;
+ <emphasis>previously</emphasis>: true|false
+ (<literal>1</literal>|<literal>0</literal>)</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelcheckpoint">LogLevelCheckpoint</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelcongestion">LogLevelCongestion</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelconnection">LogLevelConnection</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelerror">LogLevelError</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelinfo">LogLevelInfo</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelnoderestart">LogLevelNodeRestart</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelshutdown">LogLevelShutdown</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelstartup">LogLevelStartup</link></literal></entry>
+ <entry>integer</entry>
+ <entry>1</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelstatistic">LogLevelStatistic</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-longmessagebuffer">LongMessageBuffer</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>1M</entry>
+ <entry>512K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofattributes">MaxNoOfAttributes</link></literal></entry>
+ <entry>integer</entry>
+ <entry>1000</entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofconcurrentindexoperations">MaxNoOfConcurrentIndexOperations</link></literal></entry>
+ <entry>integer</entry>
+ <entry>8K</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofconcurrentoperations">MaxNoOfConcurrentOperations</link></literal></entry>
+ <entry>integer</entry>
+ <entry>32768</entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofconcurrentscans">MaxNoOfConcurrentScans</link></literal></entry>
+ <entry>integer</entry>
+ <entry>256</entry>
+ <entry>2</entry>
+ <entry>500</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofconcurrenttransactions">MaxNoOfConcurrentTransactions</link></literal></entry>
+ <entry>integer</entry>
+ <entry>4096</entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>S</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooffiredtriggers">MaxNoOfFiredTriggers</link></literal></entry>
+ <entry>integer</entry>
+ <entry>4000</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofindexes">MaxNoOfIndexes</link></literal>
+ (<emphasis>DEPRECATED</emphasis> — use
+ <literal>MaxNoOfOrderedIndexes</literal> or
+ <literal>MaxNoOfUniqueHashIndexes</literal> instead)</entry>
+ <entry>integer</entry>
+ <entry>128</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooflocaloperations">MaxNoOfLocalOperations</link></literal></entry>
+ <entry>integer</entry>
+ <entry><literal>UNDEFINED</literal></entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooflocalscans">MaxNoOfLocalScans</link></literal></entry>
+ <entry>integer</entry>
+ <entry><literal>UNDEFINED</literal> (see
+ <link linkend="ndbparam-ndbd-maxnooflocalscans">description</link>)</entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooforderedindexes">MaxNoOfOrderedIndexes</link></literal></entry>
+ <entry>integer</entry>
+ <entry>128</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofsavedmessages">MaxNoOfSavedMessages</link></literal></entry>
+ <entry>integer</entry>
+ <entry>25</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooftables">MaxNoOfTables</link></literal></entry>
+ <entry>integer</entry>
+ <entry>128</entry>
+ <entry>8</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooftriggers">MaxNoOfTriggers</link></literal></entry>
+ <entry>integer</entry>
+ <entry>768</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofuniquehashindexes">MaxNoOfUniqueHashIndexes</link></literal></entry>
+ <entry>integer</entry>
+ <entry>64</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofdiskpagestodiskafterrestartacc">NoOfDiskPagesToDiskAfterRestartACC</link></literal></entry>
+ <entry>integer (number of 8KB pages per 100 milliseconds)</entry>
+ <entry>20 (= 20 * 80KB = 1.6MB/second)</entry>
+ <entry>1</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofdiskpagestodiskafterrestarttup">NoOfDiskPagesToDiskAfterRestartTUP</link></literal></entry>
+ <entry>integer (number of 8KB pages per 100 milliseconds)</entry>
+ <entry>40 (= 40 * 80KB = 3.2MB/second)</entry>
+ <entry>1</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofdiskpagestodiskduringrestartacc">NoOfDiskPagesToDiskDuringRestartACC</link></literal></entry>
+ <entry>integer (number of 8KB pages per 100 milliseconds)</entry>
+ <entry>20 (= 20 * 80KB = 1.6MB/second)</entry>
+ <entry>1</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofdiskpagestodiskduringrestarttup">NoOfDiskPagesToDiskDuringRestartTUP</link></literal></entry>
+ <entry>integer (number of 8KB pages per 100 milliseconds)</entry>
+ <entry>40 (= 40 * 80KB = 3.2MB/second)</entry>
+ <entry>1</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-nooffragmentlogfiles">NoOfFragmentLogFiles</link></literal></entry>
+ <entry>integer</entry>
+ <entry>8</entry>
+ <entry>1</entry>
+ <entry>4294967039</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofreplicas">NoOfReplicas</link></literal></entry>
+ <entry>integer</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>1</entry>
+ <entry>4 (theoretical); 2 (supported)</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-redobuffer">RedoBuffer</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>8M</entry>
+ <entry>1M</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-restartonerrorinsert">RestartOnErrorInsert</link></literal>
+ (<emphasis>DEBUG BUILDS ONLY</emphasis>)</entry>
+ <entry>true|false (<literal>1</literal>|<literal>0</literal>)</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-serverport">ServerPort</link></literal>
+ (<emphasis>OBSOLETE</emphasis>)</entry>
+ <entry>integer</entry>
+ <entry>1186</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-startfailuretimeout">StartFailureTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-startpartialtimeout">StartPartialTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>30000</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-startpartitionedtimeout">StartPartitionedTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>60000</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-stoponerror">StopOnError</link></literal></entry>
+ <entry>true|false (<literal>1</literal>|<literal>0</literal>)</entry>
+ <entry>1</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweenglobalcheckpoints">TimeBetweenGlobalCheckpoints</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>2000</entry>
+ <entry>10</entry>
+ <entry>32000</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweeninactivetransactionabortcheck">TimeBetweenInactiveTransactionAbortCheck</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>1000</entry>
+ <entry>1000</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweenlocalcheckpoints">TimeBetweenLocalCheckpoints</link></literal></entry>
+ <entry>integer (number of 4-byte words as a base-2 logarithm)</entry>
+ <entry>20 (= <literal>4 * 2<superscript>20</superscript></literal> = 4MB write
+ operations)</entry>
+ <entry>0</entry>
+ <entry>31</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweenwatchdogcheck">TimeBetweenWatchDogCheck</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>4000</entry>
+ <entry>70</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-transactionbuffermemory">TransactionBufferMemory</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>1M</entry>
+ <entry>1K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-transactiondeadlockdetectiontimeout">TransactionDeadlockDetectionTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>1200</entry>
+ <entry>100 (Can actually be set as low as 50, but any value less than 100 is
+ treated as 100.)</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-transactioninactivetimeout">TransactionInactiveTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-undodatabuffer">UndoDataBuffer</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>16M</entry>
+ <entry>1M</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-undoindexbuffer">UndoIndexBuffer</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>2M</entry>
+ <entry>1M</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <note>
+ <para>
+ To add new data nodes to a MySQL Cluster, it is necessary to
+ shut down the cluster completely, update the
+ <filename>config.ini</filename> file, and then restart the
+ cluster (that is, you must perform a system restart). All data
+ node processes must be started with the
+ <option>--initial</option> option.
+ </para>
+
+ <para>
+ We are working to make it possible to add new data node groups
+ to a running cluster online in a future release; however, we
+ do not plan to implement this change in MySQL
+ ¤t-series;.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-config-params-mgm">
+
+ <title>MySQL Cluster Management Node Configuration Parameters</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration parameters</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[ndb_mgmd] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[mgm] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ The following table provides information about parameters used
+ in the <literal>[ndb_mgmd]</literal> or <literal>[mgm]</literal>
+ sections of a <filename>config.ini</filename> file for
+ configuring MySQL Cluster management nodes. For detailed
+ descriptions and other additional information about each of
+ these parameters, see
+ <xref linkend="mysql-cluster-mgm-definition"/>.
+ </para>
+
+ <para>
+ <emphasis><emphasis role="bold">Restart Type</emphasis> Column
+ Values</emphasis>
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>N</literal>: Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IN</literal>: Initial Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>S</literal>: System Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IS</literal>: Initial System Restart
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ See <xref linkend="mysql-cluster-config-params-overview"/>, for
+ additional explanations of these abbreviations.
+ </para>
+
+ <table id="mysql-cluster-config-params-mgm-table">
+ <title>MySQL Cluster Management Node Configuration Parameters</title>
+ <tgroup cols="6">
+ <colspec colwidth="30*"/>
+ <colspec colwidth="5*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="5*"/>
+ <tbody>
+ <row>
+ <entry><emphasis role="bold">Parameter Name</emphasis></entry>
+ <entry><emphasis role="bold">Type/Units</emphasis></entry>
+ <entry><emphasis role="bold">Default Value</emphasis></entry>
+ <entry><emphasis role="bold">Minimum Value</emphasis></entry>
+ <entry><emphasis role="bold">Maximum Value</emphasis></entry>
+ <entry><emphasis role="bold">Restart Type</emphasis></entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-arbitrationdelay">ArbitrationDelay</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-arbitrationrank">ArbitrationRank</link></literal></entry>
+ <entry>integer</entry>
+ <entry>1</entry>
+ <entry>0</entry>
+ <entry>2</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-datadir">DataDir</link></literal></entry>
+ <entry>string</entry>
+ <entry><filename>.</filename> (<command>ndb_mgmd</command> directory)</entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-executeoncomputer">ExecuteOnComputer</link></literal></entry>
+ <entry>integer</entry>
+ <entry/>
+ <entry/>
+ <entry/>
+ <entry/>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-hostname">HostName</link></literal></entry>
+ <entry>string</entry>
+ <entry><literal>localhost</literal></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-id">Id</link></literal></entry>
+ <entry>integer</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>1</entry>
+ <entry>63</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-logdestination">LogDestination</link></literal></entry>
+ <entry><literal>CONSOLE</literal>, <literal>SYSLOG</literal>, or
+ <literal>FILE</literal></entry>
+ <entry><literal>FILE</literal> (see
+ <xref linkend="mysql-cluster-mgm-definition"/>)</entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-portnumber">PortNumber</link></literal></entry>
+ <entry>integer</entry>
+ <entry>1186</entry>
+ <entry>1</entry>
+ <entry>65535</entry>
+ <entry>S</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <note>
+ <para>
+ After making changes in a management node's
+ configuration, it is necessary to perform a rolling restart of
+ the cluster in order for the new configuration to take effect.
+ See <xref linkend="mysql-cluster-mgm-definition"/>, for more
+ information.
+ </para>
+
+ <para>
+ To add new management servers to a running MySQL Cluster, it
+ is also necessary perform a rolling restart of all cluster
+ nodes after modifying any existing
+ <filename>config.ini</filename> files. For more information
+ about issues arising when using multiple management nodes, see
+ <xref linkend="mysql-cluster-limitations-multiple-nodes"/>.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-config-params-api">
+
+ <title>MySQL Cluster SQL Node and API Node Configuration Parameters</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration parameters</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[SQL] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[api] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ The following table provides information about parameters used
+ in the <literal>[SQL]</literal> and <literal>[api]</literal>
+ sections of a <filename>config.ini</filename> file for
+ configuring MySQL Cluster SQL nodes and API nodes. For detailed
+ descriptions and other additional information about each of
+ these parameters, see
+ <xref linkend="mysql-cluster-api-definition"/>.
+ </para>
+
+ <note>
+ <para>
+ For a discussion of MySQL server options for MySQL Cluster,
+ see <xref linkend="mysql-cluster-program-options-mysqld"/>;
+ for information about MySQL server system variables relating
+ to MySQL Cluster, see
+ <xref linkend="mysql-cluster-system-variables"/>.
+ </para>
+ </note>
+
+ <para>
+ <emphasis><emphasis role="bold">Restart Type</emphasis> Column
+ Values</emphasis>
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>N</literal>: Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IN</literal>: Initial Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>S</literal>: System Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IS</literal>: Initial System Restart
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ See <xref linkend="mysql-cluster-config-params-overview"/>, for
+ additional explanations of these abbreviations.
+ </para>
+
+ <table id="mysql-cluster-config-params-api-table">
+ <title>MySQL Cluster SQL Node and API Node Configuration Parameters</title>
+ <tgroup cols="6">
+ <colspec colwidth="30*"/>
+ <colspec colwidth="5*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="5*"/>
+ <tbody>
+ <row>
+ <entry><emphasis role="bold">Parameter Name</emphasis></entry>
+ <entry><emphasis role="bold">Type/Units</emphasis></entry>
+ <entry><emphasis role="bold">Default Value</emphasis></entry>
+ <entry><emphasis role="bold">Minimum Value</emphasis></entry>
+ <entry><emphasis role="bold">Maximum Value</emphasis></entry>
+ <entry><emphasis role="bold">Restart Type</emphasis></entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-arbitrationdelay">ArbitrationDelay</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-arbitrationrank">ArbitrationRank</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>2</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-batchbytesize">BatchByteSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>32K</entry>
+ <entry>1K</entry>
+ <entry>1M</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-batchsize">BatchSize</link></literal></entry>
+ <entry>integer</entry>
+ <entry>64</entry>
+ <entry>1</entry>
+ <entry>992</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-executeoncomputer">ExecuteOnComputer</link></literal></entry>
+ <entry>integer</entry>
+ <entry/>
+ <entry/>
+ <entry/>
+ <entry/>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-hostname">HostName</link></literal></entry>
+ <entry>string</entry>
+ <entry><emphasis>none</emphasis></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-id">Id</link></literal></entry>
+ <entry>integer</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>1</entry>
+ <entry>63</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-maxscanbatchsize">MaxScanBatchSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>256K</entry>
+ <entry>32K</entry>
+ <entry>16M</entry>
+ <entry>N</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <note>
+ <para>
+ To add new SQL or API nodes to the configuration of a running
+ MySQL Cluster, it is necessary to perform a rolling restart of
+ all cluster nodes after adding new <literal>[mysqld]</literal>
+ or <literal>[api]</literal> sections to the
+ <filename>config.ini</filename> file (or files, if you are
+ using more than one management server). This must be done
+ before the new SQL or API nodes can connect to the cluster.
+ </para>
+
+ <para>
+ It is <emphasis>not</emphasis> necessary to perform any
+ restart of the cluster if new SQL or API nodes can employ
+ previously unused API slots in the cluster configuration to
+ connect to the cluster.
+ </para>
+ </note>
+
+ </section>
+
+ </section>
+
+ <section id="mysql-cluster-config-lcp-params">
+
+ <title>Configuring MySQL Cluster Parameters for Local Checkpoints</title>
+
+ <indexterm>
+ <primary>DataMemory</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>IndexMemory</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskAfterRestartACC</primary>
+ <secondary>calculating</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskAfterRestartTUP</primary>
+ <secondary>calculating</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>NoOfFragmentLogFiles</primary>
+ <secondary>calculating</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>local checkpoints (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <remark role="note">
+ [js] Adapted by Jon Stephens from an item in Mikael Ronström's
+ blog, 2006-07-11.
+ </remark>
+
+ <para>
+ The parameters discussed in
+ <link linkend="mysql-cluster-logging-and-checkpointing">Logging
+ and Checkpointing</link> and in
+ <link linkend="mysql-cluster-data-memory-index-memory-string-memory">Data
+ Memory, Index Memory, and String Memory</link> that are used to
+ configure local checkpoints for a MySQL Cluster do not exist in
+ isolation, but rather are very much interdepedent on each other.
+ In this section, we illustrate how these parameters —
+ including <literal>DataMemory</literal>,
+ <literal>IndexMemory</literal>,
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal>,
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal>, and
+ <literal>NoOfFragmentLogFiles</literal> — relate to one
+ another in a working Cluster.
+ </para>
+
+ <para>
+ In this example, we assume that our application performs the
+ following numbers of types of operations per hour:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ 50000 selects
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 inserts
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 updates
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 deletes
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ We also make the following assumptions about the data used in the
+ application:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ We are working with a single table having 40 columns.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Each column can hold up to 32 bytes of data.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A typical <literal role="stmt">UPDATE</literal> run by the
+ application affects the values of 5 columns.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ No <literal>NULL</literal> values are inserted by the
+ application.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ A good starting point is to determine the amount of time that
+ should elapse between local checkpoints (LCPs). It is worth noting
+ that, in the event of a system restart, it takes 40-60 percent of
+ this interval to execute the REDO log — for example, if the
+ time between LCPs is 5 minutes (300 seconds), then it should take
+ 2 to 3 minutes (120 to 180 seconds) for the REDO log to be read.
+ </para>
+
+ <para>
+ The maximum amount of data per node can be assumed to be the size
+ of the <literal>DataMemory</literal> parameter. In this example,
+ we assume that this is 2 GB. The
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> parameter
+ represents the amount of data to be checkpointed per unit time
+ — however, this parameter is actually expressed as the
+ number of 8K memory pages to be checkpointed per 100 milliseconds.
+ 2 GB per 300 seconds is approximately 6.8 MB per second, or 700 KB
+ per 100 milliseconds, which works out to roughly 85 pages per 100
+ milliseconds.
+ </para>
+
+ <para>
+ Similarly, we can calculate
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal> in terms of
+ the time for local checkpoints and the amount of memory required
+ for indexes — that is, the <literal>IndexMemory</literal>.
+ Assuming that we allow 512 MB for indexes, this works out to
+ approximately 20 8-KB pages per 100 milliseconds for this
+ parameter.
+ </para>
+
+ <para>
+ Next, we need to determine the number of REDO log files required
+ — that is, fragment log files — the corresponding
+ parameter being <literal>NoOfFragmentLogFiles</literal>. We need
+ to make sure that there are sufficient REDO log files for keeping
+ records for at least 3 local checkpoints. In a production setting,
+ there are always uncertainties — for instance, we cannot be
+ sure that disks always operate at top speed or with maximum
+ throughput. For this reason, it is best to err on the side of
+ caution, so we double our requirement and calculate a number of
+ fragment log files which should be enough to keep records covering
+ 6 local checkpoints.
+ </para>
+
+ <para>
+ It is also important to remember that the disk also handles writes
+ to the REDO log and UNDO log, so if you find that the amount of
+ data being written to disk as determined by the values of
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal> and
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> is
+ approaching the amount of disk bandwidth available, you may wish
+ to increase the time between local checkpoints.
+ </para>
+
+ <para>
+ Given 5 minutes (300 seconds) per local checkpoint, this means
+ that we need to support writing log records at maximum speed for 6
+ * 300 = 1800 seconds. The size of a REDO log record is 72 bytes
+ plus 4 bytes per updated column value plus the maximum size of the
+ updated column, and there is one REDO log record for each table
+ record updated in a transaction, on each node where the data
+ reside. Using the numbers of operations set out previously in this
+ section, we derive the following:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ 50000 select operations per hour yields 0 log records (and
+ thus 0 bytes), since <literal role="stmt">SELECT</literal>
+ statements are not recorded in the REDO log.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 <literal role="stmt">DELETE</literal> statements per
+ hour is approximately 5 delete operations per second. (Since
+ we wish to be conservative in our estimate, we round up here
+ and in the following calculations.) No columns are updated by
+ deletes, so these statements consume only 5 operations * 72
+ bytes per operation = 360 bytes per second.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 <literal role="stmt">UPDATE</literal> statements per
+ hour is roughly the same as 5 updates per second. Each update
+ uses 72 bytes, plus 4 bytes per column * 5 columns updated,
+ plus 32 bytes per column * 5 columns — this works out to
+ 72 + 20 + 160 = 252 bytes per operation, and multiplying this
+ by 5 operation per second yields 1260 bytes per second.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 <literal role="stmt">INSERT</literal> statements per
+ hour is equivalent to 5 insert operations per second. Each
+ insert requires REDO log space of 72 bytes, plus 4 bytes per
+ record * 40 columns, plus 32 bytes per column * 40 columns,
+ which is 72 + 160 + 1280 = 1512 bytes per operation. This
+ times 5 operations per second yields 7560 bytes per second.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ So the total number of REDO log bytes being written per second is
+ approximately 0 + 360 + 1260 + 7560 = 9180 bytes. Multiplied by
+ 1800 seconds, this yields 16524000 bytes required for REDO
+ logging, or approximately 15.75 MB. The unit used for
+ <literal>NoOfFragmentLogFiles</literal> represents a set of 4
+ 16-MB log files — that is, 64 MB. Thus, the minimum value
+ (3) for this parameter is sufficient for the scenario envisioned
+ in this example, since 3 times 64 = 192 MB, or about 12 times what
+ is required; the default value of 8 (or 512 MB) is more than ample
+ in this case.
+ </para>
+
+ <para>
+ A copy of each altered table record is kept in the UNDO log. In
+ the scenario discussed above, the UNDO log would not require any
+ more space than what is provided by the default seetings. However,
+ given the size of disks, it is sensible to allocate at least 1 GB
+ for it.
+ </para>
+
+ </section>
+
+</section>
Modified: trunk/refman-5.0/mysql-cluster.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster.xml 2009-07-30 17:01:52 UTC (rev 15883)
+++ trunk/refman-5.0/mysql-cluster.xml 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 694 bytes
@@ -142,7 +142,7 @@
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="mysql-cluster-multi-computer.xml"/>
- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="mysql-cluster-configuration.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dynxml-local-mysql-cluster-configuration.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dynxml-local-mysql-cluster-optvar.xml"/>
Modified: trunk/refman-5.1/Makefile.depends
===================================================================
--- trunk/refman-5.1/mysql-cluster-configuration-core.xml (rev 0)
+++ trunk/refman-5.1/mysql-cluster-configuration-core.xml 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 31, Lines Added: 9657, Lines Deleted: 57; 380309 bytes
@@ -1345,7 +1345,7 @@
metadata/extending-mysql.idmap \
metadata/installing-core.idmap \
metadata/internationalization.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/programs-admin-util-core.idmap \
metadata/programs-using.idmap \
metadata/replication-notes.idmap \
@@ -1466,7 +1466,7 @@
metadata/installing-core.idmap \
metadata/internationalization.idmap \
metadata/language-structure-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-multi-computer.idmap \
metadata/mysql-cluster-programs-core.idmap \
metadata/news-5.1-core.idmap \
@@ -1931,6 +1931,42 @@
dynxml-local-manual-index-manprepped.xml: $(dynxml_local_manual_index_SOURCES) $(dynxml_local_manual_index_IDMAPS)
dynxml-local-manual-index-remprepped.xml: $(dynxml_local_manual_index_SOURCES) $(dynxml_local_manual_index_IDMAPS)
dynxml-local-manual-index.xml: $(dynxml_local_manual_index_INCLUDES)
+dynxml_local_mysql_cluster_configuration_INCLUDES = \
+ ../../mysqldoc/dynamic-docs/command-optvars/ndb-config-params.xml \
+ ../../mysqldoc/dynamic-docs/metadata-titles.en.xml \
+ ../common/fixedchars.ent \
+ ../common/phrases.ent \
+ ../gui-common/gui-common.ent \
+ ../mysql-monitor-2.0/version.ent \
+ ../mysql-monitor-common/enterprise.ent \
+ ../refman-common/urls.ent \
+ all-entities.ent \
+ mysql-cluster-configuration-core.xml \
+ versions.ent
+dynxml_local_mysql_cluster_configuration_IMAGES =
+dynxml_local_mysql_cluster_configuration_SOURCES = dynxml-local-mysql-cluster-configuration.xml $(dynxml_local_mysql_cluster_configuration_INCLUDES)
+dynxml_local_mysql_cluster_configuration_IDMAPS = \
+ ../ndbapi/metadata/class-ndb-cluster-connection.idmap \
+ ../ndbapi/metadata/ndb-internals.idmap \
+ ../refman-common/metadata/bug-reports.idmap \
+ metadata/dba-mysqld-server-core.idmap \
+ metadata/installing-core.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
+ metadata/mysql-cluster-disk-data.idmap \
+ metadata/mysql-cluster-interconnects.idmap \
+ metadata/mysql-cluster-limitations.idmap \
+ metadata/mysql-cluster-management.idmap \
+ metadata/mysql-cluster-optvar-core.idmap \
+ metadata/mysql-cluster-programs-core.idmap
+dynxml-local-mysql-cluster-configuration.validpure: $(dynxml_local_mysql_cluster_configuration_SOURCES)
+dynxml-local-mysql-cluster-configuration.titles: $(dynxml_local_mysql_cluster_configuration_SOURCES)
+dynxml-local-mysql-cluster-configuration.useless: $(dynxml_local_mysql_cluster_configuration_SOURCES)
+dynxml-local-mysql-cluster-configuration.valid: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration.validwarn: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration-prepped.xml: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration-manprepped.xml: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration-remprepped.xml: $(dynxml_local_mysql_cluster_configuration_SOURCES) $(dynxml_local_mysql_cluster_configuration_IDMAPS)
+dynxml-local-mysql-cluster-configuration.xml: $(dynxml_local_mysql_cluster_configuration_INCLUDES)
dynxml_local_mysql_cluster_news_combined_INCLUDES = \
../../mysqldoc/dynamic-docs/changelog/mysqld-1.xml \
../../mysqldoc/dynamic-docs/changelog/mysqld-versions.xml \
@@ -1962,7 +1998,7 @@
metadata/data-types.idmap \
metadata/dba-mysqld-server-core.idmap \
metadata/introduction.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-management.idmap \
metadata/mysql-cluster-news-core.idmap \
@@ -2014,7 +2050,7 @@
metadata/dba-mysqld-server-core.idmap \
metadata/installing-core.idmap \
metadata/introduction.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-management.idmap \
metadata/mysql-cluster-news-core.idmap \
@@ -2052,7 +2088,7 @@
dynxml_local_mysql_cluster_optvar_SOURCES = dynxml-local-mysql-cluster-optvar.xml $(dynxml_local_mysql_cluster_optvar_INCLUDES)
dynxml_local_mysql_cluster_optvar_IDMAPS = \
metadata/dba-mysqld-server-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-optvar-core.idmap \
metadata/mysql-cluster-programs-core.idmap \
metadata/mysql-cluster-replication.idmap \
@@ -2094,7 +2130,7 @@
dynxml_local_mysql_cluster_programs_IDMAPS = \
../ndbapi/metadata/ndb-errors.idmap \
../ndbapi/metadata/ndb-internals.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-disk-data.idmap \
metadata/mysql-cluster-glossary.idmap \
metadata/mysql-cluster-limitations.idmap \
@@ -2146,7 +2182,7 @@
metadata/internationalization.idmap \
metadata/introduction.idmap \
metadata/language-structure-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-interconnects.idmap \
metadata/mysql-cluster-management.idmap \
metadata/mysql-cluster-news-core.idmap \
@@ -2764,7 +2800,7 @@
metadata/information-schema.idmap \
metadata/installing-core.idmap \
metadata/internationalization.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-disk-data.idmap \
metadata/mysql-cluster-interconnects.idmap \
metadata/mysql-cluster-limitations.idmap \
@@ -3034,6 +3070,7 @@
../../mysqldoc/dynamic-docs/command-optvars/mysqlimport.xml \
../../mysqldoc/dynamic-docs/command-optvars/mysqlshow.xml \
../../mysqldoc/dynamic-docs/command-optvars/mysqlslap.xml \
+ ../../mysqldoc/dynamic-docs/command-optvars/ndb-config-params.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_common.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_config.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_error_reporter.xml \
@@ -3526,6 +3563,7 @@
dynxml-local-manual-index-stmt.xml \
dynxml-local-manual-index-sysvar.xml \
dynxml-local-manual-index.xml \
+ dynxml-local-mysql-cluster-configuration.xml \
dynxml-local-mysql-cluster-news-combined.xml \
dynxml-local-mysql-cluster-news.xml \
dynxml-local-mysql-cluster-optvar.xml \
@@ -3579,7 +3617,7 @@
monitor-refman-chapter-aspec.xml.mem-query-analyzer.none.section.xml \
monitor-refman-chapter-aspec.xml.mem-replication.none.section.xml \
monitor-refman-chapter-base.xml \
- mysql-cluster-configuration.xml \
+ mysql-cluster-configuration-core.xml \
mysql-cluster-disk-data.xml \
mysql-cluster-glossary.xml \
mysql-cluster-interconnects.xml \
@@ -3902,6 +3940,7 @@
../mysql-monitor-common/metadata/install-agent-core.idmap \
../mysql-monitor-common/metadata/install-unattended-core.idmap \
../mysql-monitor-common/metadata/install-upgrades-core.idmap \
+ ../mysql-monitor-common/metadata/mem-reference-core.idmap \
../ndbapi/metadata/class-dictionary.idmap \
../ndbapi/metadata/class-ndb-cluster-connection.idmap \
../ndbapi/metadata/class-ndb.idmap \
@@ -3993,7 +4032,7 @@
metadata/internationalization.idmap \
metadata/introduction.idmap \
metadata/language-structure-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-disk-data.idmap \
metadata/mysql-cluster-glossary.idmap \
metadata/mysql-cluster-interconnects.idmap \
@@ -4449,38 +4488,18 @@
monitor-refman-chapter-manprepped.xml: $(monitor_refman_chapter_SOURCES) $(monitor_refman_chapter_IDMAPS)
monitor-refman-chapter-remprepped.xml: $(monitor_refman_chapter_SOURCES) $(monitor_refman_chapter_IDMAPS)
-mysql_cluster_configuration_INCLUDES = \
- ../common/fixedchars.ent \
- ../common/phrases.ent \
- ../gui-common/gui-common.ent \
- ../mysql-monitor-2.0/version.ent \
- ../mysql-monitor-common/enterprise.ent \
- ../refman-common/urls.ent \
- all-entities.ent \
- versions.ent
-mysql_cluster_configuration_IMAGES =
-mysql_cluster_configuration_SOURCES = mysql-cluster-configuration.xml $(mysql_cluster_configuration_INCLUDES)
-mysql_cluster_configuration_IDMAPS = \
- ../ndbapi/metadata/class-ndb-cluster-connection.idmap \
- ../ndbapi/metadata/ndb-internals.idmap \
- ../refman-common/metadata/bug-reports.idmap \
- metadata/dba-mysqld-server-core.idmap \
- metadata/installing-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
- metadata/mysql-cluster-disk-data.idmap \
- metadata/mysql-cluster-interconnects.idmap \
- metadata/mysql-cluster-limitations.idmap \
- metadata/mysql-cluster-management.idmap \
- metadata/mysql-cluster-optvar-core.idmap \
- metadata/mysql-cluster-programs-core.idmap
-mysql-cluster-configuration.validpure: $(mysql_cluster_configuration_SOURCES)
-mysql-cluster-configuration.titles: $(mysql_cluster_configuration_SOURCES)
-mysql-cluster-configuration.useless: $(mysql_cluster_configuration_SOURCES)
-mysql-cluster-configuration.valid: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
-mysql-cluster-configuration.validwarn: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
-mysql-cluster-configuration-prepped.xml: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
-mysql-cluster-configuration-manprepped.xml: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
-mysql-cluster-configuration-remprepped.xml: $(mysql_cluster_configuration_SOURCES) $(mysql_cluster_configuration_IDMAPS)
+mysql_cluster_configuration_core_INCLUDES =
+mysql_cluster_configuration_core_IMAGES =
+mysql_cluster_configuration_core_SOURCES = mysql-cluster-configuration-core.xml $(mysql_cluster_configuration_core_INCLUDES)
+mysql_cluster_configuration_core_IDMAPS =
+mysql-cluster-configuration-core.validpure: $(mysql_cluster_configuration_core_SOURCES)
+mysql-cluster-configuration-core.titles: $(mysql_cluster_configuration_core_SOURCES)
+mysql-cluster-configuration-core.useless: $(mysql_cluster_configuration_core_SOURCES)
+mysql-cluster-configuration-core.valid: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
+mysql-cluster-configuration-core.validwarn: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
+mysql-cluster-configuration-core-prepped.xml: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
+mysql-cluster-configuration-core-manprepped.xml: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
+mysql-cluster-configuration-core-remprepped.xml: $(mysql_cluster_configuration_core_SOURCES) $(mysql_cluster_configuration_core_IDMAPS)
mysql_cluster_disk_data_INCLUDES = \
../common/fixedchars.ent \
@@ -4496,7 +4515,7 @@
mysql_cluster_disk_data_IDMAPS = \
metadata/data-types.idmap \
metadata/information-schema.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-disk-data.idmap \
metadata/sql-syntax-data-definition.idmap
mysql-cluster-disk-data.validpure: $(mysql_cluster_disk_data_SOURCES)
@@ -4520,7 +4539,7 @@
mysql_cluster_glossary_IMAGES =
mysql_cluster_glossary_SOURCES = mysql-cluster-glossary.xml $(mysql_cluster_glossary_INCLUDES)
mysql_cluster_glossary_IDMAPS = \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-disk-data.idmap \
metadata/mysql-cluster-interconnects.idmap \
metadata/mysql-cluster-management.idmap \
@@ -4547,7 +4566,7 @@
mysql_cluster_interconnects_IMAGES =
mysql_cluster_interconnects_SOURCES = mysql-cluster-interconnects.xml $(mysql_cluster_interconnects_INCLUDES)
mysql_cluster_interconnects_IDMAPS = \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-interconnects.idmap
mysql-cluster-interconnects.validpure: $(mysql_cluster_interconnects_SOURCES)
mysql-cluster-interconnects.titles: $(mysql_cluster_interconnects_SOURCES)
@@ -4572,7 +4591,7 @@
mysql_cluster_limitations_IDMAPS = \
../refman-common/metadata/bug-reports.idmap \
metadata/data-types.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-disk-data.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-management.idmap \
@@ -4608,7 +4627,7 @@
../ndbapi/metadata/ndb-internals.idmap \
metadata/dba-mysqld-server-core.idmap \
metadata/information-schema.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-management.idmap \
metadata/mysql-cluster-programs-core.idmap \
metadata/mysql-cluster-security.idmap \
@@ -4638,7 +4657,7 @@
mysql_cluster_multi_computer_SOURCES = mysql-cluster-multi-computer.xml $(mysql_cluster_multi_computer_INCLUDES)
mysql_cluster_multi_computer_IDMAPS = \
metadata/installing-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-disk-data.idmap \
metadata/mysql-cluster-interconnects.idmap \
metadata/mysql-cluster-management.idmap \
@@ -4714,7 +4733,7 @@
mysql_cluster_overview_IDMAPS = \
../ndbapi/metadata/getting-started.idmap \
../ndbapi/metadata/mgm-api.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-management.idmap \
metadata/mysql-cluster-overview.idmap \
@@ -4805,7 +4824,7 @@
../ndbapi/metadata/interface-ndbrecord.idmap \
../ndbapi/metadata/ndb-internals.idmap \
metadata/installing-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-disk-data.idmap \
metadata/mysql-cluster-limitations.idmap \
metadata/mysql-cluster-management.idmap \
@@ -4845,7 +4864,7 @@
mysql_cluster_security_SOURCES = mysql-cluster-security.xml $(mysql_cluster_security_INCLUDES)
mysql_cluster_security_IDMAPS = \
metadata/dba-security-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-programs-core.idmap \
metadata/mysql-cluster-security.idmap
mysql-cluster-security.validpure: $(mysql_cluster_security_SOURCES)
@@ -4876,7 +4895,7 @@
mysql_cluster_upgrade_downgrade_SOURCES = mysql-cluster-upgrade-downgrade.xml $(mysql_cluster_upgrade_downgrade_INCLUDES)
mysql_cluster_upgrade_downgrade_IDMAPS = \
metadata/installing-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-multi-computer.idmap \
metadata/mysql-cluster-replication.idmap \
metadata/mysql-cluster-upgrade-downgrade.idmap \
@@ -4895,6 +4914,7 @@
../../mysqldoc/dynamic-docs/changelog/mysqld-versions.xml \
../../mysqldoc/dynamic-docs/changelog/mysqld.xml \
../../mysqldoc/dynamic-docs/command-optvars/mysqld.xml \
+ ../../mysqldoc/dynamic-docs/command-optvars/ndb-config-params.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_common.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_config.xml \
../../mysqldoc/dynamic-docs/command-optvars/ndb_error_reporter.xml \
@@ -4931,11 +4951,12 @@
../refman-common/images/published/rolling-restarts.png \
../refman-common/urls.ent \
all-entities.ent \
+ dynxml-local-mysql-cluster-configuration.xml \
dynxml-local-mysql-cluster-news-combined.xml \
dynxml-local-mysql-cluster-news.xml \
dynxml-local-mysql-cluster-optvar.xml \
dynxml-local-mysql-cluster-programs.xml \
- mysql-cluster-configuration.xml \
+ mysql-cluster-configuration-core.xml \
mysql-cluster-disk-data.xml \
mysql-cluster-glossary.xml \
mysql-cluster-interconnects.xml \
@@ -4996,7 +5017,7 @@
metadata/information-schema.idmap \
metadata/installing-core.idmap \
metadata/introduction.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-disk-data.idmap \
metadata/mysql-cluster-glossary.idmap \
metadata/mysql-cluster-interconnects.idmap \
@@ -5447,7 +5468,7 @@
metadata/dba-mysqld-server-core.idmap \
metadata/dba-user-management-core.idmap \
metadata/installing-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-multi-computer.idmap \
metadata/programs-using.idmap \
metadata/sql-syntax-server-administration.idmap
@@ -5509,7 +5530,7 @@
metadata/installing-core.idmap \
metadata/internationalization.idmap \
metadata/language-structure-core.idmap \
- metadata/mysql-cluster-configuration.idmap \
+ metadata/mysql-cluster-configuration-core.idmap \
metadata/mysql-cluster-multi-computer.idmap \
metadata/mysql-cluster.idmap \
metadata/optimization.idmap \
Copied: trunk/refman-5.1/mysql-cluster-configuration-core.xml (from rev 15880, trunk/refman-5.1/mysql-cluster-configuration.xml)
===================================================================
--- trunk/refman-5.1/mysql-cluster-configuration-core.xml (rev 0)
+++ trunk/refman-5.1/mysql-cluster-configuration-core.xml 2009-07-30 19:12:22 UTC (rev 15884)
@@ -0,0 +1,9579 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY % all.entities SYSTEM "all-entities.ent">
+ %all.entities;
+]>
+<section id="mysql-cluster-configuration">
+
+ <title>MySQL Cluster Configuration</title>
+
+ <indexterm>
+ <primary>configuring MySQL Cluster</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <remark role="dynamic-dependency-list"/>
+
+ <para>
+ A MySQL server that is part of a MySQL Cluster differs in one chief
+ respect from a normal (nonclustered) MySQL server, in that it
+ employs the <literal role="se">NDBCLUSTER</literal> storage engine.
+ This engine is also referred to simply as
+ <literal role="se">NDB</literal>, and the two forms of the name are
+ synonymous.
+ </para>
+
+ <para>
+ To avoid unnecessary allocation of resources, the server is
+ configured by default with the <literal role="se">NDB</literal>
+ storage engine disabled. To enable <literal role="se">NDB</literal>,
+ you must modify the server's <filename>my.cnf</filename>
+ configuration file, or start the server with the
+ <option role="mysqld">--ndbcluster</option> option.
+ </para>
+
+ <para>
+ For more information about
+ <option role="mysqld">--ndbcluster</option> and other MySQL server
+ options specific to MySQL Cluster, see
+ <xref linkend="mysql-cluster-program-options-mysqld"/>.
+ </para>
+
+ <para>
+ The MySQL server is a part of the cluster, so it also must know how
+ to access an MGM node to obtain the cluster configuration data. The
+ default behavior is to look for the MGM node on
+ <literal>localhost</literal>. However, should you need to specify
+ that its location is elsewhere, this can be done in
+ <filename>my.cnf</filename> or on the MySQL server command line.
+ Before the <literal role="se">NDB</literal> storage engine can be
+ used, at least one MGM node must be operational, as well as any
+ desired data nodes.
+ </para>
+
+ <section id="mysql-cluster-building">
+
+ <title>Building MySQL Cluster from Source Code</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>compiling from source</secondary>
+ </indexterm>
+
+ <para>
+ <literal role="se">NDBCLUSTER</literal>, the MySQL Cluster storage
+ engine, is available in binary distributions for Linux, Mac OS X,
+ and Solaris. We are working to make Cluster run on all operating
+ systems supported by MySQL, including Windows. Beginning with
+ MySQL Cluster NDB 6.4.0, there is experimental support for MySQL
+ Cluster on Windows.
+ </para>
+
+ <para>
+ If you choose to build from a source tarball or one of the MySQL
+ Cluster public development trees, be sure to use the
+ <option>--with-ndbcluster</option> option when running
+ <command>configure</command> (if building from source on Microsoft
+ Windows platforms, use the
+ <literal>WITH_NDBCLUSTER_STORAGE_ENGINE</literal> option with
+ <command>configure.js</command>). You can also use the
+ <command>BUILD/compile-pentium-max</command> build scripts
+ provided for most Unix platforms. Note that this script includes
+ OpenSSL, so you must either have or obtain OpenSSL to build
+ successfully, or else modify
+ <command>compile-pentium-max</command> to exclude this
+ requirement. Of course, you can also just follow the standard
+ instructions for compiling your own binaries, and then perform the
+ usual tests and installation procedure. See
+ <xref linkend="installing-source-tree"/>.
+ </para>
+
+ <para>
+ <command>BUILD/compile-pentium-max</command> also includes
+ OpenSSL, so you must either have or obtain OpenSSL to build
+ successfully, or else modify
+ <command>compile-pentium-max</command> to exclude this
+ requirement. Of course, you can also just follow the standard
+ instructions for compiling your own binaries, and then perform the
+ usual tests and installation procedure. See
+ <xref linkend="installing-source-tree"/>.
+ </para>
+
+ <para>
+ You should also note that <command>compile-pentium-max</command>
+ installs MySQL to the directory
+ <filename>/usr/local/mysql</filename>, placing all MySQL Cluster
+ executables, scripts, databases, and support files in
+ subdirectories under this directory. If this is not what you
+ desire, be sure to modify the script accordingly.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-installing">
+
+ <title>Installing MySQL Cluster Software</title>
+
+ <indexterm>
+ <primary>installing MySQL Cluster</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>installation</secondary>
+ </indexterm>
+
+ <para>
+ In the next few sections, we assume that you are already familiar
+ with installing MySQL, and here we cover only the differences
+ between configuring MySQL Cluster and configuring MySQL without
+ clustering. (See <xref linkend="installing"/>, if you require more
+ information about the latter.)
+ </para>
+
+ <para>
+ You will find Cluster configuration easiest if you have already
+ have all management and data nodes running first; this is likely
+ to be the most time-consuming part of the configuration. Editing
+ the <filename>my.cnf</filename> file is fairly straightforward,
+ and this section will cover only any differences from configuring
+ MySQL without clustering.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-quick">
+
+ <title>Quick Test Setup of MySQL Cluster</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>"quick" configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>starting</secondary>
+ </indexterm>
+
+ <para>
+ To familiarize you with the basics, we will describe the simplest
+ possible configuration for a functional MySQL Cluster. After this,
+ you should be able to design your desired setup from the
+ information provided in the other relevant sections of this
+ chapter.
+ </para>
+
+ <para>
+ First, you need to create a configuration directory such as
+ <filename>/var/lib/mysql-cluster</filename>, by executing the
+ following command as the system <literal>root</literal> user:
+ </para>
+
+<programlisting>
+shell> <userinput>mkdir /var/lib/mysql-cluster</userinput>
+</programlisting>
+
+ <para>
+ In this directory, create a file named
+ <filename>config.ini</filename> that contains the following
+ information. Substitute appropriate values for
+ <literal>HostName</literal> and <literal>DataDir</literal> as
+ necessary for your system.
+ </para>
+
+<programlisting>
+# file "config.ini" - showing minimal setup consisting of 1 data node,
+# 1 management server, and 3 MySQL servers.
+# The empty default sections are not required, and are shown only for
+# the sake of completeness.
+# Data nodes must provide a hostname but MySQL Servers are not required
+# to do so.
+# If you don't know the hostname for your machine, use localhost.
+# The DataDir parameter also has a default value, but it is recommended to
+# set it explicitly.
+# Note: [db], [api], and [mgm] are aliases for [ndbd], [mysqld], and [ndb_mgmd],
+# respectively. [db] is deprecated and should not be used in new installations.
+
+[ndbd default]
+NoOfReplicas= 1
+
+[mysqld default]
+[ndb_mgmd default]
+[tcp default]
+
+[ndb_mgmd]
+HostName= myhost.example.com
+
+[ndbd]
+HostName= myhost.example.com
+DataDir= /var/lib/mysql-cluster
+
+[mysqld]
+[mysqld]
+[mysqld]
+</programlisting>
+
+ <para>
+ You can now start the <command>ndb_mgmd</command> management
+ server. By default, it attempts to read the
+ <filename>config.ini</filename> file in its current working
+ directory, so change location into the directory where the file is
+ located and then invoke <command>ndb_mgmd</command>:
+ </para>
+
+<programlisting>
+shell> <userinput>cd /var/lib/mysql-cluster</userinput>
+shell> <userinput>ndb_mgmd</userinput>
+</programlisting>
+
+ <para>
+ Then start a single data node by running <command>ndbd</command>:
+ </para>
+
+<programlisting>
+shell> <userinput>ndbd</userinput>
+</programlisting>
+
+ <para>
+ For command-line options which can be used when starting
+ <command>ndbd</command>, see
+ <xref linkend="mysql-cluster-program-options-common"/>.
+ </para>
+
+ <para>
+ By default, <command>ndbd</command> looks for the management
+ server at <literal>localhost</literal> on port 1186.
+ </para>
+
+ <note>
+ <para>
+ If you have installed MySQL from a binary tarball, you will need
+ to specify the path of the <command>ndb_mgmd</command> and
+ <command>ndbd</command> servers explicitly. (Normally, these
+ will be found in <filename>/usr/local/mysql/bin</filename>.)
+ </para>
+ </note>
+
+ <para>
+ Finally, change location to the MySQL data directory (usually
+ <filename>/var/lib/mysql</filename> or
+ <filename>/usr/local/mysql/data</filename>), and make sure that
+ the <filename>my.cnf</filename> file contains the option necessary
+ to enable the NDB storage engine:
+ </para>
+
+<programlisting>
+[mysqld]
+ndbcluster
+</programlisting>
+
+ <para>
+ You can now start the MySQL server as usual:
+ </para>
+
+<programlisting>
+shell> <userinput>mysqld_safe --user=mysql &</userinput>
+</programlisting>
+
+ <para>
+ Wait a moment to make sure the MySQL server is running properly.
+ If you see the notice <literal>mysql ended</literal>, check the
+ server's <filename>.err</filename> file to find out what went
+ wrong.
+ </para>
+
+ <para>
+ If all has gone well so far, you now can start using the cluster.
+ Connect to the server and verify that the
+ <literal role="se">NDBCLUSTER</literal> storage engine is enabled:
+ </para>
+
+<programlisting>
+shell> <userinput>mysql</userinput>
+Welcome to the MySQL monitor. Commands end with ; or \g.
+Your MySQL connection id is 1 to server version: ¤t-version;
+
+Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
+
+mysql> <userinput>SHOW ENGINES\G</userinput>
+...
+*************************** 12. row ***************************
+Engine: NDBCLUSTER
+Support: YES
+Comment: Clustered, fault-tolerant, memory-based tables
+*************************** 13. row ***************************
+Engine: NDB
+Support: YES
+Comment: Alias for NDBCLUSTER
+...
+</programlisting>
+
+ <para>
+ The row numbers shown in the preceding example output may be
+ different from those shown on your system, depending upon how your
+ server is configured.
+ </para>
+
+ <para>
+ Try to create an <literal role="se">NDBCLUSTER</literal> table:
+ </para>
+
+<programlisting>
+shell> <userinput>mysql</userinput>
+mysql> <userinput>USE test;</userinput>
+Database changed
+
+mysql> <userinput>CREATE TABLE ctest (i INT) ENGINE=NDBCLUSTER;</userinput>
+Query OK, 0 rows affected (0.09 sec)
+
+mysql> <userinput>SHOW CREATE TABLE ctest \G</userinput>
+*************************** 1. row ***************************
+ Table: ctest
+Create Table: CREATE TABLE `ctest` (
+ `i` int(11) default NULL
+) ENGINE=ndbcluster DEFAULT CHARSET=latin1
+1 row in set (0.00 sec)
+</programlisting>
+
+ <para>
+ To check that your nodes were set up properly, start the
+ management client:
+ </para>
+
+<programlisting>
+shell> <userinput>ndb_mgm</userinput>
+</programlisting>
+
+ <indexterm>
+ <primary>SHOW</primary>
+ <secondary>in MySQL Cluster management client</secondary>
+ </indexterm>
+
+ <para>
+ Use the <command>SHOW</command> command from within the management
+ client to obtain a report on the cluster's status:
+ </para>
+
+<programlisting>
+ndb_mgm> <userinput>SHOW</userinput>
+Cluster Configuration
+---------------------
+[ndbd(NDB)] 1 node(s)
+id=2 @127.0.0.1 (Version: 3.5.3, Nodegroup: 0, Master)
+
+[ndb_mgmd(MGM)] 1 node(s)
+id=1 @127.0.0.1 (Version: 3.5.3)
+
+[mysqld(API)] 3 node(s)
+id=3 @127.0.0.1 (Version: 3.5.3)
+id=4 (not connected, accepting connect from any host)
+id=5 (not connected, accepting connect from any host)
+</programlisting>
+
+ <para>
+ At this point, you have successfully set up a working MySQL
+ Cluster. You can now store data in the cluster by using any table
+ created with <literal>ENGINE=NDBCLUSTER</literal> or its alias
+ <literal>ENGINE=NDB</literal>.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-config-file">
+
+ <title>MySQL Cluster Configuration Files</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration files</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>my.cnf</primary>
+ <secondary>and MySQL Cluster</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>config.ini (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ Configuring MySQL Cluster requires working with two files:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <filename>my.cnf</filename>: Specifies options for all MySQL
+ Cluster executables. This file, with which you should be
+ familiar with from previous work with MySQL, must be
+ accessible by each executable running in the cluster.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>config.ini</filename>: This file, sometimes known as
+ the <firstterm>global configuration file</firstterm>, is read
+ only by the MySQL Cluster management server, which then
+ distributes the information contained therein to all processes
+ participating in the cluster. <filename>config.ini</filename>
+ contains a description of each node involved in the cluster.
+ This includes configuration parameters for data nodes and
+ configuration parameters for connections between all nodes in
+ the cluster. For a quick reference to the sections that can
+ appear in this file, and what sorts of configuration
+ parameters may be placed in each section, see
+ <link linkend="mysql-cluster-config-ini-sections">Sections of
+ the <filename>config.ini</filename> File</link>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Caching of configuration data</title>
+
+ <para>
+ Beginning with MySQL Cluster NDB 6.4.0, MySQL Cluster uses
+ <firstterm>stateful configuration</firstterm>. The global
+ configuration file is no longer read every time the management
+ server is restarted. Instead, the management server caches the
+ configuration the first time it is started, and thereafter, the
+ global confiuration file is read only when one of the following
+ items is true:
+
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>The management server is started using <option>--initial</option> option</title>
+
+ <para>
+ In this case, the global configuration file is re-read,
+ any existing cache files are deleted, and the management
+ server creates a new configuration cache.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>The management server is started using <option>--reload</option> option</title>
+
+ <para>
+ In this case, the management server compares its cache
+ with the global configuration file. If they differ, the
+ management server creates a new configuration cache; any
+ existing configuration cache is preserved, but not used.
+ If the management server's cache and the global
+ configuration file contain the same configuration data,
+ then the existing cache is used, and no new cache is
+ created.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>No configuration cache is found</title>
+
+ <para>
+ In this case, the management server reads the global
+ configuration file and creates a cache containing the
+ same configuration data as found in the file.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Configuration cache files</title>
+
+ <para>
+ Beginning with MySQL Cluster 6.4.0, the management server by
+ default creates configuration cache files in a directory named
+ <filename>mysql-cluster</filename> in the MySQL installation
+ directory. (If you build MySQL Cluster from source on a Unix
+ system, the default location is
+ <filename>/usr/local/mysql-cluster</filename>.) This can be
+ overridden at run time by starting the management server with
+ the <option>--configdir</option> option. Configuration cache
+ files are binary files named according to the pattern
+ <filename>ndb_<replaceable>node_id</replaceable>_config.bin.<replaceable>seq_id</replaceable></filename>,
+ where <replaceable>node_id</replaceable> is the management
+ server's node ID in the cluster, and
+ <replaceable>seq_id</replaceable> is a cache idenitifer. Cache
+ files are numbered sequentially using
+ <replaceable>seq_id</replaceable>, in the order in which they
+ are created. The management server uses the latest cache file as
+ determined by the <replaceable>seq_id</replaceable>.
+ </para>
+
+ </formalpara>
+
+ <note>
+ <para>
+ It is possible to roll back to a previous configuration by
+ deleting later configuration cache files, or by renaming an
+ earlier cache file so that it has a higher
+ <replaceable>seq_id</replaceable>. However, since configuration
+ cache files are written in a binary format, you should not
+ attempt to edit their contents by hand.
+ </para>
+ </note>
+
+ <para>
+ For more information about the <option>--configdir</option>,
+ <option>--initial</option>, and <option>--reload</option> options
+ for the MySQL Cluster management server, see
+ <xref linkend="mysql-cluster-program-options-ndb-mgmd"/>.
+ </para>
+
+ <para>
+ We are continuously making improvements in Cluster configuration
+ and attempting to simplify this process. Although we strive to
+ maintain backward compatibility, there may be times when introduce
+ an incompatible change. In such cases we will try to let Cluster
+ users know in advance if a change is not backward compatible. If
+ you find such a change and we have not documented it, please
+ report it in the MySQL bugs database using the instructions given
+ in <xref linkend="bug-reports"/>.
+ </para>
+
+ <section id="mysql-cluster-config-example">
+
+ <title>MySQL Cluster Configuration — Basic Example</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration (example)</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>my.cnf</primary>
+ <secondary>and MySQL Cluster</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>config.ini (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ To support MySQL Cluster, you will need to update
+ <filename>my.cnf</filename> as shown in the following example.
+ You may also specify these parameters on the command line when
+ invoking the executables.
+ </para>
+
+ <note>
+ <para>
+ The options shown here should not be confused with those that
+ are used in <filename>config.ini</filename> global
+ configuration files. Global configuration options are
+ discussed later in this section.
+ </para>
+ </note>
+
+<programlisting>
+# my.cnf
+# example additions to my.cnf for MySQL Cluster
+# (valid in MySQL ¤t-series;)
+
+# enable ndbcluster storage engine, and provide connectstring for
+# management server host (default port is 1186)
+[mysqld]
+ndbcluster
+ndb-connectstring=ndb_mgmd.mysql.com
+
+
+# provide connectstring for management server host (default port: 1186)
+[ndbd]
+connect-string=ndb_mgmd.mysql.com
+
+# provide connectstring for management server host (default port: 1186)
+[ndb_mgm]
+connect-string=ndb_mgmd.mysql.com
+
+# provide location of cluster configuration file
+[ndb_mgmd]
+config-file=/etc/config.ini
+</programlisting>
+
+ <para>
+ (For more information on connectstrings, see
+ <xref linkend="mysql-cluster-connectstring"/>.)
+ </para>
+
+<programlisting>
+# my.cnf
+# example additions to my.cnf for MySQL Cluster
+# (will work on all versions)
+
+# enable ndbcluster storage engine, and provide connectstring for management
+# server host to the default port 1186
+[mysqld]
+ndbcluster
+ndb-connectstring=ndb_mgmd.mysql.com:1186
+</programlisting>
+
+ <important>
+ <para>
+ Once you have started a <command>mysqld</command> process with
+ the <literal role="se">NDBCLUSTER</literal> and
+ <literal>ndb-connectstring</literal> parameters in the
+ <literal>[mysqld]</literal> in the <filename>my.cnf</filename>
+ file as shown previously, you cannot execute any
+ <literal role="stmt">CREATE TABLE</literal> or
+ <literal role="stmt">ALTER TABLE</literal> statements without
+ having actually started the cluster. Otherwise, these
+ statements will fail with an error. <emphasis>This is by
+ design</emphasis>.
+ </para>
+ </important>
+
+ <para>
+ You may also use a separate <literal>[mysql_cluster]</literal>
+ section in the cluster <filename>my.cnf</filename> file for
+ settings to be read and used by all executables:
+ </para>
+
+<programlisting>
+# cluster-specific settings
+[mysql_cluster]
+ndb-connectstring=ndb_mgmd.mysql.com:1186
+</programlisting>
+
+ <para>
+ For additional <literal role="se">NDB</literal> variables that
+ can be set in the <filename>my.cnf</filename> file, see
+ <xref linkend="mysql-cluster-system-variables"/>.
+ </para>
+
+ <para>
+ The MySQL Cluster global configuration file is named
+ <filename>config.ini</filename> by default. It is read by
+ <command>ndb_mgmd</command> at startup and can be placed
+ anywhere. Its location and name are specified by using
+ <option>--config-file=<replaceable>path_name</replaceable></option>
+ on the <command>ndb_mgmd</command> command line. If the
+ configuration file is not specified, <command>ndb_mgmd</command>
+ by default tries to read a file named
+ <filename>config.ini</filename> located in the current working
+ directory.
+ </para>
+
+ <para>
+ The global configuration file for MySQL Cluster uses INI format,
+ which consists of sections preceded by section headings
+ (surrounded by square brackets), followed by the appropriate
+ parameter names and values. One deviation from the standard INI
+ format is that the parameter name and value can be separated by
+ a colon (<quote><literal>:</literal></quote>) as well as the
+ equals sign (<quote><literal>=</literal></quote>); however, the
+ equals sign is preferred. Another deviation is that sections are
+ not uniquely identified by section name. Instead, unique
+ sections (such as two different nodes of the same type) are
+ identified by a unique ID specified as a parameter within the
+ section.
+ </para>
+
+ <para>
+ Default values are defined for most parameters, and can also be
+ specified in <filename>config.ini</filename>.
+ (<emphasis>Exception</emphasis>: The
+ <literal>NoOfReplicas</literal> configuration parameter has no
+ default value, and must always be specified explicitly in the
+ <literal>[ndbd default]</literal> section.) To create a default
+ value section, simply add the word <literal>default</literal> to
+ the section name. For example, an <literal>[ndbd]</literal>
+ section contains parameters that apply to a particular data
+ node, whereas an <literal>[ndbd default]</literal> section
+ contains parameters that apply to all data nodes. Suppose that
+ all data nodes should use the same data memory size. To
+ configure them all, create an <literal>[ndbd default]</literal>
+ section that contains a <literal>DataMemory</literal> line to
+ specify the data memory size.
+ </para>
+
+ <para>
+ The global configuration file must define the computers and
+ nodes involved in the cluster and on which computers these nodes
+ are located. An example of a simple configuration file for a
+ cluster consisting of one management server, two data nodes and
+ two MySQL servers is shown here:
+ </para>
+
+<programlisting>
+# file "config.ini" - 2 data nodes and 2 SQL nodes
+# This file is placed in the startup directory of ndb_mgmd (the
+# management server)
+# The first MySQL Server can be started from any host. The second
+# can be started only on the host mysqld_5.mysql.com
+
+[ndbd default]
+NoOfReplicas= 2
+DataDir= /var/lib/mysql-cluster
+
+[ndb_mgmd]
+Hostname= ndb_mgmd.mysql.com
+DataDir= /var/lib/mysql-cluster
+
+[ndbd]
+HostName= ndbd_2.mysql.com
+
+[ndbd]
+HostName= ndbd_3.mysql.com
+
+[mysqld]
+[mysqld]
+HostName= mysqld_5.mysql.com
+</programlisting>
+
+ <note>
+ <para>
+ The preceding example is intended as a minimal starting
+ configuration for purposes of familiarization with MySQL
+ Cluster, and is almost certain not to be sufficient for
+ production settings. See
+ <xref linkend="mysql-cluster-config-starting"/>, which
+ provides more complete example starting configurations for use
+ with MySQL Cluster NDB 6.2 and newer versions of MySQL
+ Cluster.
+ </para>
+ </note>
+
+ <para>
+ Each node has its own section in the
+ <filename>config.ini</filename> file. For example, this cluster
+ has two data nodes, so the preceding configuration file contains
+ two <literal>[ndbd]</literal> sections defining these nodes.
+ </para>
+
+ <note>
+ <para>
+ Do not place comments on the same line as a section heading in
+ the <filename>config.ini</filename> file; this causes the
+ management server not to start because it cannot parse the
+ configuration file in such cases.
+ </para>
+ </note>
+
+ <para id="mysql-cluster-config-ini-sections">
+ <emphasis role="bold">Sections of the
+ <filename>config.ini</filename> File</emphasis>
+ </para>
+
+ <para>
+ There are six different sections that you can use in the
+ <filename>config.ini</filename> configuration file, as described
+ in the following list:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>[computer]</literal>: Defines cluster hosts. This
+ is not required to configure a viable MySQL Cluster, but be
+ may used as a convenience when setting up a large cluster.
+ See <xref linkend="mysql-cluster-computer-definition"/>, for
+ more information.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[ndbd]</literal>: Defines a cluster data node
+ (<command>ndbd</command> process). See
+ <xref linkend="mysql-cluster-ndbd-definition"/>, for
+ details.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[mysqld]</literal>: Defines the cluster's MySQL
+ server nodes (also called SQL or API nodes). For a
+ discussion of SQL node configuration, see
+ <xref linkend="mysql-cluster-api-definition"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[mgm]</literal> or <literal>[ndb_mgmd]</literal>:
+ Defines a cluster management server (MGM) node. For
+ information concerning the configuration of MGM nodes, see
+ <xref linkend="mysql-cluster-mgm-definition"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[tcp]</literal>: Defines a TCP/IP connection
+ between cluster nodes, with TCP/IP being the default
+ connection protocol. Normally, <literal>[tcp]</literal> or
+ <literal>[tcp default]</literal> sections are not required
+ to set up a MySQL Cluster, as the cluster handles this
+ automatically; however, it may be necessary in some
+ situations to override the defaults provided by the cluster.
+ See <xref linkend="mysql-cluster-tcp-definition"/>, for
+ information about available TCP/IP configuration parameters
+ and how to use them. (You may also find
+ <xref linkend="mysql-cluster-tcp-definition-direct"/> to be
+ of interest in some cases.)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[shm]</literal>: Defines shared-memory connections
+ between nodes. In MySQL ¤t-series;, it is enabled by
+ default, but should still be considered experimental. For a
+ discussion of SHM interconnects, see
+ <xref linkend="mysql-cluster-shm-definition"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>[sci]</literal>:Defines <firstterm>Scalable
+ Coherent Interface</firstterm> connections between cluster
+ data nodes. Such connections require software which, while
+ freely available, is not part of the MySQL Cluster
+ distribution, as well as specialised hardware. See
+ <xref linkend="mysql-cluster-sci-definition"/> for detailed
+ information about SCI interconnects.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ You can define <literal>default</literal> values for each
+ section. All Cluster parameter names are case-insensitive, which
+ differs from parameters specified in <filename>my.cnf</filename>
+ or <filename>my.ini</filename> files.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-config-starting">
+
+ <title>Recommended Starting Configurations for MySQL Cluster NDB 6.2 and Later</title>
+
+ <para>
+ Achieving the best performance from a MySQL Cluster depends on a
+ number of factors including the following:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ MySQL Cluster software version
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Numbers of data nodes and SQL nodes
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Hardware
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Operating system
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Amount of data to be stored
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Size and type of load under which the cluster is to operate
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ Therefore, obtaining an optimum configuration is likely to be an
+ iterative process, the outcome of which can vary widely with the
+ specifics of each MySQL Cluster deployment. Changes in
+ configuration are also likely to be indicated when changes are
+ made in the platform on which the cluster is run, or in
+ applications that use the MySQL Cluster's data. For these
+ reasons, it is not possible to offer a single configuration that
+ is ideal for all usage scenarios. However, in this section, we
+ provide recommended base configurations for MySQL Cluster NDB
+ 6.2 and 6.3 that can serve as reasonable starting points.
+ </para>
+
+ <formalpara>
+
+ <title>Starting configuration for MySQL Cluster NDB 6.2</title>
+
+ <para>
+ The following is a recommended starting point for configuring
+ a cluster running MySQL Cluster NDB 6.2.
+ </para>
+
+ </formalpara>
+
+<programlisting>
+# TCP PARAMETERS
+
+[tcp default]
+<link linkend="ndbparam-tcp-sendbuffermemory">SendBufferMemory</link>=2M
+<link linkend="ndbparam-tcp-receivebuffermemory">ReceiveBufferMemory</link>=2M
+
+# Increasing the sizes of these 2 buffers beyond the default values
+# helps prevent bottlenecks due to slow disk I/O.
+
+# MANAGEMENT NODE PARAMETERS
+
+[ndb_mgmd default]
+<link linkend="ndbparam-mgm-datadir">DataDir</link>=<replaceable>path/to/management/server/data/directory</replaceable>
+
+# It is possible to use a different data directory for each management
+# server, but for ease of administration it is preferable to be
+# consistent.
+
+[ndb_mgmd]
+<link linkend="ndbparam-mgm-hostname">HostName</link>=<replaceable>management-server-1-hostname</replaceable>
+# <link linkend="ndbparam-mgm-id">Id</link>=<replaceable>management-server-A-id</replaceable>
+
+[ndb_mgmd]
+<link linkend="ndbparam-mgm-hostname">HostName</link>=<replaceable>management-server-2-hostname</replaceable>
+
+# Using 2 management servers helps guarantee that there is always an
+# arbitrator in the event of network partitioning, and so is
+# recommended for high availability. Each management server must be
+# identified by a HostName. You may for the sake of convenience specify
+# a node ID for any management server, although one will be allocated
+# for it automatically; if you do so, it must be in the range 1-255
+# inclusive and must be unique among all IDs specified for cluster
+# nodes.
+
+# DATA NODE PARAMETERS
+
+[ndbd default]
+<link linkend="ndbparam-ndbd-noofreplicas">NoOfReplicas</link>=2
+
+# This parameter has no default value; it must always must be set
+# explicitly. Using 2 replicas is recommended to guarantee
+# availability of data; using only 1 replica does not provide any
+# redundancy, which means that the failure of a single data node causes
+# the entire cluster to shut down. We do not recommend using more than
+# 2 replicas, since 2 is sufficient to provide high availability, and
+# we do not currently test with greater values for this parameter.
+
+<link linkend="ndbparam-ndbd-lockpagesinmainmemory">LockPagesInMainMemory</link>=1
+
+# On Linux and Solaris systems, setting this parameter locks data node
+# processes into memory. Doing so prevents them from swapping to disk,
+# which can severely degrade cluster performance.
+
+<link linkend="ndbparam-ndbd-datamemory">DataMemory</link>=3072M
+<link linkend="ndbparam-ndbd-indexmemory">IndexMemory</link>=384M
+
+# The values provided for DataMemory and IndexMemory assume 4 GB RAM
+# per data node. However, for best results, you should first calculate
+# the memory that would be used based on the data you actually plan to
+# store (you may find the <link linkend="mysql-cluster-programs-ndb-size-pl">ndb_size.pl</link> utility helpful in estimating
+# this), then allow an extra 20% over the calculated values. Naturally,
+# you should ensure that each data node host has at least as much
+# physical memory as the sum of these two values.
+
+# <link linkend="ndbparam-ndbd-odirect">ODirect</link>=1
+
+# Enabling this parameter causes NDBCLUSTER to try using O_DIRECT
+# writes for local checkpoints and redo logs; this can reduce load on
+# CPUs. We recommend doing so when using MySQL Cluster NDB 6.2.3 or
+# newer on systems running Linux kernel 2.6 or later.
+
+<link linkend="ndbparam-ndbd-nooffragmentlogfiles">NoOfFragmentLogFiles</link>=300
+<link linkend="ndbparam-ndbd-datadir">DataDir</link>=<replaceable>path/to/data/node/data/directory</replaceable>
+<link linkend="ndbparam-ndbd-maxnoofconcurrentoperations">MaxNoOfConcurrentOperations</link>=100000
+<link linkend="ndbparam-ndbd-timebetweenglobalcheckpoints">TimeBetweenGlobalCheckpoints</link>=1000
+<link linkend="ndbparam-ndbd-timebetweenepochs">TimeBetweenEpochs</link>=200
+<link linkend="ndbparam-ndbd-diskcheckpointspeed">DiskCheckpointSpeed</link>=10M
+<link linkend="ndbparam-ndbd-diskcheckpointspeedinrestart">DiskCheckpointSpeedInRestart</link>=100M
+<link linkend="ndbparam-ndbd-redobuffer">RedoBuffer</link>=32M
+# <link linkend="ndbparam-ndbd-maxnooflocalscans">MaxNoOfLocalScans</link>=64
+<link linkend="ndbparam-ndbd-maxnooftables">MaxNoOfTables</link>=1024
+<link linkend="ndbparam-ndbd-maxnooforderedindexes">MaxNofOfOrderedIndexes</link>=256
+
+[ndbd]
+<link linkend="ndbparam-ndbd-hostname">HostName</link>=<replaceable>data-node-A-hostname</replaceable>
+# <link linkend="ndbparam-ndbd-id">Id</link>=<replaceable>data-node-A-id</replaceable>
+
+[ndbd]
+<link linkend="ndbparam-ndbd-hostname">HostName</link>=<replaceable>data-node-B-hostname</replaceable>
+# <link linkend="ndbparam-ndbd-id">Id</link>=<replaceable>data-node-B-id</replaceable>
+
+# You must have an [ndbd] section for every data node in the cluster;
+# each of these sections must include a HostName. Each section may
+# optionally include an Id for convenience, but in most cases, it is
+# sufficient to allow the cluster to allocate node IDs dynamically. If
+# you do specify the node ID for a data node, it must be in the range 1
+# to 48 inclusive and must be unique among all IDs specified for
+# cluster nodes.
+
+# SQL NODE / API NODE PARAMETERS
+
+[mysqld]
+# <link linkend="ndbparam-api-hostname">HostName</link>=<replaceable>SQL-node-1-hostname</replaceable>
+# <link linkend="ndbparam-api-id">Id</link>=<replaceable>sql-node-A-id</replaceable>
+
+[mysqld]
+
+[mysqld]
+
+# Each API or SQL node that connects to the cluster requires a [mysqld]
+# or [api] section of its own. Each such section defines a connection
+# <quote>slot</quote>; you should have at least as many of these sections in the
+# config.ini file as the total number of API nodes and SQL nodes that
+# you wish to have connected to the cluster at any given time. There is
+# no performance or other penalty for having extra slots available in
+# case you find later that you want or need more API or SQL nodes to
+# connect to the cluster at the same time.
+# If no HostName is specified for a given [mysqld] or [api] section,
+# then <emphasis>any</emphasis> API or SQL node may use that slot to connect to the
+# cluster. You may wish to use an explicit HostName for one connection slot
+# to guarantee that an API or SQL node from that host can always
+# connect to the cluster. If you wish to prevent API or SQL nodes from
+# connecting from other than a desired host or hosts, then use a
+# HostName for every [mysqld] or [api] section in the config.ini file.
+# You can if you wish define a node ID (Id parameter) for any API or
+# SQL node, but this is not necessary; if you do so, it must be in the
+# range 1 to 255 inclusive and must be unique among all IDs specified
+# for cluster nodes.
+</programlisting>
+
+ <formalpara>
+
+ <title>Starting configuration for MySQL Cluster NDB 6.3</title>
+
+ <para>
+ The following is a recommended starting point for configuring
+ a cluster running MySQL Cluster NDB 6.3. It is similar to the
+ recommendation for MySQL Cluster NDB 6.2, with the addition of
+ parameters for better control of
+ <literal role="se">NDBCLUSTER</literal> process threads.
+ </para>
+
+ </formalpara>
+
+<programlisting>
+
+# TCP PARAMETERS
+
+[tcp default]
+<link linkend="ndbparam-tcp-sendbuffermemory">SendBufferMemory</link>=2M
+<link linkend="ndbparam-tcp-receivebuffermemory">ReceiveBufferMemory</link>=2M
+
+# Increasing the sizes of these 2 buffers beyond the default values
+# helps prevent bottlenecks due to slow disk I/O.
+
+# MANAGEMENT NODE PARAMETERS
+
+[ndb_mgmd default]
+<link linkend="ndbparam-mgm-datadir">DataDir</link>=<replaceable>path/to/management/server/data/directory</replaceable>
+
+# It is possible to use a different data directory for each management
+# server, but for ease of administration it is preferable to be
+# consistent.
+
+[ndb_mgmd]
+<link linkend="ndbparam-mgm-hostname">HostName</link>=<replaceable>management-server-1-hostname</replaceable>
+# <link linkend="ndbparam-mgm-id">Id</link>=<replaceable>management-server-A-id</replaceable>
+
+[ndb_mgmd]
+<link linkend="ndbparam-mgm-hostname">HostName</link>=<replaceable>management-server-2-hostname</replaceable>
+
+# Using 2 management servers helps guarantee that there is always an
+# arbitrator in the event of network partitioning, and so is
+# recommended for high availability. Each management server must be
+# identified by a HostName. You may for the sake of convenience specify
+# a node ID for any management server, although one will be allocated
+# for it automatically; if you do so, it must be in the range 1-255
+# inclusive and must be unique among all IDs specified for cluster
+# nodes.
+
+# DATA NODE PARAMETERS
+
+[ndbd default]
+<link linkend="ndbparam-ndbd-noofreplicas">NoOfReplicas</link>=2
+
+# This parameter has no default value; it must always must be set
+# explicitly. Using 2 replicas is recommended to guarantee
+# availability of data; using only 1 replica does not provide any
+# redundancy, which means that the failure of a single data node causes
+# the entire cluster to shut down. We do not recommend using more than
+# 2 replicas, since 2 is sufficient to provide high availability, and
+# we do not currently test with greater values for this parameter.
+
+<link linkend="ndbparam-ndbd-lockpagesinmainmemory">LockPagesInMainMemory</link>=1
+
+# On Linux and Solaris systems, setting this parameter locks data node
+# processes into memory. Doing so prevents them from swapping to disk,
+# which can severely degrade cluster performance.
+
+<link linkend="ndbparam-ndbd-datamemory">DataMemory</link>=3072M
+<link linkend="ndbparam-ndbd-indexmemory">IndexMemory</link>=384M
+
+# The values provided for DataMemory and IndexMemory assume 4 GB RAM
+# per data node. However, for best results, you should first calculate
+# the memory that would be used based on the data you actually plan to
+# store (you may find the <link linkend="mysql-cluster-programs-ndb-size-pl">ndb_size.pl</link> utility helpful in estimating
+# this), then allow an extra 20% over the calculated values. Naturally,
+# you should ensure that each data node host has at least as much
+# physical memory as the sum of these two values.
+
+# <link linkend="ndbparam-ndbd-odirect">ODirect</link>=1
+
+# Enabling this parameter causes NDBCLUSTER to try using O_DIRECT
+# writes for local checkpoints and redo logs; this can reduce load on
+# CPUs. We recommend doing so when using MySQL Cluster NDB 6.2.3 or
+# newer on systems running Linux kernel 2.6 or later.
+
+<link linkend="ndbparam-ndbd-nooffragmentlogfiles">NoOfFragmentLogFiles</link>=300
+<link linkend="ndbparam-ndbd-datadir">DataDir</link>=<replaceable>path/to/data/node/data/directory</replaceable>
+<link linkend="ndbparam-ndbd-maxnoofconcurrentoperations">MaxNoOfConcurrentOperations</link>=100000
+
+<link linkend="ndbparam-ndbd-schedulerspintimer">SchedulerSpinTimer</link>=400
+<link linkend="ndbparam-ndbd-schedulerexecutiontimer">SchedulerExecutionTimer</link>=100
+<link linkend="ndbparam-ndbd-realtimescheduler">RealTimeScheduler</link>=1
+# Setting these parameters allows you to take advantage of real-time scheduling
+# of NDBCLUSTER threads (introduced in MySQL Cluster NDB 6.3.4) to get higher
+# throughput.
+
+<link linkend="ndbparam-ndbd-timebetweenglobalcheckpoints">TimeBetweenGlobalCheckpoints</link>=1000
+<link linkend="ndbparam-ndbd-timebetweenepochs">TimeBetweenEpochs</link>=200
+<link linkend="ndbparam-ndbd-diskcheckpointspeed">DiskCheckpointSpeed</link>=10M
+<link linkend="ndbparam-ndbd-diskcheckpointspeedinrestart">DiskCheckpointSpeedInRestart</link>=100M
+<link linkend="ndbparam-ndbd-redobuffer">RedoBuffer</link>=32M
+
+# <link linkend="ndbparam-ndbd-compressedlcp">CompressedLCP</link>=1
+# <link linkend="ndbparam-ndbd-compressedbackup">CompressedBackup</link>=1
+# Enabling CompressedLCP and CompressedBackup causes, respectively, local
+checkpoint files and backup files to be compressed, which can result in a space
+savings of up to 50% over noncompressed LCPs and backups.
+
+# <link linkend="ndbparam-ndbd-maxnooflocalscans">MaxNoOfLocalScans</link>=64
+<link linkend="ndbparam-ndbd-maxnooftables">MaxNoOfTables</link>=1024
+<link linkend="ndbparam-ndbd-maxnooforderedindexes">MaxNofOfOrderedIndexes</link>=256
+
+[ndbd]
+<link linkend="ndbparam-ndbd-hostname">HostName</link>=<replaceable>data-node-A-hostname</replaceable>
+# <link linkend="ndbparam-ndbd-id">Id</link>=<replaceable>data-node-A-id</replaceable>
+
+<link linkend="ndbparam-ndbd-lockexecutethreadtocpu">LockExecuteThreadToCPU</link>=1
+<link linkend="ndbparam-ndbd-lockmaintthreadstocpu">LockMaintThreadsToCPU</link>=0
+# On systems with multiple CPUs, these parameters can be used to lock NDBCLUSTER
+# threads to specific CPUs
+
+[ndbd]
+<link linkend="ndbparam-ndbd-hostname">HostName</link>=<replaceable>data-node-B-hostname</replaceable>
+# <link linkend="ndbparam-ndbd-id">Id</link>=<replaceable>data-node-B-id</replaceable>
+
+<link linkend="ndbparam-ndbd-lockexecutethreadtocpu">LockExecuteThreadToCPU</link>=1
+<link linkend="ndbparam-ndbd-lockmaintthreadstocpu">LockMaintThreadsToCPU</link>=0
+
+# You must have an [ndbd] section for every data node in the cluster;
+# each of these sections must include a HostName. Each section may
+# optionally include an Id for convenience, but in most cases, it is
+# sufficient to allow the cluster to allocate node IDs dynamically. If
+# you do specify the node ID for a data node, it must be in the range 1
+# to 48 inclusive and must be unique among all IDs specified for
+# cluster nodes.
+
+# SQL NODE / API NODE PARAMETERS
+
+[mysqld]
+# <link linkend="ndbparam-api-hostname">HostName</link>=<replaceable>SQL-node-1-hostname</replaceable>
+# <link linkend="ndbparam-api-id">Id</link>=<replaceable>sql-node-A-id</replaceable>
+
+[mysqld]
+
+[mysqld]
+
+# Each API or SQL node that connects to the cluster requires a [mysqld]
+# or [api] section of its own. Each such section defines a connection
+# <quote>slot</quote>; you should have at least as many of these sections in the
+# config.ini file as the total number of API nodes and SQL nodes that
+# you wish to have connected to the cluster at any given time. There is
+# no performance or other penalty for having extra slots available in
+# case you find later that you want or need more API or SQL nodes to
+# connect to the cluster at the same time.
+# If no HostName is specified for a given [mysqld] or [api] section,
+# then <emphasis>any</emphasis> API or SQL node may use that slot to connect to the
+# cluster. You may wish to use an explicit HostName for one connection slot
+# to guarantee that an API or SQL node from that host can always
+# connect to the cluster. If you wish to prevent API or SQL nodes from
+# connecting from other than a desired host or hosts, then use a
+# HostName for every [mysqld] or [api] section in the config.ini file.
+# You can if you wish define a node ID (Id parameter) for any API or
+# SQL node, but this is not necessary; if you do so, it must be in the
+# range 1 to 255 inclusive and must be unique among all IDs specified
+# for cluster nodes.
+ </programlisting>
+
+ <formalpara>
+
+ <title>Recommended <filename>my.cnf</filename> options for SQL nodes</title>
+
+ <para>
+ MySQL Servers acting as MySQL Cluster SQL nodes must always be
+ started with the <option role="mysqld">--ndbcluster</option>
+ and <option>--ndb-connectstring</option> options, either on
+ the command line or in <filename>my.cnf</filename>. In
+ addition, set the following options for all
+ <command>mysqld</command> processes in the cluster, unless
+ your setup requires otherwise:
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <option>--ndb-use-exact-count=0</option>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <option>--ndb-index-stat-enable=0</option>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <option>--ndb-force-send=1</option>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <option>--engine-condition-pushdown=1</option>
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+
+ </section>
+
+ <section id="mysql-cluster-connectstring">
+
+ <title>The MySQL Cluster Connectstring</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>connectstring</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>connectstring</primary>
+ <see>MySQL Cluster</see>
+ </indexterm>
+
+ <para>
+ With the exception of the MySQL Cluster management server
+ (<command>ndb_mgmd</command>), each node that is part of a MySQL
+ Cluster requires a <firstterm>connectstring</firstterm> that
+ points to the management server's location. This connectstring
+ is used in establishing a connection to the management server as
+ well as in performing other tasks depending on the node's role
+ in the cluster. The syntax for a connectstring is as follows:
+ </para>
+
+<programlisting>
+[nodeid=<replaceable>node_id</replaceable>, ]<replaceable>host-definition</replaceable>[, <replaceable>host-definition</replaceable>[, ...]]
+
+<replaceable>host-definition</replaceable>:
+ <replaceable>host_name</replaceable>[:<replaceable>port_number</replaceable>]
+</programlisting>
+
+ <para>
+ <literal>node_id</literal> is an integer larger than 1 which
+ identifies a node in <filename>config.ini</filename>.
+ <replaceable>host_name</replaceable> is a string representing a
+ valid Internet host name or IP address.
+ <replaceable>port_number</replaceable> is an integer referring
+ to a TCP/IP port number.
+ </para>
+
+<programlisting>
+example 1 (long): "nodeid=2,myhost1:1100,myhost2:1100,192.168.0.3:1200"
+example 2 (short): "myhost1"
+</programlisting>
+
+ <para>
+ <literal>localhost:1186</literal> is used as the default
+ connectstring value if none is provided. If
+ <replaceable>port_num</replaceable> is omitted from the
+ connectstring, the default port is 1186. This port should always
+ be available on the network because it has been assigned by IANA
+ for this purpose (see
+ <ulink url="http://www.iana.org/assignments/port-numbers"/> for
+ details).
+ </para>
+
+ <para>
+ By listing multiple host definitions, it is possible to
+ designate several redundant management servers. A MySQL Cluster
+ data or API node attempts to contact successive management
+ servers on each host in the order specified, until a successful
+ connection has been established.
+ </para>
+
+ <para>
+ Beginning with MySQL Cluster NDB 6.3.19, it is also possible in
+ a connectstring to specify one or more bind addresses to be used
+ by nodes having multiple network interfaces for connecting to
+ management servers. A bind address consists of a hostname or
+ network address and an optional port number. This enhanced
+ syntax for connectstrings is shown here:
+ </para>
+
+<programlisting>
+[nodeid=<replaceable>node_id</replaceable>, ]
+ [bind-address=<replaceable>host-definition</replaceable>, ]
+ <replaceable>host-definition</replaceable>[; bind-address=<replaceable>host-definition</replaceable>]
+ <replaceable>host-definition</replaceable>[; bind-address=<replaceable>host-definition</replaceable>]
+ [, ...]]
+
+<replaceable>host-definition</replaceable>:
+ <replaceable>host_name</replaceable>[:<replaceable>port_number</replaceable>]
+</programlisting>
+
+ <para>
+ If a single bind address is used in the connectstring
+ <emphasis>prior</emphasis> to specifying any management hosts,
+ then this address is used as the default for connecting to any
+ of them (unless overridden for a given management server; see
+ later in this section for an example). For example, the
+ following connectstring causes the node to use
+ <literal>192.168.178.242</literal> regardless of the management
+ server to which it connects:
+ </para>
+
+<programlisting>
+bind-address=192.168.178.242, poseidon:1186, perch:1186
+</programlisting>
+
+ <para>
+ If a bind address is specified <emphasis>following</emphasis> a
+ management host definition, then it is used only for connecting
+ to that management node. Consider the following connectstring:
+ </para>
+
+<programlisting>
+poseidon:1186;bind-address=localhost, perch:1186;bind-address=192.168.178.242
+</programlisting>
+
+ <para>
+ In this case, the node uses <literal>localhost</literal> to
+ connect to the management server running on the host named
+ <literal>poseidon</literal> and
+ <literal>192.168.178.242</literal> to connect to the management
+ server running on the host named <literal>perch</literal>.
+ </para>
+
+ <para>
+ You can specify a default bind address and then override this
+ default for one or more specific management hosts. In the
+ following example, <literal>localhost</literal> is used for
+ connecting to the management server running on host
+ <literal>poseidon</literal>; since
+ <literal>192.168.178.242</literal> is specified first (before
+ any management server definitions), it is the default bind
+ address and so is used for connecting to the management servers
+ on hosts <literal>perch</literal> and <literal>orca</literal>:
+ </para>
+
+<programlisting>
+bind-address=192.168.178.242,poseidon:1186;bind-address=localhost,perch:1186,orca:2200
+</programlisting>
+
+ <para>
+ There are a number of different ways to specify the
+ connectstring:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Each executable has its own command-line option which
+ enables specifying the management server at startup. (See
+ the documentation for the respective executable.)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ It is also possible to set the connectstring for all nodes
+ in the cluster at once by placing it in a
+ <literal>[mysql_cluster]</literal> section in the management
+ server's <filename>my.cnf</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ For backward compatibility, two other options are available,
+ using the same syntax:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Set the <envar>NDB_CONNECTSTRING</envar> environment
+ variable to contain the connectstring.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Write the connectstring for each executable into a text
+ file named <filename>Ndb.cfg</filename> and place this
+ file in the executable's startup directory.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ <para>
+ However, these are now deprecated and should not be used for
+ new installations.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The recommended method for specifying the connectstring is to
+ set it on the command line or in the <filename>my.cnf</filename>
+ file for each executable.
+ </para>
+
+ <para>
+ The maximum length of a connectstring is 1024 characters.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-computer-definition">
+
+ <title>Defining Computers in a MySQL Cluster</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>defining node hosts</secondary>
+ </indexterm>
+
+ <para>
+ The <literal>[computer]</literal> section has no real
+ significance other than serving as a way to avoid the need of
+ defining host names for each node in the system. All parameters
+ mentioned here are required.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para id="ndbparam-computer-id">
+ <literal>Id</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:id-computer"/>
+
+ <para>
+ This is an integer value, used to refer to the host computer
+ elsewhere in the configuration file. This is not the same as
+ the node ID.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para id="ndbparam-computer-hostname">
+ <literal>HostName</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:hostname-computer"/>
+
+ <para>
+ This is the computer's hostname or IP address.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
+ <section id="mysql-cluster-mgm-definition">
+
+ <title>Defining a MySQL Cluster Management Server</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>management node</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <para>
+ The <literal>[ndb_mgmd]</literal> section is used to configure
+ the behavior of the management server. <literal>[mgm]</literal>
+ can be used as an alias; the two section names are equivalent.
+ All parameters in the following list are optional and assume
+ their default values if omitted.
+ </para>
+
+ <note>
+ <para>
+ If neither the <literal>ExecuteOnComputer</literal> nor the
+ <literal>HostName</literal> parameter is present, the default
+ value <literal>localhost</literal> will be assumed for both.
+ </para>
+ </note>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>Id</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-id">
+ <literal>Id</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:id-mgm"/>
+
+ <para>
+ Each node in the cluster has a unique identity. For a
+ management node, this is represented by an integer value in
+ the range 1 to 63 inclusive (previous to MySQL Cluster NDB
+ 6.1.1), or in the range 1 to 255 inclusive (MySQL Cluster
+ NDB 6.1.1 and later). This ID is used by all internal
+ cluster messages for addressing the node, and so must be
+ unique for each MySQL Cluster node, regardless of the type
+ of node.
+ </para>
+
+ <note>
+ <para>
+ Data node IDs must be less than 49, regardless of the
+ MySQL Cluster version used. If you plan to deploy a large
+ number of data nodes, it is a good idea to limit the node
+ IDs for management nodes (and API nodes) to values greater
+ than 48.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ExecuteOnComputer</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-executeoncomputer">
+ <literal>ExecuteOnComputer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:executeoncomputer-mgm"/>
+
+ <para>
+ This refers to the <literal>Id</literal> set for one of the
+ computers defined in a <literal>[computer]</literal> section
+ of the <filename>config.ini</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>PortNumber</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-portnumber">
+ <literal>PortNumber</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:portnumber-mgm"/>
+
+ <para>
+ This is the port number on which the management server
+ listens for configuration requests and management commands.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HostName</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-hostname">
+ <literal>HostName</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:hostname-mgm"/>
+
+ <para>
+ Specifying this parameter defines the hostname of the
+ computer on which the management node is to reside. To
+ specify a hostname other than <literal>localhost</literal>,
+ either this parameter or
+ <literal>ExecuteOnComputer</literal> is required.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogDestination</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-logdestination">
+ <literal>LogDestination</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:logdestination-mgm"/>
+
+ <para>
+ This parameter specifies where to send cluster logging
+ information. There are three options in this regard —
+ <literal>CONSOLE</literal>, <literal>SYSLOG</literal>, and
+ <literal>FILE</literal> — with <literal>FILE</literal>
+ being the default:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>CONSOLE</literal> outputs the log to
+ <literal>stdout</literal>:
+ </para>
+
+<programlisting>
+CONSOLE
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>SYSLOG</literal> sends the log to a
+ <literal>syslog</literal> facility, possible values
+ being one of <literal>auth</literal>,
+ <literal>authpriv</literal>, <literal>cron</literal>,
+ <literal>daemon</literal>, <literal>ftp</literal>,
+ <literal>kern</literal>, <literal>lpr</literal>,
+ <literal>mail</literal>, <literal>news</literal>,
+ <literal>syslog</literal>, <literal>user</literal>,
+ <literal>uucp</literal>, <literal>local0</literal>,
+ <literal>local1</literal>, <literal>local2</literal>,
+ <literal>local3</literal>, <literal>local4</literal>,
+ <literal>local5</literal>, <literal>local6</literal>, or
+ <literal>local7</literal>.
+ </para>
+
+ <note>
+ <para>
+ Not every facility is necessarily supported by every
+ operating system.
+ </para>
+ </note>
+
+<programlisting>
+SYSLOG:facility=syslog
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>FILE</literal> pipes the cluster log output to
+ a regular file on the same machine. The following values
+ can be specified:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>filename</literal>: The name of the log
+ file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>maxsize</literal>: The maximum size (in
+ bytes) to which the file can grow before logging
+ rolls over to a new file. When this occurs, the old
+ log file is renamed by appending
+ <replaceable>.N</replaceable> to the file name,
+ where <replaceable>N</replaceable> is the next
+ number not yet used with this name.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>maxfiles</literal>: The maximum number of
+ log files.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+<programlisting>
+FILE:filename=cluster.log,maxsize=1000000,maxfiles=6
+</programlisting>
+
+ <para>
+ The default value for the <literal>FILE</literal>
+ parameter is
+ <literal>FILE:filename=ndb_<replaceable>node_id</replaceable>_cluster.log,maxsize=1000000,maxfiles=6</literal>,
+ where <replaceable>node_id</replaceable> is the ID of
+ the node.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ It is possible to specify multiple log destinations
+ separated by semicolons as shown here:
+ </para>
+
+<programlisting>
+CONSOLE;SYSLOG:facility=local0;FILE:filename=/var/log/mgmd
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationRank</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-arbitrationrank">
+ <literal>ArbitrationRank</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:arbitrationrank-mgm"/>
+
+ <para>
+ This parameter is used to define which nodes can act as
+ arbitrators. Only management nodes and SQL nodes can be
+ arbitrators. <literal>ArbitrationRank</literal> can take one
+ of the following values:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>0</literal>: The node will never be used as an
+ arbitrator.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>1</literal>: The node has high priority; that
+ is, it will be preferred as an arbitrator over
+ low-priority nodes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>2</literal>: Indicates a low-priority node
+ which be used as an arbitrator only if a node with a
+ higher priority is not available for that purpose.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ Normally, the management server should be configured as an
+ arbitrator by setting its <literal>ArbitrationRank</literal>
+ to 1 (the default value) and that of all SQL nodes to 0.
+ </para>
+
+ <para>
+ Beginning with MySQL 5.1.16 and MySQL Cluster NDB 6.1.3, it
+ is possible to disable arbitration completely by setting
+ <literal>ArbitrationRank</literal> to 0 on all management
+ and SQL nodes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationDelay</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-arbitrationdelay">
+ <literal>ArbitrationDelay</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:arbitrationdelay-mgm"/>
+
+ <para>
+ An integer value which causes the management server's
+ responses to arbitration requests to be delayed by that
+ number of milliseconds. By default, this value is 0; it is
+ normally not necessary to change it.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>DataDir</primary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-datadir">
+ <literal>DataDir</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:datadir-mgm"/>
+
+ <para>
+ This specifies the directory where output files from the
+ management server will be placed. These files include
+ cluster log files, process output files, and the daemon's
+ process ID (PID) file. (For log files, this location can be
+ overridden by setting the <literal>FILE</literal> parameter
+ for <literal>LogDestination</literal> as discussed
+ previously in this section.)
+ </para>
+
+ <para>
+ The default value for this parameter is the directory in
+ which <command>ndb_mgmd</command> is located.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TotalSendBufferMemory</primary>
+ <secondary>management nodes</secondary>
+ </indexterm>
+
+ <para id="ndbparam-mgm-totalsendbuffermemory">
+ <literal>TotalSendBufferMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:totalsendbuffermemory-mgm"/>
+
+ <para>
+ This parameter is available beginning with MySQL Cluster NDB
+ 6.4.0. It is used to determine the total amount of memory to
+ allocate on this node for shared send buffer memory among
+ all configured transporters.
+ </para>
+
+ <para>
+ If this parameter is set, its minimum allowed value is 256K;
+ the maxmimum is 4294967039. For more detailed information
+ about the behavior and use of
+ <literal>TotalSendBufferMemory</literal> and configuring
+ send buffer memory parameters in MySQL Cluster NDB 6.4.0 and
+ later, see
+ <xref linkend="mysql-cluster-config-send-buffers"/>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <note>
+ <para>
+ After making changes in a management node's
+ configuration, it is necessary to perform a rolling restart of
+ the cluster in order for the new configuration to take effect.
+ </para>
+
+ <para>
+ To add new management servers to a running MySQL Cluster, it
+ is also necessary to perform a rolling restart of all cluster
+ nodes after modifying any existing
+ <filename>config.ini</filename> files. For more information
+ about issues arising when using multiple management nodes, see
+ <xref linkend="mysql-cluster-limitations-multiple-nodes"/>.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-ndbd-definition">
+
+ <title>Defining MySQL Cluster Data Nodes</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>data node</secondary>
+ </indexterm>
+
+ <para>
+ The <literal>[ndbd]</literal> and <literal>[ndbd
+ default]</literal> sections are used to configure the behavior
+ of the cluster's data nodes.
+ </para>
+
+ <para>
+ <literal>[ndbd]</literal> and <literal>[ndbd default]</literal>
+ are always used as the section names whether you are using
+ <command>ndbd</command> or (in MySQL Cluster NDB 6.4.0 and
+ later) <command>ndbmtd</command> binaries for the data node
+ processes.
+ </para>
+
+ <para>
+ There are many parameters which control buffer sizes, pool
+ sizes, timeouts, and so forth. The only mandatory parameters
+ are:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Either <literal>ExecuteOnComputer</literal> or
+ <literal>HostName</literal>, which must be defined in the
+ local <literal>[ndbd]</literal> section.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The parameter <literal>NoOfReplicas</literal>, which must be
+ defined in the<literal>[ndbd default]</literal>section, as
+ it is common to all Cluster data nodes.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ Most data node parameters are set in the <literal>[ndbd
+ default]</literal> section. Only those parameters explicitly
+ stated as being able to set local values are allowed to be
+ changed in the <literal>[ndbd]</literal> section. Where present,
+ <literal>HostName</literal>, <literal>Id</literal> and
+ <literal>ExecuteOnComputer</literal> <emphasis>must</emphasis>
+ be defined in the local <literal>[ndbd]</literal> section, and
+ not in any other section of <filename>config.ini</filename>. In
+ other words, settings for these parameters are specific to one
+ data node.
+ </para>
+
+ <para>
+ For those parameters affecting memory usage or buffer sizes, it
+ is possible to use <literal>K</literal>, <literal>M</literal>,
+ or <literal>G</literal> as a suffix to indicate units of 1024,
+ 1024×1024, or 1024×1024×1024. (For example,
+ <literal>100K</literal> means 100 × 1024 = 102400.)
+ Parameter names and values are currently case-sensitive.
+ </para>
+
+ <para>
+ Information about configuration parameters specific to MySQL
+ Cluster Disk Data tables can be found later in this section.
+ </para>
+
+ <para>
+ Beginning with MySQL Cluster NDB 6.4.0, all of these parameters
+ also apply to <command>ndbmtd</command> (the multi-threaded
+ version of <command>ndbd</command>). An additional data node
+ configuration parameter
+ <literal>MaxNoOfExecutionThreads</literal> applies to
+ <command>ndbmtd</command> only, and has no effect when used with
+ <command>ndbd</command>. For a description of this parameter and
+ its use, see <xref linkend="mysql-cluster-programs-ndbmtd"/>.
+ </para>
+
+ <formalpara>
+
+ <title>Identifying data nodes</title>
+
+ <para id="mysql-cluster-identifying-data-nodes">
+ The <literal>Id</literal> value (that is, the data node
+ identifier) can be allocated on the command line when the node
+ is started or in the configuration file.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>Id</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-id">
+ <literal>Id</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:id-ndbd"/>
+
+ <para>
+ This is the node ID used as the address of the node for all
+ cluster internal messages. For data nodes, this is an
+ integer in the range 1 to 48 inclusive. Each node in the
+ cluster must have a unique identifier.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ExecuteOnComputer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-executeoncomputer">
+ <literal>ExecuteOnComputer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:executeoncomputer-ndbd"/>
+
+ <para>
+ This refers to the <literal>Id</literal> set for one of the
+ computers defined in a <literal>[computer]</literal>
+ section.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HostName</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-hostname">
+ <literal>HostName</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:hostname-ndbd"/>
+
+ <para>
+ Specifying this parameter defines the hostname of the
+ computer on which the data node is to reside. To specify a
+ hostname other than <literal>localhost</literal>, either
+ this parameter or <literal>ExecuteOnComputer</literal> is
+ required.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ServerPort</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-serverport">
+ <literal>ServerPort</literal>
+ (<emphasis>OBSOLETE</emphasis>)
+ </para>
+
+ <para>
+ Each node in the cluster uses a port to connect to other
+ nodes. This port is used also for non-TCP transporters in
+ the connection setup phase. The default port is allocated
+ dynamically in such a way as to ensure that no two nodes on
+ the same computer receive the same port number, so it should
+ not normally be necessary to specify a value for this
+ parameter.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para id="ndbparam-ndbd-tcpbind-inaddr-any">
+ <literal>TcpBind_INADDR_ANY</literal>
+ </para>
+
+ <para>
+ Setting this parameter to <literal>TRUE</literal> or
+ <literal>1</literal> binds <literal>IP_ADDR_ANY</literal> so
+ that connections can be made from anywhere (for
+ autogenerated connections). The default is
+ <literal>FALSE</literal> (<literal>0</literal>).
+ </para>
+
+ <para>
+ This parameter was added in MySQL Cluster NDB 6.2.0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NodeGroup</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-nodegroup">
+ <literal>NodeGroup</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:nodegroup-ndbd"/>
+
+ <para>
+ This parameter can be used to assign a data node to a
+ specific node group. It is read only when the cluster is
+ started for the first time, and cannot be used to reassign a
+ data node to a different node group online. It is generally
+ not desirable to use this parameter in the <literal>[ndbd
+ default]</literal> section of the
+ <filename>config.ini</filename> file, and care must be taken
+ not to assign nodes to node groups in such a way that an
+ invalid numbers of nodes are assigned to any node groups.
+ </para>
+
+ <para>
+ The <literal>NodeGroup</literal> parameter is chiefly
+ intended for use in adding a new node group to a running
+ MySQL Cluster without having to perform a rolling restart.
+ For this purpose, you should set it to 65535 (the maximum
+ value). You are not required to set a
+ <literal>NodeGroup</literal> value for all cluster data
+ nodes, only for those nodes which are to be started and
+ added to the cluster as a new node group at a later time.
+ For more information, see
+ <xref linkend="mysql-cluster-online-add-node-example"/>.
+ </para>
+
+ <para>
+ This parameter was added in MySQL Cluster NDB 6.4.0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfReplicas</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofreplicas">
+ <literal>NoOfReplicas</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:noofreplicas-ndbd"/>
+
+ <para>
+ This global parameter can be set only in the <literal>[ndbd
+ default]</literal> section, and defines the number of
+ replicas for each table stored in the cluster. This
+ parameter also specifies the size of node groups. A node
+ group is a set of nodes all storing the same information.
+ </para>
+
+ <para>
+ Node groups are formed implicitly. The first node group is
+ formed by the set of data nodes with the lowest node IDs,
+ the next node group by the set of the next lowest node
+ identities, and so on. By way of example, assume that we
+ have 4 data nodes and that <literal>NoOfReplicas</literal>
+ is set to 2. The four data nodes have node IDs 2, 3, 4 and
+ 5. Then the first node group is formed from nodes 2 and 3,
+ and the second node group by nodes 4 and 5. It is important
+ to configure the cluster in such a manner that nodes in the
+ same node groups are not placed on the same computer because
+ a single hardware failure would cause the entire cluster to
+ fail.
+ </para>
+
+ <para>
+ If no node IDs are provided, the order of the data nodes
+ will be the determining factor for the node group. Whether
+ or not explicit assignments are made, they can be viewed in
+ the output of the management client's
+ <literal role="ndb_mgm_cmd">SHOW</literal> command.
+ </para>
+
+ <para>
+ There is no default value for
+ <literal>NoOfReplicas</literal>; the maximum possible value
+ is 4. Currently, only the values 1 and 2 are actually
+ supported (see Bug#18621).
+ </para>
+
+ <important>
+ <para>
+ Setting <literal>NoOfReplicas</literal> to 1 means that
+ there is only a single copy of all Cluster data; in this
+ case, the loss of a single data node causes the cluster to
+ fail because there are no additional copies of the data
+ stored by that node.
+ </para>
+ </important>
+
+ <para>
+ The value for this parameter must divide evenly into the
+ number of data nodes in the cluster. For example, if there
+ are two data nodes, then <literal>NoOfReplicas</literal>
+ must be equal to either 1 or 2, since 2/3 and 2/4 both yield
+ fractional values; if there are four data nodes, then
+ <literal>NoOfReplicas</literal> must be equal to 1, 2, or 4.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>DataDir</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-datadir">
+ <literal>DataDir</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:datadir-ndbd"/>
+
+ <para>
+ This parameter specifies the directory where trace files,
+ log files, pid files and error logs are placed.
+ </para>
+
+ <para>
+ The default is the data node process working directory.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>FileSystemPath</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-filesystempath">
+ <literal>FileSystemPath</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:filesystempath-ndbd"/>
+
+ <para>
+ This parameter specifies the directory where all files
+ created for metadata, REDO logs, UNDO logs (for Disk Data
+ tables) and data files are placed. The default is the
+ directory specified by <literal>DataDir</literal>.
+ </para>
+
+ <note>
+ <para>
+ This directory must exist before the
+ <command>ndbd</command> process is initiated.
+ </para>
+ </note>
+
+ <para>
+ The recommended directory hierarchy for MySQL Cluster
+ includes <filename>/var/lib/mysql-cluster</filename>, under
+ which a directory for the node's file system is created. The
+ name of this subdirectory contains the node ID. For example,
+ if the node ID is 2, this subdirectory is named
+ <filename>ndb_2_fs</filename>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupDataDir</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupdatadir">
+ <literal>BackupDataDir</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:backupdatadir-ndbd"/>
+
+ <para>
+ This parameter specifies the directory in which backups are
+ placed. If omitted, the default backup location is the
+ directory named <filename>BACKUP</filename> under the
+ location specified by the <literal>FileSystemPath</literal>
+ parameter. (See above.)
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para id="mysql-cluster-data-memory-index-memory-string-memory">
+ <emphasis role="bold">Data Memory, Index Memory, and String
+ Memory</emphasis>
+ </para>
+
+ <para>
+ <literal>DataMemory</literal> and <literal>IndexMemory</literal>
+ are <literal>[ndbd]</literal> parameters specifying the size of
+ memory segments used to store the actual records and their
+ indexes. In setting values for these, it is important to
+ understand how <literal>DataMemory</literal> and
+ <literal>IndexMemory</literal> are used, as they usually need to
+ be updated to reflect actual usage by the cluster:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>DataMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-datamemory">
+ <literal>DataMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:datamemory-ndbd"/>
+
+ <para>
+ This parameter defines the amount of space (in bytes)
+ available for storing database records. The entire amount
+ specified by this value is allocated in memory, so it is
+ extremely important that the machine has sufficient physical
+ memory to accommodate it.
+ </para>
+
+ <para>
+ The memory allocated by <literal>DataMemory</literal> is
+ used to store both the actual records and indexes. There is
+ a 16-byte overhead on each record; an additional amount for
+ each record is incurred because it is stored in a 32KB page
+ with 128 byte page overhead (see below). There is also a
+ small amount wasted per page due to the fact that each
+ record is stored in only one page.
+ </para>
+
+ <para>
+ For variable-size table attributes in MySQL 5.1, the data is
+ stored on separate datapages, allocated from
+ <literal>DataMemory</literal>. Variable-length records use a
+ fixed-size part with an extra overhead of 4 bytes to
+ reference the variable-size part. The variable-size part has
+ 2 bytes overhead plus 2 bytes per attribute.
+ </para>
+
+ <para>
+ The maximum record size is currently 8052 bytes.
+ </para>
+
+ <para>
+ The memory space defined by <literal>DataMemory</literal> is
+ also used to store ordered indexes, which use about 10 bytes
+ per record. Each table row is represented in the ordered
+ index. A common error among users is to assume that all
+ indexes are stored in the memory allocated by
+ <literal>IndexMemory</literal>, but this is not the case:
+ Only primary key and unique hash indexes use this memory;
+ ordered indexes use the memory allocated by
+ <literal>DataMemory</literal>. However, creating a primary
+ key or unique hash index also creates an ordered index on
+ the same keys, unless you specify <literal>USING
+ HASH</literal> in the index creation statement. This can be
+ verified by running <command>ndb_desc -d
+ <replaceable>db_name</replaceable>
+ <replaceable>table_name</replaceable></command> in the
+ management client.
+ </para>
+
+ <para>
+ The memory space allocated by <literal>DataMemory</literal>
+ consists of 32KB pages, which are allocated to table
+ fragments. Each table is normally partitioned into the same
+ number of fragments as there are data nodes in the cluster.
+ Thus, for each node, there are the same number of fragments
+ as are set in <literal>NoOfReplicas</literal>.
+ </para>
+
+ <para>
+ In addition, due to the way in which new pages are allocated
+ when the capacity of the current page is exhausted, there is
+ an additional overhead of approximately 18.75%. When more
+ <literal>DataMemory</literal> is required, more than one new
+ page is allocated, according to the following formula:
+
+<programlisting>
+number of new pages = FLOOR(number of current pages × 0.1875) + 1
+</programlisting>
+
+ For example, if 15 pages are currently allocated to a given
+ table and an insert to this table requires additional
+ storage space, the number of new pages allocated to the
+ table is <literal>FLOOR(15 × 0.1875) + 1 =
+ FLOOR(2.8125) + 1 = 2 + 1 =
+ 3</literal>. Now 15 + 3 = 18 memory pages are
+ allocated to the table. When the last of these 18 pages
+ becomes full, <literal>FLOOR(18 × 0.1875) + 1
+ = FLOOR(3.3750) + 1 = 3 + 1 =
+ 4</literal> new pages are allocated, so the total number of
+ pages allocated to the table is now 22.
+ </para>
+
+ <note>
+ <para>
+ The <quote>18.75% + 1</quote> overhead is no longer
+ required beginning with MySQL Cluster NDB 6.2.3 and MySQL
+ Cluster NDB 6.3.0.
+ </para>
+ </note>
+
+ <para>
+ Once a page has been allocated, it is currently not possible
+ to return it to the pool of free pages, except by deleting
+ the table. (This also means that
+ <literal>DataMemory</literal> pages, once allocated to a
+ given table, cannot be used by other tables.) Performing a
+ node recovery also compresses the partition because all
+ records are inserted into empty partitions from other live
+ nodes.
+ </para>
+
+ <para>
+ The <literal>DataMemory</literal> memory space also contains
+ UNDO information: For each update, a copy of the unaltered
+ record is allocated in the <literal>DataMemory</literal>.
+ There is also a reference to each copy in the ordered table
+ indexes. Unique hash indexes are updated only when the
+ unique index columns are updated, in which case a new entry
+ in the index table is inserted and the old entry is deleted
+ upon commit. For this reason, it is also necessary to
+ allocate enough memory to handle the largest transactions
+ performed by applications using the cluster. In any case,
+ performing a few large transactions holds no advantage over
+ using many smaller ones, for the following reasons:
+ </para>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>transactions</secondary>
+ </indexterm>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Large transactions are not any faster than smaller ones
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Large transactions increase the number of operations
+ that are lost and must be repeated in event of
+ transaction failure
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Large transactions use more memory
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The default value for <literal>DataMemory</literal> is 80MB;
+ the minimum is 1MB. There is no maximum size, but in reality
+ the maximum size has to be adapted so that the process does
+ not start swapping when the limit is reached. This limit is
+ determined by the amount of physical RAM available on the
+ machine and by the amount of memory that the operating
+ system may commit to any one process. 32-bit operating
+ systems are generally limited to 2−4GB per process;
+ 64-bit operating systems can use more. For large databases,
+ it may be preferable to use a 64-bit operating system for
+ this reason.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>IndexMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-indexmemory">
+ <literal>IndexMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:indexmemory-ndbd"/>
+
+ <para>
+ This parameter controls the amount of storage used for hash
+ indexes in MySQL Cluster. Hash indexes are always used for
+ primary key indexes, unique indexes, and unique constraints.
+ Note that when defining a primary key and a unique index,
+ two indexes will be created, one of which is a hash index
+ used for all tuple accesses as well as lock handling. It is
+ also used to enforce unique constraints.
+ </para>
+
+ <para>
+ The size of the hash index is 25 bytes per record, plus the
+ size of the primary key. For primary keys larger than 32
+ bytes another 8 bytes is added.
+ </para>
+
+ <para>
+ The default value for <literal>IndexMemory</literal> is
+ 18MB. The minimum is 1MB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StringMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-stringmemory">
+ <literal>StringMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:stringmemory-ndbd"/>
+
+ <para>
+ This parameter determines how much memory is allocated for
+ strings such as table names, and is specified in an
+ <literal>[ndbd]</literal> or <literal>[ndbd
+ default]</literal> section of the
+ <filename>config.ini</filename> file. A value between
+ <literal>0</literal> and <literal>100</literal> inclusive is
+ interpreted as a percent of the maximum default value, which
+ is calculated based on a number of factors including the
+ number of tables, maximum table name size, maximum size of
+ <filename>.FRM</filename> files,
+ <literal>MaxNoOfTriggers</literal>, maximum column name
+ size, and maximum default column value. In general it is
+ safe to assume that the maximum default value is
+ approximately 5 MB for a MySQL Cluster having 1000 tables.
+ </para>
+
+ <para>
+ A value greater than <literal>100</literal> is interpreted
+ as a number of bytes.
+ </para>
+
+ <para>
+ The default value is <literal>5</literal> — that is, 5
+ percent of the default maximum, or roughly 5 KB. (Note that
+ this is a change from previous versions of MySQL Cluster.)
+ </para>
+
+ <para>
+ Under most circumstances, the default value should be
+ sufficient, but when you have a great many Cluster tables
+ (1000 or more), it is possible to get Error 773
+ <errortext>Out of string memory, please modify StringMemory
+ config parameter: Permanent error: Schema error</errortext>,
+ in which case you should increase this value.
+ <literal>25</literal> (25 percent) is not excessive, and
+ should prevent this error from recurring in all but the most
+ extreme conditions.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The following example illustrates how memory is used for a
+ table. Consider this table definition:
+ </para>
+
+<programlisting>
+CREATE TABLE example (
+ a INT NOT NULL,
+ b INT NOT NULL,
+ c INT NOT NULL,
+ PRIMARY KEY(a),
+ UNIQUE(b)
+) ENGINE=NDBCLUSTER;
+</programlisting>
+
+ <para>
+ For each record, there are 12 bytes of data plus 12 bytes
+ overhead. Having no nullable columns saves 4 bytes of overhead.
+ In addition, we have two ordered indexes on columns
+ <literal>a</literal> and <literal>b</literal> consuming roughly
+ 10 bytes each per record. There is a primary key hash index on
+ the base table using roughly 29 bytes per record. The unique
+ constraint is implemented by a separate table with
+ <literal>b</literal> as primary key and <literal>a</literal> as
+ a column. This other table consumes an additional 29 bytes of
+ index memory per record in the <literal>example</literal> table
+ as well 8 bytes of record data plus 12 bytes of overhead.
+ </para>
+
+ <para>
+ Thus, for one million records, we need 58MB for index memory to
+ handle the hash indexes for the primary key and the unique
+ constraint. We also need 64MB for the records of the base table
+ and the unique index table, plus the two ordered index tables.
+ </para>
+
+ <para>
+ You can see that hash indexes takes up a fair amount of memory
+ space; however, they provide very fast access to the data in
+ return. They are also used in MySQL Cluster to handle uniqueness
+ constraints.
+ </para>
+
+ <para>
+ Currently, the only partitioning algorithm is hashing and
+ ordered indexes are local to each node. Thus, ordered indexes
+ cannot be used to handle uniqueness constraints in the general
+ case.
+ </para>
+
+ <para>
+ An important point for both <literal>IndexMemory</literal> and
+ <literal>DataMemory</literal> is that the total database size is
+ the sum of all data memory and all index memory for each node
+ group. Each node group is used to store replicated information,
+ so if there are four nodes with two replicas, there will be two
+ node groups. Thus, the total data memory available is 2 ×
+ <literal>DataMemory</literal> for each data node.
+ </para>
+
+ <para>
+ It is highly recommended that <literal>DataMemory</literal> and
+ <literal>IndexMemory</literal> be set to the same values for all
+ nodes. Data distribution is even over all nodes in the cluster,
+ so the maximum amount of space available for any node can be no
+ greater than that of the smallest node in the cluster.
+ </para>
+
+ <para>
+ <literal>DataMemory</literal> and <literal>IndexMemory</literal>
+ can be changed, but decreasing either of these can be risky;
+ doing so can easily lead to a node or even an entire MySQL
+ Cluster that is unable to restart due to there being
+ insufficient memory space. Increasing these values should be
+ acceptable, but it is recommended that such upgrades are
+ performed in the same manner as a software upgrade, beginning
+ with an update of the configuration file, and then restarting
+ the management server followed by restarting each data node in
+ turn.
+ </para>
+
+ <para>
+ Updates do not increase the amount of index memory used. Inserts
+ take effect immediately; however, rows are not actually deleted
+ until the transaction is committed.
+ </para>
+
+ <formalpara>
+
+ <title>Transaction parameters</title>
+
+ <para id="mysql-cluster-transaction-parameters">
+ The next three <literal>[ndbd]</literal> parameters that we
+ discuss are important because they affect the number of
+ parallel transactions and the sizes of transactions that can
+ be handled by the system.
+ <literal>MaxNoOfConcurrentTransactions</literal> sets the
+ number of parallel transactions possible in a node.
+ <literal>MaxNoOfConcurrentOperations</literal> sets the number
+ of records that can be in update phase or locked
+ simultaneously.
+ </para>
+
+ </formalpara>
+
+ <para>
+ Both of these parameters (especially
+ <literal>MaxNoOfConcurrentOperations</literal>) are likely
+ targets for users setting specific values and not using the
+ default value. The default value is set for systems using small
+ transactions, to ensure that these do not use excessive memory.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfConcurrentTransactions</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofconcurrenttransactions">
+ <literal>MaxNoOfConcurrentTransactions</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnoofconcurrenttransactions-ndbd"/>
+
+ <para>
+ Each cluster data node requires a transaction record for
+ each active transaction in the cluster. The task of
+ coordinating transactions is distributed among all of the
+ data nodes. The total number of transaction records in the
+ cluster is the number of transactions in any given node
+ times the number of nodes in the cluster.
+ </para>
+
+ <para>
+ Transaction records are allocated to individual MySQL
+ servers. Each connection to a MySQL server requires at least
+ one transaction record, plus an additional transaction
+ object per table accessed by that connection. This means
+ that a reasonable minimum for this parameter is
+
+<programlisting>
+MaxNoOfConcurrentTransactions =
+ (maximum number of tables accessed in any single transaction + 1)
+ * number of cluster SQL nodes
+</programlisting>
+
+ For example, suppose that there are 4 SQL nodes using the
+ cluster. A single join involving 5 tables requires 6
+ transaction records; if there are 5 such joins in a
+ transaction, then 5 * 6 = 30 transaction records are
+ required for this transaction, per MySQL server, or 30 * 4 =
+ 120 transaction records total.
+ </para>
+
+ <para>
+ This parameter must be set to the same value for all cluster
+ data nodes. This is due to the fact that, when a data node
+ fails, the oldest surviving node re-creates the transaction
+ state of all transactions that were ongoing in the failed
+ node.
+ </para>
+
+ <para>
+ Changing the value of
+ <literal>MaxNoOfConcurrentTransactions</literal> requires a
+ complete shutdown and restart of the cluster.
+ </para>
+
+ <para>
+ The default value is 4096.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfConcurrentOperations</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofconcurrentoperations">
+ <literal>MaxNoOfConcurrentOperations</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnoofconcurrentoperations-ndbd"/>
+
+ <para>
+ It is a good idea to adjust the value of this parameter
+ according to the size and number of transactions. When
+ performing transactions of only a few operations each and
+ not involving a great many records, there is no need to set
+ this parameter very high. When performing large transactions
+ involving many records need to set this parameter higher.
+ </para>
+
+ <para>
+ Records are kept for each transaction updating cluster data,
+ both in the transaction coordinator and in the nodes where
+ the actual updates are performed. These records contain
+ state information needed to find UNDO records for rollback,
+ lock queues, and other purposes.
+ </para>
+
+ <para>
+ This parameter should be set to the number of records to be
+ updated simultaneously in transactions, divided by the
+ number of cluster data nodes. For example, in a cluster
+ which has four data nodes and which is expected to handle
+ 1,000,000 concurrent updates using transactions, you should
+ set this value to 1000000 / 4 = 250000.
+ </para>
+
+ <para>
+ Read queries which set locks also cause operation records to
+ be created. Some extra space is allocated within individual
+ nodes to accommodate cases where the distribution is not
+ perfect over the nodes.
+ </para>
+
+ <para>
+ When queries make use of the unique hash index, there are
+ actually two operation records used per record in the
+ transaction. The first record represents the read in the
+ index table and the second handles the operation on the base
+ table.
+ </para>
+
+ <para>
+ The default value is 32768.
+ </para>
+
+ <para>
+ This parameter actually handles two values that can be
+ configured separately. The first of these specifies how many
+ operation records are to be placed with the transaction
+ coordinator. The second part specifies how many operation
+ records are to be local to the database.
+ </para>
+
+ <para>
+ A very large transaction performed on an eight-node cluster
+ requires as many operation records in the transaction
+ coordinator as there are reads, updates, and deletes
+ involved in the transaction. However, the operation records
+ of the are spread over all eight nodes. Thus, if it is
+ necessary to configure the system for one very large
+ transaction, it is a good idea to configure the two parts
+ separately. <literal>MaxNoOfConcurrentOperations</literal>
+ will always be used to calculate the number of operation
+ records in the transaction coordinator portion of the node.
+ </para>
+
+ <para>
+ It is also important to have an idea of the memory
+ requirements for operation records. These consume about 1KB
+ per record.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfLocalOperations</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooflocaloperations">
+ <literal>MaxNoOfLocalOperations</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnooflocaloperations-ndbd"/>
+
+ <para>
+ By default, this parameter is calculated as 1.1 ×
+ <literal>MaxNoOfConcurrentOperations</literal>. This fits
+ systems with many simultaneous transactions, none of them
+ being very large. If there is a need to handle one very
+ large transaction at a time and there are many nodes, it is
+ a good idea to override the default value by explicitly
+ specifying this parameter.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Transaction temporary storage</title>
+
+ <para id="mysql-cluster-transaction-temporary-storage">
+ The next set of <literal>[ndbd]</literal> parameters is used
+ to determine temporary storage when executing a statement that
+ is part of a Cluster transaction. All records are released
+ when the statement is completed and the cluster is waiting for
+ the commit or rollback.
+ </para>
+
+ </formalpara>
+
+ <para>
+ The default values for these parameters are adequate for most
+ situations. However, users with a need to support transactions
+ involving large numbers of rows or operations may need to
+ increase these values to enable better parallelism in the
+ system, whereas users whose applications require relatively
+ small transactions can decrease the values to save memory.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfConcurrentIndexOperations</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofconcurrentindexoperations">
+ <literal>MaxNoOfConcurrentIndexOperations</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnoofconcurrentindexoperations-ndbd"/>
+
+ <para>
+ For queries using a unique hash index, another temporary set
+ of operation records is used during a query's execution
+ phase. This parameter sets the size of that pool of records.
+ Thus, this record is allocated only while executing a part
+ of a query. As soon as this part has been executed, the
+ record is released. The state needed to handle aborts and
+ commits is handled by the normal operation records, where
+ the pool size is set by the parameter
+ <literal>MaxNoOfConcurrentOperations</literal>.
+ </para>
+
+ <para>
+ The default value of this parameter is 8192. Only in rare
+ cases of extremely high parallelism using unique hash
+ indexes should it be necessary to increase this value. Using
+ a smaller value is possible and can save memory if the DBA
+ is certain that a high degree of parallelism is not required
+ for the cluster.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfFiredTriggers</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooffiredtriggers">
+ <literal>MaxNoOfFiredTriggers</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnooffiredtriggers-ndbd"/>
+
+ <para>
+ The default value of <literal>MaxNoOfFiredTriggers</literal>
+ is 4000, which is sufficient for most situations. In some
+ cases it can even be decreased if the DBA feels certain the
+ need for parallelism in the cluster is not high.
+ </para>
+
+ <para>
+ A record is created when an operation is performed that
+ affects a unique hash index. Inserting or deleting a record
+ in a table with unique hash indexes or updating a column
+ that is part of a unique hash index fires an insert or a
+ delete in the index table. The resulting record is used to
+ represent this index table operation while waiting for the
+ original operation that fired it to complete. This operation
+ is short-lived but can still require a large number of
+ records in its pool for situations with many parallel write
+ operations on a base table containing a set of unique hash
+ indexes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TransactionBufferMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-transactionbuffermemory">
+ <literal>TransactionBufferMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:transactionbuffermemory-ndbd"/>
+
+ <para>
+ The memory affected by this parameter is used for tracking
+ operations fired when updating index tables and reading
+ unique indexes. This memory is used to store the key and
+ column information for these operations. It is only very
+ rarely that the value for this parameter needs to be altered
+ from the default.
+ </para>
+
+ <para>
+ The default value for
+ <literal>TransactionBufferMemory</literal> is 1MB.
+ </para>
+
+ <para>
+ Normal read and write operations use a similar buffer, whose
+ usage is even more short-lived. The compile-time parameter
+ <literal>ZATTRBUF_FILESIZE</literal> (found in
+ <filename>ndb/src/kernel/blocks/Dbtc/Dbtc.hpp</filename>)
+ set to 4000 × 128 bytes (500KB). A similar buffer for
+ key information, <literal>ZDATABUF_FILESIZE</literal> (also
+ in <filename>Dbtc.hpp</filename>) contains 4000 × 16 =
+ 62.5KB of buffer space. <literal>Dbtc</literal> is the
+ module that handles transaction coordination.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Scans and buffering</title>
+
+ <para id="mysql-cluster-scans-and-buffering">
+ There are additional <literal>[ndbd]</literal> parameters in
+ the <literal>Dblqh</literal> module (in
+ <filename>ndb/src/kernel/blocks/Dblqh/Dblqh.hpp</filename>)
+ that affect reads and updates. These include
+ <literal>ZATTRINBUF_FILESIZE</literal>, set by default to
+ 10000 × 128 bytes (1250KB) and
+ <literal>ZDATABUF_FILE_SIZE</literal>, set by default to
+ 10000*16 bytes (roughly 156KB) of buffer space. To date, there
+ have been neither any reports from users nor any results from
+ our own extensive tests suggesting that either of these
+ compile-time limits should be increased.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfConcurrentScans</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofconcurrentscans">
+ <literal>MaxNoOfConcurrentScans</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnoofconcurrentscans-ndbd"/>
+
+ <para>
+ This parameter is used to control the number of parallel
+ scans that can be performed in the cluster. Each transaction
+ coordinator can handle the number of parallel scans defined
+ for this parameter. Each scan query is performed by scanning
+ all partitions in parallel. Each partition scan uses a scan
+ record in the node where the partition is located, the
+ number of records being the value of this parameter times
+ the number of nodes. The cluster should be able to sustain
+ <literal>MaxNoOfConcurrentScans</literal> scans concurrently
+ from all nodes in the cluster.
+ </para>
+
+ <para>
+ Scans are actually performed in two cases. The first of
+ these cases occurs when no hash or ordered indexes exists to
+ handle the query, in which case the query is executed by
+ performing a full table scan. The second case is encountered
+ when there is no hash index to support the query but there
+ is an ordered index. Using the ordered index means executing
+ a parallel range scan. The order is kept on the local
+ partitions only, so it is necessary to perform the index
+ scan on all partitions.
+ </para>
+
+ <para>
+ The default value of
+ <literal>MaxNoOfConcurrentScans</literal> is 256. The
+ maximum value is 500.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfLocalScans</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooflocalscans">
+ <literal>MaxNoOfLocalScans</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnooflocalscans-ndbd"/>
+
+ <para>
+ Specifies the number of local scan records if many scans are
+ not fully parallelized. If the number of local scan records
+ is not provided, it is calculated as the product of
+ <literal>MaxNoOfConcurrentScans</literal> and the number of
+ data nodes in the system. The minimum value is 32.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BatchSizePerLocalScan</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-batchsizeperlocalscan">
+ <literal>BatchSizePerLocalScan</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:batchsizeperlocalscan-ndbd"/>
+
+ <para>
+ This parameter is used to calculate the number of lock
+ records used to handle concurrent scan operations.
+ </para>
+
+ <para>
+ The default value is 64; this value has a strong connection
+ to the <literal>ScanBatchSize</literal> defined in the SQL
+ nodes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LongMessageBuffer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-longmessagebuffer">
+ <literal>LongMessageBuffer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:longmessagebuffer-ndbd"/>
+
+ <para>
+ This is an internal buffer used for passing messages within
+ individual nodes and between nodes. Although it is highly
+ unlikely that this would need to be changed, it is
+ configurable. In MySQL Cluster NDB 6.4.3 and earlier, the
+ default is 1MB; beginning with MySQL Cluster NDB 7.0.4, it
+ is 4MB.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para id="mysql-cluster-memory-allocation">
+ <emphasis role="bold">Memory Allocation</emphasis>
+ </para>
+
+ <para id="ndbparam-ndbd-maxallocate">
+ <literal>MaxAllocate</literal>
+ </para>
+
+ <para>
+ This is the maximum size of the memory unit to use when
+ allocating memory for tables. In cases where
+ <literal role="se">NDB</literal> gives <errortext>Out of
+ memory</errortext> errors, but it is evident by examining the
+ cluster logs or the output of <literal>DUMP 1000</literal> (see
+ <xref linkend="ndb-internals-dump-command-1000"/>) that all
+ available memory has not yet been used, you can increase the
+ value of this parameter (or <literal>MaxNoOfTables</literal>, or
+ both) in order to cause <literal role="se">NDB</literal> to make
+ sufficient memory available.
+ </para>
+
+ <para>
+ This parameter was introduced in MySQL 5.1.20, MySQL Cluster NDB
+ 6.1.12 and MySQL Cluster NDB 6.2.3.
+ </para>
+
+ <para id="mysql-cluster-logging-and-checkpointing">
+ <emphasis role="bold">Logging and checkpointing</emphasis>
+ </para>
+
+ <para>
+ The following <literal>[ndbd]</literal> parameters control log
+ and checkpoint behavior.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfFragmentLogFiles</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-nooffragmentlogfiles">
+ <literal>NoOfFragmentLogFiles</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:nooffragmentlogfiles-ndbd"/>
+
+ <para>
+ This parameter sets the number of REDO log files for the
+ node, and thus the amount of space allocated to REDO
+ logging. Because the REDO log files are organized in a ring,
+ it is extremely important that the first and last log files
+ in the set (sometimes referred to as the <quote>head</quote>
+ and <quote>tail</quote> log files, respectively) do not
+ meet. When these approach one another too closely, the node
+ begins aborting all transactions encompassing updates due to
+ a lack of room for new log records.
+ </para>
+
+ <para>
+ A <literal>REDO</literal> log record is not removed until
+ the required number of local checkpoints has been completed
+ since that log record was inserted (prior to MySQL Cluster
+ NDB 6.3.8, this was 3 local checkpoints; in later versions
+ of MySQL Cluster, only 2 local checkpoints are necessary).
+ Checkpointing frequency is determined by its own set of
+ configuration parameters discussed elsewhere in this
+ chapter.
+ </para>
+
+ <para>
+ How these parameters interact and proposals for how to
+ configure them are discussed in
+ <xref linkend="mysql-cluster-config-lcp-params"/>.
+ </para>
+
+ <para>
+ The default parameter value is 16, which by default means 16
+ sets of 4 16MB files for a total of 1024MB. Beginning with
+ MySQL Cluster NDB 6.1.1, the size of the individual log
+ files is configurable using the
+ <literal>FragmentLogFileSize</literal> parameter; more
+ information about this parameter can be found
+ <link linkend="ndbparam-ndbd-fragmentlogfilesize">here</link>.
+ In scenarios requiring a great many updates, the value for
+ <literal>NoOfFragmentLogFiles</literal> may need to be set
+ as high as 300 or even higher to provide sufficient space
+ for REDO logs.
+ </para>
+
+ <para>
+ If the checkpointing is slow and there are so many writes to
+ the database that the log files are full and the log tail
+ cannot be cut without jeopardizing recovery, all updating
+ transactions are aborted with internal error code 410
+ (<literal>Out of log file space temporarily</literal>). This
+ condition prevails until a checkpoint has completed and the
+ log tail can be moved forward.
+ </para>
+
+ <important>
+ <para>
+ This parameter cannot be changed <quote>on the
+ fly</quote>; you must restart the node using
+ <option>--initial</option>. If you wish to change this
+ value for all data nodes in a running cluster, you can do
+ so via a rolling node restart (using
+ <option>--initial</option> when starting each data node).
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>FragmentLogFileSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-fragmentlogfilesize">
+ <literal>FragmentLogFileSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:fragmentlogfilesize-ndbd"/>
+
+ <para>
+ Setting this parameter allows you to control directly the
+ size of redo log files. This can be useful in situations
+ when MySQL Cluster is operating under a high load and it is
+ unable to close fragment log files quickly enough before
+ attempting to open new ones (only 2 fragment log files can
+ be open at one time); increasing the size of the fragment
+ log files gives the cluster more time before having to open
+ each new fragment log file. The default value for this
+ parameter is 16M. <literal>FragmentLogFileSize</literal> was
+ added in MySQL Cluster NDB 6.1.11.
+ </para>
+
+ <para>
+ For more information about fragment log files, see the
+ description of the
+ <link linkend="ndbparam-ndbd-nooffragmentlogfiles">NoOfFragmentLogFiles
+ parameter</link>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>InitFragmentLogFiles</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-initfragmentlogfiles">
+ <literal>InitFragmentLogFiles</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:initfragmentlogfiles-ndbd"/>
+
+ <para>
+ By default, fragment log files are created sparsely when
+ performing an initial start of a data node — that is,
+ depending on the operating system and file system in use,
+ not all bytes are necessarily written to disk. Beginning
+ with MySQL Cluster NDB 6.3.19, it is possible to override
+ this behavior and force all bytes to be written regardless
+ of the platform and file system type being used by mean of
+ this parameter.
+ </para>
+
+ <para>
+ <literal>InitFragmentLogFiles</literal> takes one of two
+ values:
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>SPARSE</literal>. Fragment log files are
+ created sparsely. This is the default value.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>FULL</literal>. Force all bytes of the
+ fragment log file to be written to disk.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ <para>
+ Depending on your operating system and file system, setting
+ <literal>InitFragmentLogFiles=FULL</literal> may help
+ eliminate I/O errors on writes to the REDO log.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfOpenFiles</primary>
+ </indexterm>
+
+ <remark role="todo">
+ If this doesn't ever need to be changed, then why is it even
+ mentioned? [js]
+ </remark>
+
+ <para id="ndbparam-ndbd-maxnoofopenfiles">
+ <literal>MaxNoOfOpenFiles</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnoofopenfiles-ndbd"/>
+
+ <para>
+ This parameter sets a ceiling on how many internal threads
+ to allocate for open files. <emphasis>Any situation
+ requiring a change in this parameter should be reported as a
+ bug</emphasis>.
+ </para>
+
+ <para>
+ The default value is 0. (Prior to MySQL 5.1.16, the default
+ was 40.) However, the minimum value to which this parameter
+ can be set is 20.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>InitialNoOfOpenFiles</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-initialnoofopenfiles">
+ <literal>InitialNoOfOpenFiles</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:initialnoofopenfiles-ndbd"/>
+
+ <para>
+ This parameter sets the initial number of internal threads
+ to allocate for open files.
+ </para>
+
+ <para>
+ The default value is 27.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfSavedMessages</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofsavedmessages">
+ <literal>MaxNoOfSavedMessages</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnoofsavedmessages-ndbd"/>
+
+ <para>
+ This parameter sets the maximum number of trace files that
+ are kept before overwriting old ones. Trace files are
+ generated when, for whatever reason, the node crashes.
+ </para>
+
+ <para>
+ The default is 25 trace files.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxLCPStartDelay</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxlcpstartdelay">
+ <literal>MaxLCPStartDelay</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxlcpstartdelay-ndbd"/>
+
+ <para>
+ In parallel data node recovery (supported in MySQL Cluster
+ NDB 6.3.8 and later), only table data is actually copied and
+ synchronized in parallel; synchronization of metadata such
+ as dictionary and checkpoint information is done in a serial
+ fashion. In addition, recovery of dictionary and checkpoint
+ information cannot be executed in parallel with performing
+ of local checkpoints. This means that, when starting or
+ restarting many data nodes concurrently, data nodes may be
+ forced to wait while a local checkpoint is performed, which
+ can result in longer node recovery times.
+ </para>
+
+ <para>
+ Beginning with MySQL Cluster NDB 6.3.23 and MySQL Cluster
+ NDB 6.4.3, it is possible to force a delay in the local
+ checkpoint to allow more (and possibly all) data nodes to
+ complete metadata synchronization; once each data
+ node's metadata synchronization is complete, all of the
+ data nodes can recover table data in parallel, even while
+ the local checkpoint is being executed.
+ </para>
+
+ <para>
+ To force such a delay, you can set
+ <literal>MaxLCPStartDelay</literal>, which determines the
+ number of seconds the cluster can wait to begin a local
+ checkpoint while data nodes continue to synchronize
+ metadata. This parameter should be set in the <literal>[ndbd
+ default]</literal> section of the
+ <filename>config.ini</filename> file, so that it is the same
+ for all data nodes. The maximum value is 600; the default is
+ 0.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Metadata objects</title>
+
+ <para id="mysql-cluster-metadata-objects">
+ The next set of <literal>[ndbd]</literal> parameters defines
+ pool sizes for metadata objects, used to define the maximum
+ number of attributes, tables, indexes, and trigger objects
+ used by indexes, events, and replication between clusters.
+ Note that these act merely as <quote>suggestions</quote> to
+ the cluster, and any that are not specified revert to the
+ default values shown.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfAttributes</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofattributes">
+ <literal>MaxNoOfAttributes</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnoofattributes-ndbd"/>
+
+ <para>
+ Defines the number of attributes that can be defined in the
+ cluster.
+ </para>
+
+ <para>
+ The default value is 1000, with the minimum possible value
+ being 32. The maximum is 4294967039. Each attribute consumes
+ around 200 bytes of storage per node due to the fact that
+ all metadata is fully replicated on the servers.
+ </para>
+
+ <para>
+ When setting <literal>MaxNoOfAttributes</literal>, it is
+ important to prepare in advance for any
+ <literal role="stmt">ALTER TABLE</literal> statements that
+ you might want to perform in the future. This is due to the
+ fact, during the execution of <literal role="stmt">ALTER
+ TABLE</literal> on a Cluster table, 3 times the number of
+ attributes as in the original table are used, and a good
+ practice is to allow double this amount. For example, if the
+ MySQL Cluster table having the greatest number of attributes
+ (<replaceable>greatest_number_of_attributes</replaceable>)
+ has 100 attributes, a good starting point for the value of
+ <literal>MaxNoOfAttributes</literal> would be <literal>6 *
+ <replaceable>greatest_number_of_attributes</replaceable> =
+ 600</literal>.
+ </para>
+
+ <para>
+ You should also estimate the average number of attributes
+ per table and multiply this by
+ <literal>MaxNoOfTables</literal>. If this value is larger
+ than the value obtained in the previous paragraph, you
+ should use the larger value instead.
+ </para>
+
+ <para>
+ Assuming that you can create all desired tables without any
+ problems, you should also verify that this number is
+ sufficient by trying an actual <literal role="stmt">ALTER
+ TABLE</literal> after configuring the parameter. If this is
+ not successful, increase
+ <literal>MaxNoOfAttributes</literal> by another multiple of
+ <literal>MaxNoOfTables</literal> and test it again.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfTables</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooftables">
+ <literal>MaxNoOfTables</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnooftables-ndbd"/>
+
+ <para>
+ A table object is allocated for each table, unique hash
+ index, and ordered index. This parameter sets the maximum
+ number of table objects for the cluster as a whole.
+ </para>
+
+ <para>
+ For each attribute that has a
+ <literal role="type">BLOB</literal> data type an extra table
+ is used to store most of the
+ <literal role="type">BLOB</literal> data. These tables also
+ must be taken into account when defining the total number of
+ tables.
+ </para>
+
+ <para>
+ The default value of this parameter is 128. The minimum is 8
+ and the maximum is 1600. Each table object consumes
+ approximately 20KB per node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfOrderedIndexes</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooforderedindexes">
+ <literal>MaxNoOfOrderedIndexes</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnooforderedindexes-ndbd"/>
+
+ <para>
+ For each ordered index in the cluster, an object is
+ allocated describing what is being indexed and its storage
+ segments. By default, each index so defined also defines an
+ ordered index. Each unique index and primary key has both an
+ ordered index and a hash index.
+ <literal>MaxNoOfOrderedIndexes</literal> sets the total
+ number of hash indexes that can be in use in the system at
+ any one time.
+ </para>
+
+ <para>
+ The default value of this parameter is 128. Each hash index
+ object consumes approximately 10KB of data per node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfUniqueHashIndexes</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofuniquehashindexes">
+ <literal>MaxNoOfUniqueHashIndexes</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnoofuniquehashindexes-ndbd"/>
+
+ <para>
+ For each unique index that is not a primary key, a special
+ table is allocated that maps the unique key to the primary
+ key of the indexed table. By default, an ordered index is
+ also defined for each unique index. To prevent this, you
+ must specify the <literal>USING HASH</literal> option when
+ defining the unique index.
+ </para>
+
+ <para>
+ The default value is 64. Each index consumes approximately
+ 15KB per node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfTriggers</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnooftriggers">
+ <literal>MaxNoOfTriggers</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnooftriggers-ndbd"/>
+
+ <para>
+ Internal update, insert, and delete triggers are allocated
+ for each unique hash index. (This means that three triggers
+ are created for each unique hash index.) However, an
+ <emphasis>ordered</emphasis> index requires only a single
+ trigger object. Backups also use three trigger objects for
+ each normal table in the cluster.
+ </para>
+
+ <para>
+ Replication between clusters also makes use of internal
+ triggers.
+ </para>
+
+ <para>
+ This parameter sets the maximum number of trigger objects in
+ the cluster.
+ </para>
+
+ <para>
+ The default value is 768.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxNoOfIndexes</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxnoofindexes">
+ <literal>MaxNoOfIndexes</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxnoofindexes-ndbd"/>
+
+ <para>
+ This parameter is deprecated in MySQL ¤t-series;; you
+ should use <literal>MaxNoOfOrderedIndexes</literal> and
+ <literal>MaxNoOfUniqueHashIndexes</literal> instead.
+ </para>
+
+ <para>
+ This parameter is used only by unique hash indexes. There
+ needs to be one record in this pool for each unique hash
+ index defined in the cluster.
+ </para>
+
+ <para>
+ The default value of this parameter is 128.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Boolean parameters</title>
+
+ <para id="mysql-cluster-boolean-parameters">
+ The behavior of data nodes is also affected by a set of
+ <literal>[ndbd]</literal> parameters taking on boolean values.
+ These parameters can each be specified as
+ <literal>TRUE</literal> by setting them equal to
+ <literal>1</literal> or <literal>Y</literal>, and as
+ <literal>FALSE</literal> by setting them equal to
+ <literal>0</literal> or <literal>N</literal>.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>LockPagesInMainMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-lockpagesinmainmemory">
+ <literal>LockPagesInMainMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:lockpagesinmainmemory-ndbd"/>
+
+ <para>
+ For a number of operating systems, including Solaris and
+ Linux, it is possible to lock a process into memory and so
+ avoid any swapping to disk. This can be used to help
+ guarantee the cluster's real-time characteristics.
+ </para>
+
+ <para>
+ Beginning with MySQL 5.1.15 and MySQL Cluster NDB 6.1.1,
+ this parameter takes one of the integer values
+ <literal>0</literal>, <literal>1</literal>, or
+ <literal>2</literal>, which act as follows:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>0</literal>: Disables locking. This is the
+ default value.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>1</literal>: Performs the lock after allocating
+ memory for the process.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>2</literal>: Performs the lock before memory
+ for the process is allocated.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ Previously, this parameter was a Boolean.
+ <literal>0</literal> or <literal>false</literal> was the
+ default setting, and disabled locking. <literal>1</literal>
+ or <literal>true</literal> enabled locking of the process
+ after its memory was allocated.
+
+ <important>
+ <para>
+ Beginning with MySQL 5.1.15 and MySQL Cluster NDB 6.1.1,
+ it is no longer possible to use <literal>true</literal>
+ or <literal>false</literal> for the value of this
+ parameter; when upgrading from a previous version, you
+ must change the value to <literal>0</literal>,
+ <literal>1</literal>, or <literal>2</literal>.
+ </para>
+ </important>
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StopOnError</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-stoponerror">
+ <literal>StopOnError</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:stoponerror-ndbd"/>
+
+ <para>
+ This parameter specifies whether an <command>ndbd</command>
+ process should exit or perform an automatic restart when an
+ error condition is encountered.
+ </para>
+
+ <para>
+ This feature is enabled by default.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Diskless</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-diskless">
+ <literal>Diskless</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:diskless-ndbd"/>
+
+ <para>
+ It is possible to specify MySQL Cluster tables as
+ <firstterm>diskless</firstterm>, meaning that tables are not
+ checkpointed to disk and that no logging occurs. Such tables
+ exist only in main memory. A consequence of using diskless
+ tables is that neither the tables nor the records in those
+ tables survive a crash. However, when operating in diskless
+ mode, it is possible to run <command>ndbd</command> on a
+ diskless computer.
+ </para>
+
+ <important>
+ <para>
+ This feature causes the <emphasis>entire</emphasis>
+ cluster to operate in diskless mode.
+ </para>
+ </important>
+
+ <para>
+ When this feature is enabled, Cluster online backup is
+ disabled. In addition, a partial start of the cluster is not
+ possible.
+ </para>
+
+ <para>
+ <literal>Diskless</literal> is disabled by default.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ODirect</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-odirect">
+ <literal>ODirect</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:odirect-ndbd"/>
+
+ <para>
+ Enabling this parameter causes
+ <literal role="se">NDB</literal> to attempt using
+ <literal>O_DIRECT</literal> writes for LCP, backups, and
+ redo logs, often lowering <command>kswapd</command> and CPU
+ usage. When using MySQL Cluster on Linux, enable
+ <literal>ODirect</literal> if you are using a 2.6 or kernel.
+ </para>
+
+ <para>
+ This parameter was added in the following releases:
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ MySQL 5.1.20
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ MySQL Cluster NDB 6.1.11
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ MySQL Cluster NDB 6.2.3
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ MySQL Cluster NDB 6.3.0
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ <para>
+ <literal>ODirect</literal> is disabled by default.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>RestartOnErrorInsert</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-restartonerrorinsert">
+ <literal>RestartOnErrorInsert</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:restartonerrorinsert-ndbd"/>
+
+ <para>
+ This feature is accessible only when building the debug
+ version where it is possible to insert errors in the
+ execution of individual blocks of code as part of testing.
+ </para>
+
+ <para>
+ This feature is disabled by default.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>CompressedBackup</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-compressedbackup">
+ <literal>CompressedBackup</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:compressedbackup-ndbd"/>
+
+ <para>
+ Setting this parameter to <literal>1</literal> causes backup
+ files to be compressed. The compression used is equivalent
+ to <command>gzip --fast</command>, and can save 50% or more
+ of the space required on the data node to store uncompressed
+ backup files. Compressed backups can be enabled for
+ individual data nodes, or for all data nodes (by setting
+ this parameter in the <literal>[ndbd default]</literal>
+ section of the <filename>config.ini</filename> file).
+ </para>
+
+ <important>
+ <para>
+ You cannot restore a compressed backup to a cluster
+ running a MySQL version that does not support this
+ feature.
+ </para>
+ </important>
+
+ <para>
+ The default value is <literal>0</literal> (disabled).
+ </para>
+
+ <para>
+ This parameter was introduced in MySQL Cluster NDB 6.3.7.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>CompressedLCP</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-compressedlcp">
+ <literal>CompressedLCP</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:compressedlcp-ndbd"/>
+
+ <para>
+ Setting this parameter to <literal>1</literal> causes local
+ checkpoint files to be compressed. The compression used is
+ equivalent to <command>gzip --fast</command>, and can save
+ 50% or more of the space required on the data node to store
+ uncompressed checkpoint files. Compressed LCPs can be
+ enabled for individual data nodes, or for all data nodes (by
+ setting this parameter in the <literal>[ndbd
+ default]</literal> section of the
+ <filename>config.ini</filename> file).
+ </para>
+
+ <important>
+ <para>
+ You cannot restore a compressed local checkpoint to a
+ cluster running a MySQL version that does not support this
+ feature.
+ </para>
+ </important>
+
+ <para>
+ The default value is <literal>0</literal> (disabled).
+ </para>
+
+ <para>
+ This parameter was introduced in MySQL Cluster NDB 6.3.7.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para id="mysql-cluster-timeouts-intervals-disk-paging">
+ <emphasis role="bold">Controlling Timeouts, Intervals, and Disk
+ Paging</emphasis>
+ </para>
+
+ <para>
+ There are a number of <literal>[ndbd]</literal> parameters
+ specifying timeouts and intervals between various actions in
+ Cluster data nodes. Most of the timeout values are specified in
+ milliseconds. Any exceptions to this are mentioned where
+ applicable.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenWatchDogCheck</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweenwatchdogcheck">
+ <literal>TimeBetweenWatchDogCheck</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:timebetweenwatchdogcheck-ndbd"/>
+
+ <para>
+ To prevent the main thread from getting stuck in an endless
+ loop at some point, a <quote>watchdog</quote> thread checks
+ the main thread. This parameter specifies the number of
+ milliseconds between checks. If the process remains in the
+ same state after three checks, the watchdog thread
+ terminates it.
+ </para>
+
+ <para>
+ This parameter can easily be changed for purposes of
+ experimentation or to adapt to local conditions. It can be
+ specified on a per-node basis although there seems to be
+ little reason for doing so.
+ </para>
+
+ <para>
+ The default timeout is 6000 milliseconds (6 seconds).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenWatchDogCheckInitial</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweenwatchdogcheckinitial">
+ <literal>TimeBetweenWatchDogCheckInitial</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:timebetweenwatchdogcheckinitial-ndbd"/>
+
+ <para>
+ This is similar to the
+ <literal>TimeBetweenWatchDogCheck</literal> parameter,
+ except that
+ <literal>TimeBetweenWatchDogCheckInitial</literal> controls
+ the amount of time that passes between execution checks
+ inside a database node in the early start phases during
+ which memory is allocated.
+ </para>
+
+ <para>
+ The default timeout is 6000 milliseconds (6 seconds).
+ </para>
+
+ <para>
+ This parameter was added in MySQL 5.1.20.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StartPartialTimeout</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-startpartialtimeout">
+ <literal>StartPartialTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:startpartialtimeout-ndbd"/>
+
+ <para>
+ This parameter specifies how long the Cluster waits for all
+ data nodes to come up before the cluster initialization
+ routine is invoked. This timeout is used to avoid a partial
+ Cluster startup whenever possible.
+ </para>
+
+ <para>
+ The default value is 30000 milliseconds (30 seconds). 0
+ disables the timeout, in which case the cluster may start
+ only if all nodes are available.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StartPartitionedTimeout</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-startpartitionedtimeout">
+ <literal>StartPartitionedTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:startpartitionedtimeout-ndbd"/>
+
+ <para>
+ If the cluster is ready to start after waiting for
+ <literal>StartPartialTimeout</literal> milliseconds but is
+ still possibly in a partitioned state, the cluster waits
+ until this timeout has also passed.
+ </para>
+
+ <para>
+ The default timeout is 60000 milliseconds (60 seconds).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>StartFailureTimeout</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-startfailuretimeout">
+ <literal>StartFailureTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:startfailuretimeout-ndbd"/>
+
+ <para>
+ If a data node has not completed its startup sequence within
+ the time specified by this parameter, the node startup
+ fails. Setting this parameter to 0 (the default value) means
+ that no data node timeout is applied.
+ </para>
+
+ <para>
+ For nonzero values, this parameter is measured in
+ milliseconds. For data nodes containing extremely large
+ amounts of data, this parameter should be increased. For
+ example, in the case of a data node containing several
+ gigabytes of data, a period as long as 10−15 minutes
+ (that is, 600000 to 1000000 milliseconds) might be required
+ to perform a node restart.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HeartbeatIntervalDbDb</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-heartbeatintervaldbdb">
+ <literal>HeartbeatIntervalDbDb</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:heartbeatintervaldbdb-ndbd"/>
+
+ <para>
+ One of the primary methods of discovering failed nodes is by
+ the use of heartbeats. This parameter states how often
+ heartbeat signals are sent and how often to expect to
+ receive them. After missing three heartbeat intervals in a
+ row, the node is declared dead. Thus, the maximum time for
+ discovering a failure through the heartbeat mechanism is
+ four times the heartbeat interval.
+ </para>
+
+ <para>
+ The default heartbeat interval is 1500 milliseconds (1.5
+ seconds). This parameter must not be changed drastically and
+ should not vary widely between nodes. If one node uses 5000
+ milliseconds and the node watching it uses 1000
+ milliseconds, obviously the node will be declared dead very
+ quickly. This parameter can be changed during an online
+ software upgrade, but only in small increments.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HeartbeatIntervalDbApi</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-heartbeatintervaldbapi">
+ <literal>HeartbeatIntervalDbApi</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:heartbeatintervaldbapi-ndbd"/>
+
+ <para>
+ Each data node sends heartbeat signals to each MySQL server
+ (SQL node) to ensure that it remains in contact. If a MySQL
+ server fails to send a heartbeat in time it is declared
+ <quote>dead,</quote> in which case all ongoing transactions
+ are completed and all resources released. The SQL node
+ cannot reconnect until all activities initiated by the
+ previous MySQL instance have been completed. The
+ three-heartbeat criteria for this determination are the same
+ as described for <literal>HeartbeatIntervalDbDb</literal>.
+ </para>
+
+ <para>
+ The default interval is 1500 milliseconds (1.5 seconds).
+ This interval can vary between individual data nodes because
+ each data node watches the MySQL servers connected to it,
+ independently of all other data nodes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenLocalCheckpoints</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweenlocalcheckpoints">
+ <literal>TimeBetweenLocalCheckpoints</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:timebetweenlocalcheckpoints-ndbd"/>
+
+ <para>
+ This parameter is an exception in that it does not specify a
+ time to wait before starting a new local checkpoint; rather,
+ it is used to ensure that local checkpoints are not
+ performed in a cluster where relatively few updates are
+ taking place. In most clusters with high update rates, it is
+ likely that a new local checkpoint is started immediately
+ after the previous one has been completed.
+ </para>
+
+ <para>
+ The size of all write operations executed since the start of
+ the previous local checkpoints is added. This parameter is
+ also exceptional in that it is specified as the base-2
+ logarithm of the number of 4-byte words, so that the default
+ value 20 means 4MB (4 ×
+ 2<superscript>20</superscript>) of write operations, 21
+ would mean 8MB, and so on up to a maximum value of 31, which
+ equates to 8GB of write operations.
+ </para>
+
+ <para>
+ All the write operations in the cluster are added together.
+ Setting <literal>TimeBetweenLocalCheckpoints</literal> to 6
+ or less means that local checkpoints will be executed
+ continuously without pause, independent of the cluster's
+ workload.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenGlobalCheckpoints</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweenglobalcheckpoints">
+ <literal>TimeBetweenGlobalCheckpoints</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:timebetweenglobalcheckpoints-ndbd"/>
+
+ <para>
+ When a transaction is committed, it is committed in main
+ memory in all nodes on which the data is mirrored. However,
+ transaction log records are not flushed to disk as part of
+ the commit. The reasoning behind this behavior is that
+ having the transaction safely committed on at least two
+ autonomous host machines should meet reasonable standards
+ for durability.
+ </para>
+
+ <para>
+ It is also important to ensure that even the worst of cases
+ — a complete crash of the cluster — is handled
+ properly. To guarantee that this happens, all transactions
+ taking place within a given interval are put into a global
+ checkpoint, which can be thought of as a set of committed
+ transactions that has been flushed to disk. In other words,
+ as part of the commit process, a transaction is placed in a
+ global checkpoint group. Later, this group's log records are
+ flushed to disk, and then the entire group of transactions
+ is safely committed to disk on all computers in the cluster.
+ </para>
+
+ <para>
+ This parameter defines the interval between global
+ checkpoints. The default is 2000 milliseconds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenEpochs</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweenepochs">
+ <literal>TimeBetweenEpochs</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:timebetweenepochs-ndbd"/>
+
+ <para>
+ This parameter defines the interval between synchronisation
+ epochs for MySQL Cluster Replication. The default value is
+ 100 milliseconds.
+ </para>
+
+ <para>
+ <literal>TimeBetweenEpochs</literal> is part of the
+ implementation of <quote>micro-GCPs</quote>, which can be
+ used to improve the performance of MySQL Cluster
+ Replication. This parameter was introduced in MySQL Cluster
+ NDB 6.2.5 and MySQL Cluster NDB 6.3.2.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenEpochsTimeout</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweenepochstimeout">
+ <literal>TimeBetweenEpochsTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:timebetweenepochstimeout-ndbd"/>
+
+ <para>
+ This parameter defines a timeout for synchronisation epochs
+ for MySQL Cluster Replication. If a node fails to
+ participate in a global checkpoint within the time
+ determined by this parameter, the node is shut down. The
+ default value is 4000 milliseconds.
+ </para>
+
+ <para>
+ <literal>TimeBetweenEpochsTimeout</literal> is part of the
+ implementation of <quote>micro-GCPs</quote>, which can be
+ used to improve the performance of MySQL Cluster
+ Replication. This parameter was introduced in MySQL Cluster
+ NDB 6.2.7 and MySQL Cluster NDB 6.3.4.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxBufferedEpochs</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-maxbufferedepochs">
+ <literal>MaxBufferedEpochs</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxbufferedepochs-ndbd"/>
+
+ <para>
+ The number of unprocessed epochs by which a subscribing node
+ can lag behind. Exceeding this number causes a lagging
+ subscriber to be disconnected.
+ </para>
+
+ <para>
+ The default value of 100 is sufficient for most normal
+ operations. If a subscribing node does lag enough to cause
+ disconnections, it is usually due to network or scheduling
+ issues with regard to processes or threads. (In rare
+ circumstances, the problem may be due to a bug in the
+ <literal role="se">NDB</literal> client.) It may be
+ desirable to set the value lower than the default when
+ epochs are longer.
+ </para>
+
+ <para>
+ Disconnection prevents client issues from affecting the data
+ node service, running out of memory to buffer data, and
+ eventually shutting down. Instead, only the client is
+ affected as a result of the disconnect (by, for example gap
+ events in the binlog), forcing the client to reconnect or
+ restart the process.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TimeBetweenInactiveTransactionAbortCheck</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-timebetweeninactivetransactionabortcheck">
+ <literal>TimeBetweenInactiveTransactionAbortCheck</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:timebetweeninactivetransactionabortcheck-ndbd"/>
+
+ <para>
+ Timeout handling is performed by checking a timer on each
+ transaction once for every interval specified by this
+ parameter. Thus, if this parameter is set to 1000
+ milliseconds, every transaction will be checked for timing
+ out once per second.
+ </para>
+
+ <para>
+ The default value is 1000 milliseconds (1 second).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TransactionInactiveTimeout (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-transactioninactivetimeout">
+ <literal>TransactionInactiveTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:transactioninactivetimeout-ndbd"/>
+
+ <para>
+ This parameter states the maximum time that is permitted to
+ lapse between operations in the same transaction before the
+ transaction is aborted.
+ </para>
+
+ <para>
+ The default for this parameter is zero (no timeout). For a
+ real-time database that needs to ensure that no transaction
+ keeps locks for too long, this parameter should be set to a
+ relatively small value. The unit is milliseconds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TransactionDeadlockDetectionTimeout</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-transactiondeadlockdetectiontimeout">
+ <literal>TransactionDeadlockDetectionTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:transactiondeadlockdetectiontimeout-ndbd"/>
+
+ <para>
+ When a node executes a query involving a transaction, the
+ node waits for the other nodes in the cluster to respond
+ before continuing. A failure to respond can occur for any of
+ the following reasons:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The node is <quote>dead</quote>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The operation has entered a lock queue
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The node requested to perform the action could be
+ heavily overloaded.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ This timeout parameter states how long the transaction
+ coordinator waits for query execution by another node before
+ aborting the transaction, and is important for both node
+ failure handling and deadlock detection. In MySQL 5.1.10 and
+ earlier versions, setting it too high could cause
+ undesirable behavior in situations involving deadlocks and
+ node failure. Beginning with MySQL 5.1.11, active
+ transactions occurring during node failures are actively
+ aborted by the MySQL Cluster Transaction Coordinator, and so
+ high settings are no longer an issue with this parameter.
+ </para>
+
+ <para>
+ The default timeout value is 1200 milliseconds (1.2
+ seconds).
+ </para>
+
+ <para>
+ Prior to MySQL Cluster NDB versions 6.2.18, 6.3.24, and
+ 7.0.5, the effective minimum for this parameter was 100
+ milliseconds. (Bug#44099) Beginning with these versions, the
+ actual minimum is 50 milliseconds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>DiskSyncSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-disksyncsize">
+ <literal>DiskSyncSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:disksyncsize-ndbd"/>
+
+ <para>
+ This is the maximum number of bytes to store before flushing
+ data to a local checkpoint file. This is done in order to
+ prevent write buffering, which can impede performance
+ significantly. This parameter is <emphasis>not</emphasis>
+ intended to take the place of
+ <literal>TimeBetweenLocalCheckpoints</literal>.
+ </para>
+
+ <note>
+ <para>
+ When <literal>ODirect</literal> is enabled, it is not
+ necessary to set <literal>DiskSyncSize</literal>; in fact,
+ in such cases its value is simply ignored.
+ </para>
+ </note>
+
+ <para>
+ The default value is 4M (4 megabytes).
+ </para>
+
+ <para>
+ This parameter was added in MySQL 5.1.12.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>DiskCheckpointSpeed</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-diskcheckpointspeed">
+ <literal>DiskCheckpointSpeed</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:diskcheckpointspeed-ndbd"/>
+
+ <para>
+ The amount of data,in bytes per second, that is sent to disk
+ during a local checkpoint.
+ </para>
+
+ <para>
+ The default value is 10M (10 megabytes per second).
+ </para>
+
+ <para>
+ This parameter was added in MySQL 5.1.12.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>DiskCheckpointSpeedInRestart</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-diskcheckpointspeedinrestart">
+ <literal>DiskCheckpointSpeedInRestart</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:diskcheckpointspeedinrestart-ndbd"/>
+
+ <para>
+ The amount of data,in bytes per second, that is sent to disk
+ during a local checkpoint as part of a restart operation.
+ </para>
+
+ <para>
+ The default value is 100M (100 megabytes per second).
+ </para>
+
+ <para>
+ This parameter was added in MySQL 5.1.12.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskAfterRestartTUP (DEPRECATED)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofdiskpagestodiskafterrestarttup">
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:noofdiskpagestodiskafterrestarttup-ndbd"/>
+
+ <para>
+ When executing a local checkpoint, the algorithm flushes all
+ data pages to disk. Merely doing so as quickly as possible
+ without any moderation is likely to impose excessive loads
+ on processors, networks, and disks. To control the write
+ speed, this parameter specifies how many pages per 100
+ milliseconds are to be written. In this context, a
+ <quote>page</quote> is defined as 8KB. This parameter is
+ specified in units of 80KB per second, so setting
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> to a
+ value of <literal>20</literal> entails writing 1.6MB in data
+ pages to disk each second during a local checkpoint. This
+ value includes the writing of UNDO log records for data
+ pages. That is, this parameter handles the limitation of
+ writes from data memory. (See the entry for
+ <literal>IndexMemory</literal> for information about index
+ pages.)
+ </para>
+
+ <para>
+ In short, this parameter specifies how quickly to execute
+ local checkpoints. It operates in conjunction with
+ <literal>NoOfFragmentLogFiles</literal>,
+ <literal>DataMemory</literal>, and
+ <literal>IndexMemory</literal>.
+ </para>
+
+ <para>
+ For more information about the interaction between these
+ parameters and possible strategies for choosing appropriate
+ values for them, see
+ <xref linkend="mysql-cluster-config-lcp-params"/>.
+ </para>
+
+ <para>
+ The default value is 40 (3.2MB of data pages per second).
+ </para>
+
+ <note>
+ <para>
+ This parameter is deprecated as of MySQL 5.1.6. For MySQL
+ 5.1.12 and later versions, use
+ <link linkend="ndbparam-ndbd-diskcheckpointspeed">DiskCheckpointSpeed</link>
+ and
+ <link linkend="ndbparam-ndbd-disksyncsize">DiskSyncSize</link>
+ instead.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskAfterRestartACC (DEPRECATED)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofdiskpagestodiskafterrestartacc">
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:noofdiskpagestodiskafterrestartacc-ndbd"/>
+
+ <para>
+ This parameter uses the same units as
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> and
+ acts in a similar fashion, but limits the speed of writing
+ index pages from index memory.
+ </para>
+
+ <para>
+ The default value of this parameter is 20 (1.6MB of index
+ memory pages per second).
+ </para>
+
+ <note>
+ <para>
+ This parameter is deprecated as of MySQL 5.1.6. For MySQL
+ 5.1.12 and later versions, use
+ <link linkend="ndbparam-ndbd-diskcheckpointspeed">DiskCheckpointSpeed</link>
+ and
+ <link linkend="ndbparam-ndbd-disksyncsize">DiskSyncSize</link>.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskDuringRestartTUP (DEPRECATED)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofdiskpagestodiskduringrestarttup">
+ <literal>NoOfDiskPagesToDiskDuringRestartTUP</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:noofdiskpagestodiskduringrestarttup-ndbd"/>
+
+ <para>
+ This parameter is used in a fashion similar to
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> and
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal>, only
+ it does so with regard to local checkpoints executed in the
+ node when a node is restarting. A local checkpoint is always
+ performed as part of all node restarts. During a node
+ restart it is possible to write to disk at a higher speed
+ than at other times, because fewer activities are being
+ performed in the node.
+ </para>
+
+ <para>
+ This parameter covers pages written from data memory.
+ </para>
+
+ <para>
+ The default value is 40 (3.2MB per second).
+ </para>
+
+ <note>
+ <para>
+ This parameter is deprecated as of MySQL 5.1.6. For MySQL
+ 5.1.12 and later versions, use
+ <link linkend="ndbparam-ndbd-diskcheckpointspeedinrestart">DiskCheckpointSpeedInRestart</link>
+ and
+ <link linkend="ndbparam-ndbd-disksyncsize">DiskSyncSize</link>.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskDuringRestartACC (DEPRECATED)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-noofdiskpagestodiskduringrestartacc">
+ <literal>NoOfDiskPagesToDiskDuringRestartACC</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:noofdiskpagestodiskduringrestartacc-ndbd"/>
+
+ <para>
+ Controls the number of index memory pages that can be
+ written to disk during the local checkpoint phase of a node
+ restart.
+ </para>
+
+ <para>
+ As with
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> and
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal>,
+ values for this parameter are expressed in terms of 8KB
+ pages written per 100 milliseconds (80KB/second).
+ </para>
+
+ <para>
+ The default value is 20 (1.6MB per second).
+ </para>
+
+ <note>
+ <para>
+ This parameter is deprecated as of MySQL 5.1.6. For MySQL
+ 5.1.12 and later versions, use
+ <link linkend="ndbparam-ndbd-diskcheckpointspeedinrestart">DiskCheckpointSpeedInRestart</link>
+ and
+ <link linkend="ndbparam-ndbd-disksyncsize">DiskSyncSize</link>.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationTimeout (DEPRECATED)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-arbitrationtimeout">
+ <literal>ArbitrationTimeout</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:arbitrationtimeout-ndbd"/>
+
+ <para>
+ This parameter specifies how long data nodes wait for a
+ response from the arbitrator to an arbitration message. If
+ this is exceeded, the network is assumed to have split.
+ </para>
+
+ <para>
+ The default value is 1000 milliseconds (1 second).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Arbitration</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-arbitration">
+ <literal>Arbitration</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:arbitration-ndbd"/>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:arbitration-ndbd"/>
+
+ <para>
+ The <literal>Arbitration</literal> parameter, added in MySQL
+ Cluster NDB 7.0.7, allows a choice of arbitration schemes,
+ corresponding to one of 3 possible values for this
+ parameter:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title><literal>Default</literal></title>
+
+ <para>
+ This allows arbitration to proceed normally, as
+ determined by the <literal>ArbitrationRank</literal>
+ settings for the management and API nodes. This is the
+ default value.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title><literal>Disabled</literal></title>
+
+ <para>
+ Previously, it was possible to disable arbitration
+ only by setting <literal>ArbitrationRank</literal> to
+ 0 on all management and API nodes. Now, you can now
+ use <literal>Arbitration = Disabled</literal> in the
+ <literal>[ndbd default]</literal> section of the
+ <filename>config.ini</filename> file to accomplish
+ this task. In this case, any
+ <literal>ArbitrationRank</literal> settings are
+ ignored.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title><literal>WaitExternal</literal></title>
+
+ <para>
+ The <literal>Arbitration</literal> parameter also
+ makes it possible to configure arbitration in such a
+ way that the cluster waits until after the time
+ determined by <literal>ArbitrationTimeout</literal>
+ has passed for an external cluster manager application
+ to perform arbitration instead of handling arbitration
+ internally. This can be done by setting
+ <literal>Arbitration = WaitExternal</literal> in the
+ <literal>[ndbd default]</literal> section of the
+ <filename>config.ini</filename> file. For best results
+ with the <literal>WaitExternal</literal> setting, it
+ is recommended that
+ <literal>ArbitrationTimeout</literal> be 2 times as
+ long as the interval required by the external cluster
+ manager to perform arbitration.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+
+ <important>
+ <para>
+ This parameter should be used only in the <literal>[ndbd
+ default]</literal> section of the cluster configuration
+ file. The behavior of the cluster is unspecified when
+ <literal>Arbitration</literal> is set to different values
+ for individual data nodes.
+ </para>
+ </important>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Buffering and logging</title>
+
+ <para id="mysql-cluster-buffering-and-logging">
+ Several <literal>[ndbd]</literal> configuration parameters
+ enable the advanced user to have more control over the
+ resources used by node processes and to adjust various buffer
+ sizes at need.
+ </para>
+
+ </formalpara>
+
+ <para>
+ These buffers are used as front ends to the file system when
+ writing log records to disk. If the node is running in diskless
+ mode, these parameters can be set to their minimum values
+ without penalty due to the fact that disk writes are
+ <quote>faked</quote> by the <literal role="se">NDB</literal>
+ storage engine's file system abstraction layer.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>UndoIndexBuffer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-undoindexbuffer">
+ <literal>UndoIndexBuffer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:undoindexbuffer-ndbd"/>
+
+ <para>
+ The UNDO index buffer, whose size is set by this parameter,
+ is used during local checkpoints. The
+ <literal role="se">NDB</literal> storage engine uses a
+ recovery scheme based on checkpoint consistency in
+ conjunction with an operational REDO log. To produce a
+ consistent checkpoint without blocking the entire system for
+ writes, UNDO logging is done while performing the local
+ checkpoint. UNDO logging is activated on a single table
+ fragment at a time. This optimization is possible because
+ tables are stored entirely in main memory.
+ </para>
+
+ <para>
+ The UNDO index buffer is used for the updates on the primary
+ key hash index. Inserts and deletes rearrange the hash
+ index; the NDB storage engine writes UNDO log records that
+ map all physical changes to an index page so that they can
+ be undone at system restart. It also logs all active insert
+ operations for each fragment at the start of a local
+ checkpoint.
+ </para>
+
+ <para>
+ Reads and updates set lock bits and update a header in the
+ hash index entry. These changes are handled by the
+ page-writing algorithm to ensure that these operations need
+ no UNDO logging.
+ </para>
+
+ <para>
+ This buffer is 2MB by default. The minimum value is 1MB,
+ which is sufficient for most applications. For applications
+ doing extremely large or numerous inserts and deletes
+ together with large transactions and large primary keys, it
+ may be necessary to increase the size of this buffer. If
+ this buffer is too small, the NDB storage engine issues
+ internal error code 677 (<literal>Index UNDO buffers
+ overloaded</literal>).
+ </para>
+
+ <important>
+ <para>
+ It is not safe to decrease the value of this parameter
+ during a rolling restart.
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>UndoDataBuffer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-undodatabuffer">
+ <literal>UndoDataBuffer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:undodatabuffer-ndbd"/>
+
+ <para>
+ This parameter sets the size of the UNDO data buffer, which
+ performs a function similar to that of the UNDO index
+ buffer, except the UNDO data buffer is used with regard to
+ data memory rather than index memory. This buffer is used
+ during the local checkpoint phase of a fragment for inserts,
+ deletes, and updates.
+ </para>
+
+ <para>
+ Because UNDO log entries tend to grow larger as more
+ operations are logged, this buffer is also larger than its
+ index memory counterpart, with a default value of 16MB.
+ </para>
+
+ <para>
+ This amount of memory may be unnecessarily large for some
+ applications. In such cases, it is possible to decrease this
+ size to a minimum of 1MB.
+ </para>
+
+ <para>
+ It is rarely necessary to increase the size of this buffer.
+ If there is such a need, it is a good idea to check whether
+ the disks can actually handle the load caused by database
+ update activity. A lack of sufficient disk space cannot be
+ overcome by increasing the size of this buffer.
+ </para>
+
+ <para>
+ If this buffer is too small and gets congested, the NDB
+ storage engine issues internal error code 891
+ (<errortext>Data UNDO buffers overloaded</errortext>).
+ </para>
+
+ <important>
+ <para>
+ It is not safe to decrease the value of this parameter
+ during a rolling restart.
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>RedoBuffer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-redobuffer">
+ <literal>RedoBuffer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:redobuffer-ndbd"/>
+
+ <para>
+ All update activities also need to be logged. The REDO log
+ makes it possible to replay these updates whenever the
+ system is restarted. The NDB recovery algorithm uses a
+ <quote>fuzzy</quote> checkpoint of the data together with
+ the UNDO log, and then applies the REDO log to play back all
+ changes up to the restoration point.
+ </para>
+
+ <para>
+ <literal>RedoBuffer</literal> sets the size of the buffer in
+ which the REDO log is written. In MySQL Cluster NDB 6.4.3
+ and earlier, the default value is 8MB; beginning with MySQL
+ Cluster NDB 7.0.4, the default is 32MB. The minimum value is
+ 1MB.
+ </para>
+
+ <para>
+ If this buffer is too small, the NDB storage engine issues
+ error code 1221 (<literal>REDO log buffers
+ overloaded</literal>).
+ </para>
+
+ <important>
+ <para>
+ It is not safe to decrease the value of this parameter
+ during a rolling restart.
+ </para>
+ </important>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Controlling log messages</title>
+
+ <para id="mysql-cluster-controlling-log-messages">
+ In managing the cluster, it is very important to be able to
+ control the number of log messages sent for various event
+ types to <literal>stdout</literal>. For each event category,
+ there are 16 possible event levels (numbered 0 through 15).
+ Setting event reporting for a given event category to level 15
+ means all event reports in that category are sent to
+ <literal>stdout</literal>; setting it to 0 means that there
+ will be no event reports made in that category.
+ </para>
+
+ </formalpara>
+
+ <para>
+ By default, only the startup message is sent to
+ <literal>stdout</literal>, with the remaining event reporting
+ level defaults being set to 0. The reason for this is that these
+ messages are also sent to the management server's cluster log.
+ </para>
+
+ <para>
+ An analogous set of levels can be set for the management client
+ to determine which event levels to record in the cluster log.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelStartup</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelstartup">
+ <literal>LogLevelStartup</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:loglevelstartup-ndbd"/>
+
+ <para>
+ The reporting level for events generated during startup of
+ the process.
+ </para>
+
+ <para>
+ The default level is 1.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelShutdown</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelshutdown">
+ <literal>LogLevelShutdown</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:loglevelshutdown-ndbd"/>
+
+ <para>
+ The reporting level for events generated as part of graceful
+ shutdown of a node.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelStatistic (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelstatistic">
+ <literal>LogLevelStatistic</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:loglevelstatistic-ndbd"/>
+
+ <para>
+ The reporting level for statistical events such as number of
+ primary key reads, number of updates, number of inserts,
+ information relating to buffer usage, and so on.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelCheckpoint (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelcheckpoint">
+ <literal>LogLevelCheckpoint</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:loglevelcheckpoint-ndbd"/>
+
+ <para>
+ The reporting level for events generated by local and global
+ checkpoints.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelNodeRestart (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelnoderestart">
+ <literal>LogLevelNodeRestart</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:loglevelnoderestart-ndbd"/>
+
+ <para>
+ The reporting level for events generated during node
+ restart.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelConnection (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelconnection">
+ <literal>LogLevelConnection</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:loglevelconnection-ndbd"/>
+
+ <para>
+ The reporting level for events generated by connections
+ between cluster nodes.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelError</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelerror">
+ <literal>LogLevelError</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:loglevelerror-ndbd"/>
+
+ <para>
+ The reporting level for events generated by errors and
+ warnings by the cluster as a whole. These errors do not
+ cause any node failure but are still considered worth
+ reporting.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelCongestion</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelcongestion">
+ <literal>LogLevelCongestion</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:loglevelcongestion-ndbd"/>
+
+ <para>
+ The reporting level for events generated by congestion.
+ These errors do not cause node failure but are still
+ considered worth reporting.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LogLevelInfo</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-loglevelinfo">
+ <literal>LogLevelInfo</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:loglevelinfo-ndbd"/>
+
+ <para>
+ The reporting level for events generated for information
+ about the general state of the cluster.
+ </para>
+
+ <para>
+ The default level is 0.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MemReportFrequency</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-memreportfrequency">
+ <literal>MemReportFrequency</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:memreportfrequency-ndbd"/>
+
+ <para>
+ This parameter controls how often data node memory usage
+ reports are recorded in the cluster log; it is an integer
+ value representing the number of seconds between reports.
+ </para>
+
+ <para>
+ Each data node's data memory and index memory usage is
+ logged as both a percentage and a number of 32 KB pages of
+ the <literal>DataMemory</literal> and
+ <literal>IndexMemory</literal>, respectively, set in the
+ <filename>config.ini</filename> file. For example, if
+ <literal>DataMemory</literal> is equal to 100 MB, and a
+ given data node is using 50 MB for data memory storage, the
+ corresponding line in the cluster log might look like this:
+ </para>
+
+<programlisting>
+2006-12-24 01:18:16 [MgmSrvr] INFO -- Node 2: Data usage is 50%(1280 32K pages of total 2560)
+</programlisting>
+
+ <para>
+ <literal>MemReportFrequency</literal> is not a required
+ parameter. If used, it can be set for all cluster data nodes
+ in the <literal>[ndbd default]</literal> section of
+ <filename>config.ini</filename>, and can also be set or
+ overridden for individual data nodes in the corresponding
+ <literal>[ndbd]</literal> sections of the configuration
+ file. The minimum value — which is also the default
+ value — is 0, in which case memory reports are logged
+ only when memory usage reaches certain percentages (80%,
+ 90%, and 100%), as mentioned in the discussion of statistics
+ events in <xref linkend="mysql-cluster-log-events"/>.
+ </para>
+
+ <para>
+ This parameter was added in MySQL Cluster 5.1.16 and MySQL
+ Cluster NDB 6.1.0.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara>
+
+ <title>Backup parameters</title>
+
+ <para id="mysql-cluster-backup-parameters">
+ The <literal>[ndbd]</literal> parameters discussed in this
+ section define memory buffers set aside for execution of
+ online backups.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupDataBufferSize (MySQL Cluster configuration parameter)</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupdatabuffersize">
+ <literal>BackupDataBufferSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:backupdatabuffersize-ndbd"/>
+
+ <para>
+ In creating a backup, there are two buffers used for sending
+ data to the disk. The backup data buffer is used to fill in
+ data recorded by scanning a node's tables. Once this buffer
+ has been filled to the level specified as
+ <literal>BackupWriteSize</literal> (see below), the pages
+ are sent to disk. While flushing data to disk, the backup
+ process can continue filling this buffer until it runs out
+ of space. When this happens, the backup process pauses the
+ scan and waits until some disk writes have completed freed
+ up memory so that scanning may continue.
+ </para>
+
+ <para>
+ In MySQL Cluster NDB 6.4.3 and earlier, the default value is
+ 2MB; in MySQL Cluster NDB 7.0.4 and later, it is 16MB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupLogBufferSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backuplogbuffersize">
+ <literal>BackupLogBufferSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:backuplogbuffersize-ndbd"/>
+
+ <para>
+ The backup log buffer fulfills a role similar to that played
+ by the backup data buffer, except that it is used for
+ generating a log of all table writes made during execution
+ of the backup. The same principles apply for writing these
+ pages as with the backup data buffer, except that when there
+ is no more space in the backup log buffer, the backup fails.
+ For that reason, the size of the backup log buffer must be
+ large enough to handle the load caused by write activities
+ while the backup is being made. See
+ <xref linkend="mysql-cluster-backup-configuration"/>.
+ </para>
+
+ <para>
+ The default value for this parameter should be sufficient
+ for most applications. In fact, it is more likely for a
+ backup failure to be caused by insufficient disk write speed
+ than it is for the backup log buffer to become full. If the
+ disk subsystem is not configured for the write load caused
+ by applications, the cluster is unlikely to be able to
+ perform the desired operations.
+ </para>
+
+ <para>
+ It is preferable to configure cluster nodes in such a manner
+ that the processor becomes the bottleneck rather than the
+ disks or the network connections.
+ </para>
+
+ <para>
+ In MySQL Cluster NDB 6.4.3 and earlier, the default value is
+ 2MB; in MySQL Cluster NDB 7.0.4 and later, it is 16MB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupmemory">
+ <literal>BackupMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:backupmemory-ndbd"/>
+
+ <para>
+ This parameter is simply the sum of
+ <literal>BackupDataBufferSize</literal> and
+ <literal>BackupLogBufferSize</literal>.
+ </para>
+
+ <para>
+ In MySQL Cluster NDB 6.4.3 and earlier, the default value
+ was 2MB + 2MB = 4MB; in MySQL Cluster NDB 7.0.4 and later,
+ it is 16MB + 16MB = 32MB.
+ </para>
+
+ <important>
+ <para>
+ If <literal>BackupDataBufferSize</literal> and
+ <literal>BackupLogBufferSize</literal> taken together
+ exceed the default value for
+ <literal>BackupMemory</literal>, then this parameter must
+ be set explicitly in the <filename>config.ini</filename>
+ file to their sum.
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupReportFrequency</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupreportfrequency">
+ <literal>BackupReportFrequency</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:backupreportfrequency-ndbd"/>
+
+ <para>
+ This parameter controls how often backup status reports are
+ issued in the management client during a backup, as well as
+ how often such reports are written to the cluster log
+ (provided cluster event logging is configured to allow it
+ — see
+ <xref linkend="mysql-cluster-logging-and-checkpointing"/>).
+ <literal>BackupReportFrequency</literal> represents the time
+ in seconds between backup status reports.
+ </para>
+
+ <para>
+ The default value is 0.
+ </para>
+
+ <para>
+ This parameter was added in MySQL Cluster NDB 6.2.3.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupWriteSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupwritesize">
+ <literal>BackupWriteSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:backupwritesize-ndbd"/>
+
+ <para>
+ This parameter specifies the default size of messages
+ written to disk by the backup log and backup data buffers.
+ </para>
+
+ <para>
+ In MySQL Cluster 6.4.3 and earlier, the default value for
+ this parameter was 32KB; beginning with MySQL Cluster NDB
+ 7.0.4, it is 256KB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BackupMaxWriteSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-backupmaxwritesize">
+ <literal>BackupMaxWriteSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:backupmaxwritesize-ndbd"/>
+
+ <para>
+ This parameter specifies the maximum size of messages
+ written to disk by the backup log and backup data buffers.
+ </para>
+
+ <para>
+ In MySQL Cluster 6.4.3 and earlier, the default value for
+ this parameter was 256KB; beginning with MySQL Cluster NDB
+ 7.0.4, it is 1MB.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <important>
+ <para>
+ When specifying these parameters, the following relationships
+ must hold true. Otherwise, the data node will be unable to
+ start:
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>BackupDataBufferSize >= BackupWriteSize
+ + 188KB</literal>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>BackupLogBufferSize >= BackupWriteSize
+ + 16KB</literal>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>BackupMaxWriteSize >=
+ BackupWriteSize</literal>
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+ </important>
+
+ <para id="mysql-cluster-realtime-performance-parameters">
+ <emphasis role="bold">Realtime Performance Parameters</emphasis>
+ </para>
+
+ <para>
+ The <literal>[ndbd]</literal> parameters discussed in this
+ section are used in scheduling and locking of threads to
+ specific CPUs on multiprocessor data node hosts. They were
+ introduced in MySQL Cluster NDB 6.3.4.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>LockExecuteThreadToCPU</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-lockexecutethreadtocpu">
+ <literal>LockExecuteThreadToCPU</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:lockexecutethreadtocpu-ndbd"/>
+
+ <formalpara>
+
+ <title>Previous to MySQL Cluster NDB 7.0</title>
+
+ <para>
+ This parameter specifies the ID of the CPU assigned to
+ handle the <literal role="se">NDBCLUSTER</literal>
+ execution thread. The value of this parameter is an
+ integer in the range 0 to 65535 (inclusive). The default
+ is 65535.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>MySQL Cluster NDB 7.0 and later (beginning with MySQL Cluster NDB 6.4.0)</title>
+
+ <para>
+ When used with <command>ndbd</command>, this parameter
+ (now a string) specifies the ID of the CPU assigned to
+ handle the <literal role="se">NDBCLUSTER</literal>
+ execution thread. When used with
+ <command>ndbmtd</command>, the value of this parameter is
+ a comma-separated list of CPU IDs assigned to handle
+ execution threads. Each CPU ID in the list should be an
+ integer in the range 0 to 65535 (inclusive). The number of
+ IDs specified should match the number of execution threads
+ determined by <literal>MaxNoOfExecutionThreads</literal>.
+ There is no default value.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>LockMaintThreadsToCPU</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-lockmaintthreadstocpu">
+ <literal>LockMaintThreadsToCPU</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:lockmaintthreadstocpu-ndbd"/>
+
+ <para>
+ This parameter specifies the ID of the CPU assigned to
+ handle <literal role="se">NDBCLUSTER</literal> maintenance
+ threads.
+ </para>
+
+ <para>
+ The value of this parameter is an integer in the range 0 to
+ 65535 (inclusive). This parameter was added in MySQL Cluster
+ NDB 6.3.4. Prior to MySQL Cluster NDB 6.4.0, the default is
+ 65535; in MySQL Cluster NDB 7.0 and later MySQL Cluster
+ release series, there is no default value.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>RealtimeScheduler</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-realtimescheduler">
+ <literal>RealtimeScheduler</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:realtimescheduler-ndbd"/>
+
+ <para>
+ Setting this parameter to 1 enables real-time scheduling of
+ <literal role="se">NDBCLUSTER</literal> threads.
+ </para>
+
+ <para>
+ The default is 0 (scheduling disabled).
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SchedulerExecutionTimer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-schedulerexecutiontimer">
+ <literal>SchedulerExecutionTimer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:schedulerexecutiontimer-ndbd"/>
+
+ <para>
+ This parameter specifies the time in microseconds for
+ threads to be executed in the scheduler before being sent.
+ Setting it to 0 minimizes the response time; to achieve
+ higher throughput, you can increase the value at the expense
+ of longer response times.
+ </para>
+
+ <para>
+ The default is 50 μsec, which our testing shows to
+ increase throughput slightly in high-load cases without
+ materially delaying requests.
+ </para>
+
+ <para>
+ This parameter was added in MySQL Cluster NDB 6.3.4.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SchedulerSpinTimer</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-schedulerspintimer">
+ <literal>SchedulerSpinTimer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:schedulerspintimer-ndbd"/>
+
+ <para>
+ This parameter specifies the time in microseconds for
+ threads to be executed in the scheduler before sleeping.
+ </para>
+
+ <para>
+ The default value is 0.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <formalpara id="mysql-cluster-ndbd-definition-disk-data-parameters">
+
+ <title>Disk Data Configuration Parameters</title>
+
+ <para>
+ Configuration parameters affecting Disk Data behavior include
+ the following:
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>DiskPageBufferMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-diskpagebuffermemory">
+ <literal>DiskPageBufferMemory</literal>
+ </para>
+
+ <para>
+ This determines the amount of space used for caching
+ pages on disk, and is set in the
+ <literal>[ndbd]</literal> or <literal>[ndbd
+ default]</literal> section of the
+ <filename>config.ini</filename> file. It is measured in
+ bytes. Each page takes up 32 KB. This means that Cluster
+ Disk Data storage always uses
+ <replaceable>N</replaceable> * 32 KB memory where
+ <replaceable>N</replaceable> is some nonnegative
+ integer.
+ </para>
+
+ <para>
+ The default value for this parameter is
+ <literal>64M</literal> (2000 pages of 32 KB each).
+ </para>
+
+ <para>
+ This parameter was added in MySQL 5.1.6.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SharedGlobalMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-sharedglobalmemory">
+ <literal>SharedGlobalMemory</literal>
+ </para>
+
+ <para>
+ This determines the amount of memory that is used for
+ log buffers, disk operations (such as page requests and
+ wait queues), and metadata for tablespaces, log file
+ groups, <literal>UNDO</literal> files, and data files.
+ It can be set in the <literal>[ndbd]</literal> or
+ <literal>[ndbd default]</literal> section of the
+ <filename>config.ini</filename> configuration file, and
+ is measured in bytes.
+ </para>
+
+ <para>
+ The default value is <literal>20M</literal>.
+ </para>
+
+ <para>
+ This parameter was added in MySQL 5.1.6.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>DiskIOThreadPool</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>ThreadPool (OBSOLETE)</primary>
+ <see>DiskIOThreadPool</see>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-diskiothreadpool">
+ <literal>DiskIOThreadPool</literal>
+ </para>
+
+ <para>
+ This parameter determines the number of unbound threads
+ used for Disk Data file access. Before
+ <literal>DiskIOThreadPool</literal> was introduced,
+ exactly one thread was spawned for each Disk Data file,
+ which could lead to performance issues, particularly
+ when using very large data files. With
+ <literal>DiskIOThreadPool</literal>, you can — for
+ example — access a single large data file using
+ several threads working in parallel.
+ </para>
+
+ <para>
+ Currently, this parameter applies to Disk Data I/O
+ threads only, but we plan in the future to make the
+ number of such threads configurable for in-memory data
+ as well.
+ </para>
+
+ <para>
+ The optimum value for this parameter depends on your
+ hardware and configuration, and includes these factors:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>Physical distribution of Disk Data files</title>
+
+ <para>
+ You can obtain better performance by placing data
+ files, undo log files, and the data node
+ filesystem on separate physical disks. If you do
+ this with some or all of these sets of files, then
+ you can set <literal>DiskIOThreadPool</literal>
+ higher to allow separate threads to handle the
+ files on each disk.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Disk performance and types</title>
+
+ <para>
+ The number of threads that can be accommodated for
+ Disk Data file handling is also dependent on the
+ speed and throughput of the disks. Faster disks
+ and higher throughput allow for more disk I/O
+ threads. Our test results indicate that
+ solid-state disk drives can handle many more disk
+ I/O threads than conventional disks, and thus
+ higher values for
+ <literal>DiskIOThreadPool</literal>.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ This parameter was added in MySQL Cluster NDB 6.4.0.
+ Previous to MySQL Cluster NDB 6.4.3, it was named
+ <literal>ThreadPool</literal>. Previous to MySQL Cluster
+ NDB 7.0.7, the default value was 8. Beginning with MySQL
+ Cluster NDB 7.0.7 and MySQL Cluster NDB 7.1.0, the
+ default is 2.
+ </para>
+ </listitem>
+
+ <listitem>
+ <formalpara id="mysql-cluster-ndbd-disk-data-filesystem-parameters">
+
+ <title>Disk Data filesystem parameters</title>
+
+ <para>
+ The parameters in the following list were added in
+ MySQL Cluster NDB 6.2.17, 6.3.22, and 6.4.3 to make it
+ easier to place MySQL Cluster Disk Data files in
+ specific directories.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>FileSystemPathDD</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-filesystempathdd">
+ <literal>FileSystemPathDD</literal>
+ </para>
+
+ <para>
+ If this parameter is specified, then MySQL Cluster
+ Disk Data data files and undo log files are placed
+ in the indicated directory. This can be overridden
+ for data files, undo log files, or both, by
+ specifying values for
+ <literal>FileSystemPathDataFiles</literal>,
+ <literal>FileSystemPathUndoFiles</literal>, or both,
+ as explained for these parameters. It can also be
+ overridden for data files by specifying a path in
+ the <literal>ADD DATAFILE</literal> clause of a
+ <literal role="stmt">CREATE TABLESPACE</literal> or
+ <literal role="stmt">ALTER TABLESPACE</literal>
+ statement, and for undo log files by specifying a
+ path in the <literal>ADD UNDOFILE</literal> clause
+ of a <literal role="stmt">CREATE LOGFILE
+ GROUP</literal> or <literal role="stmt">ALTER
+ LOGFILE GROUP</literal> statement. If
+ <literal>FileSystemPathDD</literal> is not
+ specified, then <literal>FileSystemPath</literal> is
+ used.
+ </para>
+
+ <para>
+ If a <literal>FileSystemPathDD</literal> directory
+ is specified for a given data node (including the
+ case where the parameter is specified in the
+ <literal>[ndbd default]</literal> section of the
+ <filename>config.ini</filename> file), then starting
+ that data node with <option>--initial</option>
+ causes all files in the directory to be deleted.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>FileSystemPathDataFiles</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-filesystempathdatafiles">
+ <literal>FileSystemPathDataFiles</literal>
+ </para>
+
+ <para>
+ If this parameter is specified, then MySQL Cluster
+ Disk Data data files are placed in the indicated
+ directory. This overrides any value set for
+ <literal>FileSystemPathDD</literal>. This parameter
+ can be overridden for a given data file by
+ specifying a path in the <literal>ADD
+ DATAFILE</literal> clause of a
+ <literal role="stmt">CREATE TABLESPACE</literal> or
+ <literal role="stmt">ALTER TABLESPACE</literal>
+ statement used to create that data file. If
+ <literal>FileSystemPathDataFiles</literal> is not
+ specified, then <literal>FileSystemPathDD</literal>
+ is used (or <literal>FileSystemPath</literal>, if
+ <literal>FileSystemPathDD</literal> has also not
+ been set).
+ </para>
+
+ <para>
+ If a <literal>FileSystemPathDataFiles</literal>
+ directory is specified for a given data node
+ (including the case where the parameter is specified
+ in the <literal>[ndbd default]</literal> section of
+ the <filename>config.ini</filename> file), then
+ starting that data node with
+ <option>--initial</option> causes all files in the
+ directory to be deleted.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>FileSystemPathUndoFiles</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-filesystempathundofiles">
+ <literal>FileSystemPathUndoFiles</literal>
+ </para>
+
+ <para>
+ If this parameter is specified, then MySQL Cluster
+ Disk Data undo log files are placed in the indicated
+ directory. This overrides any value set for
+ <literal>FileSystemPathDD</literal>. This parameter
+ can be overridden for a given data file by
+ specifying a path in the <literal>ADD UNDO</literal>
+ clause of a <literal role="stmt">CREATE LOGFILE
+ GROUP</literal> or <literal role="stmt">CREATE
+ LOGFILE GROUP</literal> statement used to create
+ that data file. If
+ <literal>FileSystemPathUndoFiles</literal> is not
+ specified, then <literal>FileSystemPathDD</literal>
+ is used (or <literal>FileSystemPath</literal>, if
+ <literal>FileSystemPathDD</literal> has also not
+ been set).
+ </para>
+
+ <para>
+ If a <literal>FileSystemPathUndoFiles</literal>
+ directory is specified for a given data node
+ (including the case where the parameter is specified
+ in the <literal>[ndbd default]</literal> section of
+ the <filename>config.ini</filename> file), then
+ starting that data node with
+ <option>--initial</option> causes all files in the
+ directory to be deleted.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ For more information, see
+ <xref linkend="mysql-cluster-disk-data-objects"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <formalpara id="mysql-cluster-ndbd-disk-data-object-creation-parameters">
+
+ <title>Disk Data object creation parameters</title>
+
+ <para>
+ The next two parameters enable you — when
+ starting the cluster for the first time — to
+ cause a Disk Data log file group, tablespace, or both,
+ to be created without the use of SQL statements.
+ </para>
+
+ </formalpara>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>InitialLogFileGroup</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-initiallogfilegroup">
+ <literal>InitialLogFileGroup</literal>
+ </para>
+
+ <para>
+ This parameter can be used to specify a log file
+ group that is created when performing an initial
+ start of the cluster.
+ <literal>InitialLogFileGroup</literal> is specified
+ as shown here:
+ </para>
+
+<programlisting>
+InitialLogFileGroup = [name=<replaceable>name</replaceable>;] [undobuffer_size=<replaceable>size</replaceable>;] <replaceable>file-specification-list</replaceable>
+
+<replaceable>file-specification-list</replaceable>:
+ <replaceable>file-specification</replaceable>[; <replaceable>file-specification</replaceable>[; ...]]
+
+<replaceable>file-specification</replaceable>:
+ <replaceable>filename</replaceable>:<replaceable>size</replaceable>
+</programlisting>
+
+ <para>
+ The <literal>name</literal> of the log file group is
+ optional and defaults to
+ <literal>DEFAULT_LG</literal>. The
+ <literal>undobuffer_size</literal> is also optional;
+ if omitted, it defaults to <literal>256M</literal>
+ (256 megabytes). Each
+ <replaceable>file-specification</replaceable>
+ corresponds to an undo log file, and at least one
+ must be specified in the
+ <replaceable>file-specification-list</replaceable>.
+ Undo log files are placed according to any values
+ that have been set for
+ <literal>FileSystemPath</literal>,
+ <literal>FileSystemPathDD</literal>, and
+ <literal>FileSystemPathUndoFiles</literal>, just as
+ if they had been created as the result of a
+ <literal role="stmt">CREATE LOGFILE GROUP</literal>
+ or <literal role="stmt">ALTER LOGFILE
+ GROUP</literal> statement.
+ </para>
+
+ <para>
+ Consider the following example:
+ </para>
+
+<programlisting>
+InitialLogFileGroup = name=LG1; undobuffer_size=128M; undo1.log:250M; undo2.log:150M
+</programlisting>
+
+ <para>
+ This is equivalent to the following SQL statements:
+ </para>
+
+<programlisting>
+CREATE LOGFILE GROUP LG1
+ ADD UNDOFILE 'undo1.log'
+ INITIAL_SIZE 250M
+ UNDO_BUFFER_SIZE 128M
+ ENGINE NDBCLUSTER;
+
+ALTER LOGFILE GROUP LG1
+ ADD UNDOFILE 'undo2.log'
+ INITIAL_SIZE 150M
+ ENGINE NDBCLUSTER;
+</programlisting>
+
+ <para>
+ This logfile group is created when the data nodes
+ are started with <option>--initial</option>.
+ </para>
+
+ <para>
+ This parameter, if used, should always be set in the
+ <literal>[ndbd default]</literal> section of the
+ <filename>config.ini</filename> file. The behavior
+ of a MySQL Cluster when different values are set on
+ different data nodes is not defined.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>InitialTablespace</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-initialtablespace">
+ <literal>InitialTablespace</literal>
+ </para>
+
+ <para>
+ This parameter can be used to specify a MySQL
+ Cluster Disk Data tablespace that is created when
+ performing an initial start of the cluster.
+ <literal>InitialTablespace</literal> is specified as
+ shown here:
+ </para>
+
+<programlisting>
+InitialTablespace = [name=<replaceable>name</replaceable>;] [extent_size=<replaceable>size</replaceable>;] [logfile_group=<replaceable>lg-name</replaceable>;] <replaceable>file-specification-list</replaceable>
+</programlisting>
+
+ <para>
+ The <literal>name</literal> of the tablespace is
+ optional and defaults to
+ <literal>DEFAULT_TS</literal>. The
+ <literal>extent_size</literal> is also optional; it
+ defaults to <literal>1M</literal> (1 megabyte). The
+ <literal>logfile_group</literal> is also optional,
+ and defaults to <literal>DEFAULT_LG</literal>. The
+ <replaceable>file-specification-list</replaceable>
+ uses the same syntax as shown with the
+ <literal>InitialLogfileGroup</literal> parameter,
+ the only difference being that each
+ <replaceable>file-specification</replaceable> used
+ with <literal>InitialTablespace</literal>
+ corresponds to a data file. At least one must be
+ specified in the
+ <replaceable>file-specification-list</replaceable>.
+ Data files are placed according to any values that
+ have been set for <literal>FileSystemPath</literal>,
+ <literal>FileSystemPathDD</literal>, and
+ <literal>FileSystemPathDataFiles</literal>, just as
+ if they had been created as the result of a
+ <literal role="stmt">CREATE TABLESPACE</literal> or
+ <literal role="stmt">ALTER TABLESPACE</literal>
+ statement.
+ </para>
+
+ <para>
+ For example, consider the following line specifying
+ <literal>InitialTablespace</literal> in the
+ <literal>[ndbd default]</literal> section of the
+ <filename>config.ini</filename> file (as with
+ <literal>InitialLogfileGroup</literal>, this
+ parameter should always be set in the <literal>[ndbd
+ default]</literal> section, as the behavior of a
+ MySQL Cluster when different values are set on
+ different data nodes is not defined):
+ </para>
+
+<programlisting>
+InitialTablespace = name=TS1; extent_size=8M; logfile_group=LG1; data1.dat:2G; data2.dat:4G
+</programlisting>
+
+ <para>
+ This is equivalent to the following SQL statements:
+ </para>
+
+<programlisting>
+CREATE TABLESPACE TS1
+ ADD DATAFILE 'data1.dat'
+ USE LOGFILE GROUP LG1
+ EXTENT_SIZE 8M
+ INITIAL_SIZE 2G
+ ENGINE NDBCLUSTER;
+
+ALTER TABLESPACE TS1
+ ADD UNDOFILE 'data2.dat'
+ INITIAL_SIZE 4G
+ ENGINE NDBCLUSTER;
+</programlisting>
+
+ <para>
+ This tablespace is created when the data nodes are
+ started with <option>--initial</option>, and can be
+ used whenever creating MySQL Cluster Disk Data
+ tables thereafter.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+
+ <formalpara id="mysql-cluster-ndbd-definition-gcp-stop-errors">
+
+ <title>Disk Data and <errortext>GCP Stop</errortext> errors</title>
+
+ <para>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>GCP Stop errors</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>GCP Stop errors (MySQL Cluster)</primary>
+ </indexterm>
+
+ Errors encountered when using Disk Data tables such as
+ <errortext>Node <replaceable>nodeid</replaceable> killed this
+ node because GCP stop was detected</errortext> (error 2303)
+ are often referred to as <quote>CGP stop errors</quote>. Such
+ errors are usually due to slow disks and insufficient disk
+ throughput. You can help prevent these errors from occurring
+ by using faster disks, and by adjusting the cluster
+ configuration as discussed here:
+
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>MySQL Cluster NDB 6.2 and 6.3</title>
+
+ <para>
+ <indexterm>
+ <primary>DiskPageBufferMemory</primary>
+ </indexterm>
+
+ When working with large amounts of data on disk under
+ high load, the default value for
+ <literal>DiskPageBufferMemory</literal> may not be
+ large enough. In such cases, you should increase its
+ value to include most of the memory available to the
+ data nodes after accounting for index memory, data
+ memory, internal buffers, and memory needed by the
+ data node host operating system. You can use this
+ formula as a guide:
+
+<programlisting>
+DiskPageBufferMemory
+ = 0.8
+ x (
+ [total memory]
+ - ([operating system memory] + [buffer memory] + DataMemory + IndexMemory)
+ )
+</programlisting>
+
+ Once you have established that sufficient memory is
+ reserved for <literal>DataMemory</literal>,
+ <literal>IndexMemory</literal>, NDB internal buffers,
+ and operating system overhead, it is possible (and
+ sometimes desirable) to allocate more than the above
+ amount of the remainder to
+ <literal>DiskPageBufferMemory</literal>.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>MySQL Cluster NDB 6.4 and 7.X</title>
+
+ <para>
+ <indexterm>
+ <primary>DiskIOThreadPool</primary>
+ </indexterm>
+
+ In addition to the considerations given for
+ <literal>DiskPageBufferMemory</literal> as explained
+ in the previous item, it is also very important that
+ the <literal>DiskIOThreadPool</literal> configuration
+ parameter be set correctly; having
+ <literal>DiskIOThreadPool</literal> set too high is
+ very likely to cause GCP stop errors (Bug#37227).
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Parameters for configuring send buffer memory allocation (MySQL Cluster
+ NDB 7.0)</title>
+
+ <para>
+ Beginning with MySQL Cluster NDB 6.4.0, send buffer memory is
+ allocated dynamically from a memory pool shared between all
+ transporters, which means that the size of the send buffer can
+ be adjusted as necessary. (Previously, the NDB kernel used a
+ fixed-size send buffer for every node in the cluster, which
+ was allocated when the node started and could not be changed
+ while the node was running.) The following data node
+ configuration parameters were added in MySQL Cluster NDB 6.4.0
+ to permit the setting of limits on this memory allocation;
+ this change is reflected by the addition of the configuration
+ parameters <literal>TotalSendBufferMemory</literal>,
+ <literal>ReservedSendBufferMemory</literal>, and
+ <literal>OverLoadLimit</literal>, as well as a change in how
+ the existing <literal>SendBufferMemory</literal> configuration
+ parameter is used. For more information, see
+ <xref linkend="mysql-cluster-config-send-buffers"/>.
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>TotalSendBufferMemory</primary>
+ <secondary>data nodes</secondary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-totalsendbuffermemory">
+ <literal>TotalSendBufferMemory</literal>
+ </para>
+
+ <para>
+ This parameter is available beginning with MySQL Cluster
+ NDB 6.4.0. It is used to determine the total amount of
+ memory to allocate on this node for shared send buffer
+ memory among all configured transporters.
+ </para>
+
+ <para>
+ If this parameter is set, its minimum allowed value is
+ 256K; the maxmimum is 4294967039.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ReservedSendBufferMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-ndbd-reservedsendbuffermemory">
+ <literal>ReservedSendBufferMemory</literal>
+ </para>
+
+ <para>
+ This optional parameter is available beginning with
+ MySQL Cluster NDB 6.4.0. If set, it reserves an amount
+ of memory (in bytes) for connections between data nodes,
+ and that cannot be allocated for send buffers to be used
+ for management or API nodes. This helps prevent API
+ nodes from using excess send buffer memory and thereby
+ causing communications failures in the NDB kernel.
+ </para>
+
+ <para>
+ If this parameter is set, its minimum allowed value is
+ 256K; the maxmimum is 4294967039.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ For more detailed information about the behavior and use of
+ <literal>TotalSendBufferMemory</literal> and
+ <literal>ReservedSendBufferMemory</literal>, and about
+ configuring send buffer memory parameters in MySQL Cluster NDB
+ 6.4.0 and later, see
+ <xref linkend="mysql-cluster-config-send-buffers"/>.
+ </para>
+
+ </formalpara>
+
+ <note>
+ <para>
+ Previous to MySQL Cluster NDB 7.0, to add new data nodes to a
+ MySQL Cluster, it is necessary to shut down the cluster
+ completely, update the <filename>config.ini</filename> file,
+ and then restart the cluster (that is, you must perform a
+ system restart). All data node processes must be started with
+ the <option>--initial</option> option.
+ </para>
+
+ <para>
+ Beginning with MySQL Cluster NDB 7.0, it is possible to add
+ new data node groups to a running cluster online. See
+ <xref linkend="mysql-cluster-online-add-node"/>, for more
+ information.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-api-definition">
+
+ <title>Defining SQL and Other API Nodes in a MySQL Cluster</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>SQL node</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>API node</secondary>
+ </indexterm>
+
+ <para>
+ The <literal>[mysqld]</literal> and <literal>[api]</literal>
+ sections in the <filename>config.ini</filename> file define the
+ behavior of the MySQL servers (SQL nodes) and other applications
+ (API nodes) used to access cluster data. None of the parameters
+ shown is required. If no computer or host name is provided, any
+ host can use this SQL or API node.
+ </para>
+
+ <para>
+ Generally speaking, a <literal>[mysqld]</literal> section is
+ used to indicate a MySQL server providing an SQL interface to
+ the cluster, and an <literal>[api]</literal> section is used for
+ applications other than <command>mysqld</command> processes
+ accessing cluster data, but the two designations are actually
+ synonomous; you can, for instance, list parameters for a MySQL
+ server acting as an SQL node in an <literal>[api]</literal>
+ section.
+ </para>
+
+ <note>
+ <para>
+ For a discussion of MySQL server options for MySQL Cluster,
+ see <xref linkend="mysql-cluster-program-options-mysqld"/>;
+ for information about MySQL server system variables relating
+ to MySQL Cluster, see
+ <xref linkend="mysql-cluster-system-variables"/>.
+ </para>
+ </note>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>Id</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-id">
+ <literal>Id</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:id-api"/>
+
+ <para>
+ The <literal>Id</literal> is an integer value used to
+ identify the node in all cluster internal messages. Prior to
+ MySQL Cluster NDB 6.1.1, the permitted range of values for
+ this parameter was 1 to 63 inclusive. Beginning with MySQL
+ Cluster NDB 6.1.1, the permitted range is 1 to 255
+ inclusive. This value must be unique for each node in the
+ cluster, regardless of the type of node.
+ </para>
+
+ <note>
+ <para>
+ Data node IDs must be less than 49, regardless of the
+ MySQL Cluster version used. If you plan to deploy a large
+ number of data nodes, it is a good idea to limit the node
+ IDs for API nodes (and management nodes) to values greater
+ than 48.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ExecuteOnComputer</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-executeoncomputer">
+ <literal>ExecuteOnComputer</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:executeoncomputer-api"/>
+
+ <para>
+ This refers to the <literal>Id</literal> set for one of the
+ computers (hosts) defined in a <literal>[computer]</literal>
+ section of the configuration file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>HostName</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-hostname">
+ <literal>HostName</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:hostname-api"/>
+
+ <para>
+ Specifying this parameter defines the hostname of the
+ computer on which the SQL node (API node) is to reside. To
+ specify a hostname, either this parameter or
+ <literal>ExecuteOnComputer</literal> is required.
+ </para>
+
+ <para>
+ If no <literal>HostName</literal> or
+ <literal>ExecuteOnComputer</literal> is specified in a given
+ <literal>[mysql]</literal> or <literal>[api]</literal>
+ section of the <filename>config.ini</filename> file, then an
+ SQL or API node may connect using the corresponding
+ <quote>slot</quote> from any host which can establish a
+ network connection to the management server host machine.
+ <emphasis>This differs from the default behavior for data
+ nodes, where <literal>localhost</literal> is assumed for
+ <literal>HostName</literal> unless otherwise
+ specified</emphasis>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationRank</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-arbitrationrank">
+ <literal>ArbitrationRank</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:arbitrationrank-api"/>
+
+ <para>
+ This parameter defines which nodes can act as arbitrators.
+ Both MGM nodes and SQL nodes can be arbitrators. A value of
+ 0 means that the given node is never used as an arbitrator,
+ a value of 1 gives the node high priority as an arbitrator,
+ and a value of 2 gives it low priority. A normal
+ configuration uses the management server as arbitrator,
+ setting its <literal>ArbitrationRank</literal> to 1 (the
+ default) and those for all SQL nodes to 0.
+ </para>
+
+ <para>
+ Beginning with MySQL 5.1.16 and MySQL Cluster NDB 6.1.3, it
+ is possible to disable arbitration completely by setting
+ <literal>ArbitrationRank</literal> to 0 on all management
+ and SQL nodes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ArbitrationDelay</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-arbitrationdelay">
+ <literal>ArbitrationDelay</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:arbitrationdelay-api"/>
+
+ <para>
+ Setting this parameter to any other value than 0 (the
+ default) means that responses by the arbitrator to
+ arbitration requests will be delayed by the stated number of
+ milliseconds. It is usually not necessary to change this
+ value.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BatchByteSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-batchbytesize">
+ <literal>BatchByteSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:batchbytesize-api"/>
+
+ <remark role="todo">
+ Add pointers to discussions of table scans and range scans
+ in Optimization chapter. [js]
+ </remark>
+
+ <para>
+ For queries that are translated into full table scans or
+ range scans on indexes, it is important for best performance
+ to fetch records in properly sized batches. It is possible
+ to set the proper size both in terms of number of records
+ (<literal>BatchSize</literal>) and in terms of bytes
+ (<literal>BatchByteSize</literal>). The actual batch size is
+ limited by both parameters.
+ </para>
+
+ <para>
+ The speed at which queries are performed can vary by more
+ than 40% depending upon how this parameter is set. In future
+ releases, MySQL Server will make educated guesses on how to
+ set parameters relating to batch size, based on the query
+ type.
+ </para>
+
+ <para>
+ This parameter is measured in bytes and by default is equal
+ to 32KB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>BatchSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-batchsize">
+ <literal>BatchSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:batchsize-api"/>
+
+ <para>
+ This parameter is measured in number of records and is by
+ default set to 64. The maximum size is 992.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>MaxScanBatchSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-api-maxscanbatchsize">
+ <literal>MaxScanBatchSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:maxscanbatchsize-api"/>
+
+ <para>
+ The batch size is the size of each batch sent from each data
+ node. Most scans are performed in parallel to protect the
+ MySQL Server from receiving too much data from many nodes in
+ parallel; this parameter sets a limit to the total batch
+ size over all nodes.
+ </para>
+
+ <para>
+ The default value of this parameter is set to 256KB. Its
+ maximum size is 16MB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>TotalSendBufferMemory</primary>
+ <secondary>API and SQL nodes</secondary>
+ </indexterm>
+
+ <para id="ndbparam-api-totalsendbuffermemory">
+ <literal>TotalSendBufferMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:totalsendbuffermemory-api"/>
+
+ <para>
+ This parameter is available beginning with MySQL Cluster NDB
+ 6.4.0. It is used to determine the total amount of memory to
+ allocate on this node for shared send buffer memory among
+ all configured transporters.
+ </para>
+
+ <para>
+ If this parameter is set, its minimum allowed value is 256K;
+ the maxmimum is 4294967039. For more detailed information
+ about the behavior and use of
+ <literal>TotalSendBufferMemory</literal> and configuring
+ send buffer memory parameters in MySQL Cluster NDB 6.4.0 and
+ later, see
+ <xref linkend="mysql-cluster-config-send-buffers"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>AutoReconnect</primary>
+ <secondary>API and SQL nodes</secondary>
+ </indexterm>
+
+ <para id="ndbparam-api-autoreconnect">
+ <literal>AutoReconnect</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:autoreconnect-api"/>
+
+ <para>
+ This parameter is available beginning with MySQL Cluster NDB
+ 6.3.26 and MySQL Cluster NDB 7.0.7. By default, its value is
+ <literal>false</literal>, which forces disconnected API
+ nodes (including MySQL Servers acting as SQL nodes) the use
+ a new connection to the cluster rather than attempting to
+ re-use an existing one, which can cause problems when using
+ dynamically-allocated node IDs. (Bug#45921)
+ </para>
+
+ <note>
+ <para>
+ This parameter can be overridden using the NDB API. For
+ more information, see
+ <xref linkend="class-ndb-cluster-connection-set-auto-reconnect"/>,
+ and
+ <xref linkend="class-ndb-cluster-connection-get-auto-reconnect"/>.
+ </para>
+ </note>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ You can obtain some information from a MySQL server running as a
+ Cluster SQL node using <literal role="stmt">SHOW
+ STATUS</literal> in the <literal>mysql</literal> client, as
+ shown here:
+ </para>
+
+<programlisting>
+mysql> <userinput>SHOW STATUS LIKE 'ndb%';</userinput>
++-----------------------------+---------------+
+| Variable_name | Value |
++-----------------------------+---------------+
+| Ndb_cluster_node_id | 5 |
+| Ndb_config_from_host | 192.168.0.112 |
+| Ndb_config_from_port | 1186 |
+| Ndb_number_of_storage_nodes | 4 |
++-----------------------------+---------------+
+4 rows in set (0.02 sec)
+</programlisting>
+
+ <para>
+ For information about these Cluster system status variables, see
+ <xref linkend="server-status-variables"/>.
+ </para>
+
+ <note>
+ <para>
+ To add new SQL or API nodes to the configuration of a running
+ MySQL Cluster, it is necessary to perform a rolling restart of
+ all cluster nodes after adding new <literal>[mysqld]</literal>
+ or <literal>[api]</literal> sections to the
+ <filename>config.ini</filename> file (or files, if you are
+ using more than one management server). This must be done
+ before the new SQL or API nodes can connect to the cluster.
+ </para>
+
+ <para>
+ It is <emphasis>not</emphasis> necessary to perform any
+ restart of the cluster if new SQL or API nodes can employ
+ previously unused API slots in the cluster configuration to
+ connect to the cluster.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-tcp-definition">
+
+ <title>MySQL Cluster TCP/IP Connections</title>
+
+ <para>
+ TCP/IP is the default transport mechanism for all connections
+ between nodes in a MySQL Cluster. Normally it is not necessary
+ to define TCP/IP connections; MySQL Cluster automatically sets
+ up such connections for all data nodes, management nodes, and
+ SQL or API nodes.
+ </para>
+
+ <note>
+ <para>
+ For an exception to this rule, see
+ <xref linkend="mysql-cluster-tcp-definition-direct"/>.
+ </para>
+ </note>
+
+ <para>
+ To override the default connection parameters, it is necessary
+ to define a connection using one or more
+ <literal>[tcp]</literal> sections in the
+ <filename>config.ini</filename> file. Each
+ <literal>[tcp]</literal> section explicitly defines a TCP/IP
+ connection between two MySQL Cluster nodes, and must contain at
+ a minimum the parameters <literal>NodeId1</literal> and
+ <literal>NodeId2</literal>, as well as any connection parameters
+ to override.
+ </para>
+
+ <para>
+ It is also possible to change the default values for these
+ parameters by setting them in the <literal>[tcp
+ default]</literal> section.
+ </para>
+
+ <important>
+ <para>
+ Any <literal>[tcp]</literal> sections in the
+ <filename>config.ini</filename> file should be listed
+ <emphasis>last</emphasis>, following all other sections in the
+ file. However, this is not required for a <literal>[tcp
+ default]</literal> section. This requirement is a known issue
+ with the way in which the <filename>config.ini</filename> file
+ is read by the MySQL Cluster management server.
+ </para>
+ </important>
+
+ <para>
+ Connection parameters which can be set in
+ <literal>[tcp]</literal> and <literal>[tcp default]</literal>
+ sections of the <filename>config.ini</filename> file are listed
+ here:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para id="ndbparam-tcp-nodeid">
+ <literal>NodeId1</literal>, <literal>NodeId2</literal>
+ </para>
+
+ <para>
+ To identify a connection between two nodes it is necessary
+ to provide their node IDs in the <literal>[tcp]</literal>
+ section of the configuration file. These are the same unique
+ <literal>Id</literal> values for each of these nodes as
+ described in <xref linkend="mysql-cluster-api-definition"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>OverloadLimit</primary>
+ </indexterm>
+
+ <para id="mysql-cluster-param-tcp-overloadlimit">
+ <literal>OverloadLimit</literal>
+ </para>
+
+ <para>
+ Beginning in MySQL Cluster NDB 6.4.0, this parameter can be
+ used to determine the amount of unsent data that must be
+ present in the send buffer before the connection is
+ considered overloaded. See
+ <xref linkend="mysql-cluster-config-send-buffers"/>, for
+ more information.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendBufferMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-sendbuffermemory">
+ <literal>SendBufferMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:sendbuffermemory-tcp"/>
+
+ <para>
+ TCP transporters use a buffer to store all messages before
+ performing the send call to the operating system. When this
+ buffer reaches 64KB its contents are sent; these are also
+ sent when a round of messages have been executed. To handle
+ temporary overload situations it is also possible to define
+ a bigger send buffer.
+ </para>
+
+ <para>
+ Prior to MySQL Cluster NDB 7.0, this parameter determined a
+ fixed amount of memory allocated at startup for each
+ configured TCP connection. Beginning with MySQL Cluster NDB
+ 6.4.0, memory is not dedicated to each transporter. Instead,
+ the value denotes the hard limit for how much memory (out of
+ the total available memory — that is,
+ <literal>TotalSendBufferMemory</literal>) that may be used
+ by a single transporter. For more information about
+ configuring dynamic transporter send buffer memory
+ allocation in MySQL Cluster NDB 7.0 and later, see
+ <xref linkend="mysql-cluster-config-send-buffers"/>.
+ </para>
+
+ <para>
+ In MySQL Cluster NDB 6.4.3 and earlier, the default size of
+ the send buffer was 256 KB; in MySQL Cluster NDB 7.0.4 and
+ later, it is 2MB, which is the size recommended in most
+ situations. The minimum size is 64 KB; the theoretical
+ maximum is 4 GB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendSignalId</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-sendsignalid">
+ <literal>SendSignalId</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:sendsignalid-tcp"/>
+
+ <para>
+ To be able to retrace a distributed message datagram, it is
+ necessary to identify each message. When this parameter is
+ set to <literal>Y</literal>, message IDs are transported
+ over the network. This feature is disabled by default in
+ production builds, and enabled in <literal>-debug</literal>
+ builds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Checksum</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-checksum">
+ <literal>Checksum</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:checksum-tcp"/>
+
+ <para>
+ This parameter is a boolean parameter (enabled by setting it
+ to <literal>Y</literal> or <literal>1</literal>, disabled by
+ setting it to <literal>N</literal> or <literal>0</literal>).
+ It is disabled by default. When it is enabled, checksums for
+ all messages are calculated before they placed in the send
+ buffer. This feature ensures that messages are not corrupted
+ while waiting in the send buffer, or by the transport
+ mechanism.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>PortNumber</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-portnumber">
+ <literal>PortNumber</literal>
+ (<emphasis>OBSOLETE</emphasis>)
+ </para>
+
+ <para>
+ This formerly specified the port number to be used for
+ listening for connections from other nodes. This parameter
+ should no longer be used.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ReceiveBufferMemory</primary>
+ </indexterm>
+
+ <para id="ndbparam-tcp-receivebuffermemory">
+ <literal>ReceiveBufferMemory</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:receivebuffermemory-tcp"/>
+
+ <para>
+ Specifies the size of the buffer used when receiving data
+ from the TCP/IP socket.
+ </para>
+
+ <para>
+ In MySQL Cluster NDB 6.4.3 and earlier, the default value of
+ this parameter was 64 KB; beginning with MySQL Cluster NDB
+ 7.0.4, 2MB is the default. The minimum possible value is
+ 16KB; the theoretical maximum is 4GB.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
+ <section id="mysql-cluster-tcp-definition-direct">
+
+ <title>MySQL Cluster TCP/IP Connections Using Direct Connections</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>networking</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>transporters</secondary>
+ <tertiary>TCP/IP</tertiary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>direct connections between nodes</secondary>
+ </indexterm>
+
+ <para>
+ Setting up a cluster using direct connections between data nodes
+ requires specifying explicitly the crossover IP addresses of the
+ data nodes so connected in the <literal>[tcp]</literal> section
+ of the cluster <filename>config.ini</filename> file.
+ </para>
+
+ <para>
+ In the following example, we envision a cluster with at least
+ four hosts, one each for a management server, an SQL node, and
+ two data nodes. The cluster as a whole resides on the
+ <literal>172.23.72.*</literal> subnet of a LAN. In addition to
+ the usual network connections, the two data nodes are connected
+ directly using a standard crossover cable, and communicate with
+ one another directly using IP addresses in the
+ <literal>1.1.0.*</literal> address range as shown:
+ </para>
+
+<programlisting>
+# Management Server
+[ndb_mgmd]
+Id=1
+HostName=172.23.72.20
+
+# SQL Node
+[mysqld]
+Id=2
+HostName=172.23.72.21
+
+# Data Nodes
+[ndbd]
+Id=3
+HostName=172.23.72.22
+
+[ndbd]
+Id=4
+HostName=172.23.72.23
+
+# TCP/IP Connections
+[tcp]
+NodeId1=3
+NodeId2=4
+HostName1=1.1.0.1
+HostName2=1.1.0.2
+</programlisting>
+
+ <para>
+ The <literal>HostName<replaceable>N</replaceable></literal>
+ parameter, where <replaceable>N</replaceable> is an integer, is
+ used only when specifying direct TCP/IP connections.
+ </para>
+
+ <para>
+ The use of direct connections between data nodes can improve the
+ cluster's overall efficiency by allowing the data nodes to
+ bypass an Ethernet device such as a switch, hub, or router, thus
+ cutting down on the cluster's latency. It is important to note
+ that to take the best advantage of direct connections in this
+ fashion with more than two data nodes, you must have a direct
+ connection between each data node and every other data node in
+ the same node group.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-shm-definition">
+
+ <title>MySQL Cluster Shared-Memory Connections</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>networking</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>shared memory transporter</primary>
+ <see>MySQL Cluster</see>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>shared memory transport</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>transporters</secondary>
+ <tertiary>shared memory (SHM)</tertiary>
+ </indexterm>
+
+ <para>
+ MySQL Cluster attempts to use the shared memory transporter and
+ configure it automatically where possible.
+ <literal>[shm]</literal> sections in the
+ <filename>config.ini</filename> file explicitly define
+ shared-memory connections between nodes in the cluster. When
+ explicitly defining shared memory as the connection method, it
+ is necessary to define at least <literal>NodeId1</literal>,
+ <literal>NodeId2</literal> and <literal>ShmKey</literal>. All
+ other parameters have default values that should work well in
+ most cases.
+ </para>
+
+ <important>
+ <para>
+ <emphasis>SHM functionality is considered experimental
+ only</emphasis>. It is not officially supported in any current
+ MySQL Cluster release, and testing results indicate that SHM
+ performance is not appreciably greater than when using TCP/IP
+ for the transporter.
+ </para>
+
+ <para>
+ For these reasons, you must determine for yourself or by using
+ our free resources (forums, mailing lists) whether SHM can be
+ made to work correctly in your specific case.
+ </para>
+ </important>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>node identifiers (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>node identifiers</secondary>
+ </indexterm>
+
+ <para id="ndbparam-shm-nodeids">
+ <literal>NodeId1</literal>, <literal>NodeId2</literal>
+ </para>
+
+ <para>
+ To identify a connection between two nodes it is necessary
+ to provide node identifiers for each of them, as
+ <literal>NodeId1</literal> and <literal>NodeId2</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ShmKey</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-shmkey">
+ <literal>ShmKey</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:shmkey-shm"/>
+
+ <para>
+ When setting up shared memory segments, a node ID, expressed
+ as an integer, is used to identify uniquely the shared
+ memory segment to use for the communication. There is no
+ default value.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>ShmSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-shmsize">
+ <literal>ShmSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:shmsize-shm"/>
+
+ <para>
+ Each SHM connection has a shared memory segment where
+ messages between nodes are placed by the sender and read by
+ the reader. The size of this segment is defined by
+ <literal>ShmSize</literal>. The default value is 1MB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendSignalId</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-sendsignalid">
+ <literal>SendSignalId</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:sendsignalid-shm"/>
+
+ <para>
+ To retrace the path of a distributed message, it is
+ necessary to provide each message with a unique identifier.
+ Setting this parameter to <literal>Y</literal> causes these
+ message IDs to be transported over the network as well. This
+ feature is disabled by default in production builds, and
+ enabled in <literal>-debug</literal> builds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Checksum (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-checksum">
+ <literal>Checksum</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:checksum-shm"/>
+
+ <para>
+ This parameter is a boolean
+ (<literal>Y</literal>/<literal>N</literal>) parameter which
+ is disabled by default. When it is enabled, checksums for
+ all messages are calculated before being placed in the send
+ buffer.
+ </para>
+
+ <para>
+ This feature prevents messages from being corrupted while
+ waiting in the send buffer. It also serves as a check
+ against data being corrupted during transport.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SigNum</primary>
+ </indexterm>
+
+ <para id="ndbparam-shm-signum">
+ <literal>SigNum</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:signum-shm"/>
+
+ <para>
+ When using the shared memory transporter, a process sends an
+ operating system signal to the other process when there is
+ new data available in the shared memory. Should that signal
+ conflict with with an existing signal, this parameter can be
+ used to change it. This is a possibility when using SHM due
+ to the fact that different operating systems use different
+ signal numbers.
+ </para>
+
+ <para>
+ The default value of <literal>SigNum</literal> is 0;
+ therefore, it must be set to avoid errors in the cluster log
+ when using the shared memory transporter. Typically, this
+ parameter is set to 10 in the <literal>[shm
+ default]</literal> section of the
+ <filename>config.ini</filename> file.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
+ <section id="mysql-cluster-sci-definition">
+
+ <title>SCI Transport Connections in MySQL Cluster</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>networking</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>SCI (Scalable Coherent Interface)</primary>
+ <see>MySQL Cluster</see>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>SCI (Scalable Coherent Interface)</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>transporters</secondary>
+ <tertiary>Scalable Coherent Interface (SCI)</tertiary>
+ </indexterm>
+
+ <para>
+ <literal>[sci]</literal> sections in the
+ <filename>config.ini</filename> file explicitly define SCI
+ (Scalable Coherent Interface) connections between cluster nodes.
+ Using SCI transporters in MySQL Cluster is supported only when
+ the MySQL binaries are built using
+ <option>--with-ndb-sci=<replaceable>/your/path/to/SCI</replaceable></option>.
+ The <replaceable>path</replaceable> should point to a directory
+ that contains at a minimum <filename>lib</filename> and
+ <filename>include</filename> directories containing SISCI
+ libraries and header files. (See
+ <xref linkend="mysql-cluster-interconnects"/> for more
+ information about SCI.)
+ </para>
+
+ <para>
+ In addition, SCI requires specialized hardware.
+ </para>
+
+ <para>
+ It is strongly recommended to use SCI Transporters only for
+ communication between <command>ndbd</command> processes. Note
+ also that using SCI Transporters means that the
+ <command>ndbd</command> processes never sleep. For this reason,
+ SCI Transporters should be used only on machines having at least
+ two CPUs dedicated for use by <command>ndbd</command> processes.
+ There should be at least one CPU per <command>ndbd</command>
+ process, with at least one CPU left in reserve to handle
+ operating system activities.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>node identifiers (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>node identifiers</secondary>
+ </indexterm>
+
+ <para id="ndbparam-sci-nodeids">
+ <literal>NodeId1</literal>, <literal>NodeId2</literal>
+ </para>
+
+ <para>
+ To identify a connection between two nodes it is necessary
+ to provide node identifiers for each of them, as
+ <literal>NodeId1</literal> and <literal>NodeId2</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Host*SciId* parameters</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-host1sciid0">
+ <literal>Host1SciId0</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:host1sciid0-sci"/>
+
+ <para>
+ This identifies the SCI node ID on the first Cluster node
+ (identified by <literal>NodeId1</literal>).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para id="ndbparam-sci-host1sciid1">
+ <literal>Host1SciId1</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:host1sciid1-sci"/>
+
+ <para>
+ It is possible to set up SCI Transporters for failover
+ between two SCI cards which then should use separate
+ networks between the nodes. This identifies the node ID and
+ the second SCI card to be used on the first node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para id="ndbparam-sci-host2sciid0">
+ <literal>Host2SciId0</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:host2sciid0-sci"/>
+
+ <para>
+ This identifies the SCI node ID on the second Cluster node
+ (identified by <literal>NodeId2</literal>).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para id="ndbparam-sci-host2sciid1">
+ <literal>Host2SciId1</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:host2sciid1-sci"/>
+
+ <para>
+ When using two SCI cards to provide failover, this parameter
+ identifies the second SCI card to be used on the second
+ node.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SharedBufferSize</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-sharedbuffersize">
+ <literal>SharedBufferSize</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:sharedbuffersize-sci"/>
+
+ <para>
+ Each SCI transporter has a shared memory segment used for
+ communication between the two nodes. Setting the size of
+ this segment to the default value of 1MB should be
+ sufficient for most applications. Using a smaller value can
+ lead to problems when performing many parallel inserts; if
+ the shared buffer is too small, this can also result in a
+ crash of the <command>ndbd</command> process.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendLimit</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-sendlimit">
+ <literal>SendLimit</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:sendlimit-sci"/>
+
+ <para>
+ A small buffer in front of the SCI media stores messages
+ before transmitting them over the SCI network. By default,
+ this is set to 8KB. Our benchmarks show that performance is
+ best at 64KB but 16KB reaches within a few percent of this,
+ and there was little if any advantage to increasing it
+ beyond 8KB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>SendSignalId</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-sendsignalid">
+ <literal>SendSignalId</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:sendsignalid-sci"/>
+
+ <para>
+ To trace a distributed message it is necessary to identify
+ each message uniquely. When this parameter is set to
+ <literal>Y</literal>, message IDs are transported over the
+ network. This feature is disabled by default in production
+ builds, and enabled in <literal>-debug</literal> builds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <indexterm>
+ <primary>Checksum (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para id="ndbparam-sci-checksum">
+ <literal>Checksum</literal>
+ </para>
+
+ <para condition="dynamic:optvar:item" role="5.1:ndb-config-params:checksum-sci"/>
+
+ <para>
+ This parameter is a boolean value, and is disabled by
+ default. When <literal>Checksum</literal> is enabled,
+ checksums are calculated for all messages before they are
+ placed in the send buffer. This feature prevents messages
+ from being corrupted while waiting in the send buffer. It
+ also serves as a check against data being corrupted during
+ transport.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
+ </section>
+
+ <section id="mysql-cluster-config-params-overview">
+
+ <title>Overview of MySQL Cluster Configuration Parameters</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration parameters</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>configuration</primary>
+ <secondary>MySQL Cluster</secondary>
+ </indexterm>
+
+ <remark role="note">
+ [js] Prepared with the assistance of Johan Andersson, Hartmut
+ Holzgraefe, Sergei Kozlov, Jeb Miller, and Bernd Ocklin.
+ </remark>
+
+ <para>
+ The next three sections provide summary tables of MySQL Cluster
+ configuration parameters used in the
+ <filename>config.ini</filename> file to govern the cluster's
+ functioning. Each table lists the parameters for one of the
+ Cluster node process types (<command>ndbd</command>,
+ <command>ndb_mgmd</command>, and <command>mysqld</command>), and
+ includes the parameter's type as well as its default, mimimum, and
+ maximum values as applicable.
+ </para>
+
+ <para>
+ It is also stated what type of restart is required (node restart
+ or system restart) — and whether the restart must be done
+ with <option>--initial</option> — to change the value of a
+ given configuration parameter. This information is provided in
+ each table's <emphasis role="bold">Restart Type</emphasis> column,
+ which contains one of the values shown in this list:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>N</literal>: Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IN</literal>: Initial Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>S</literal>: System Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IS</literal>: Initial System Restart
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ When performing a node restart or an initial node restart, all of
+ the cluster's data nodes must be restarted in turn (also referred
+ to as a <firstterm>rolling restart</firstterm>). It is possible to
+ update cluster configuration parameters marked
+ <literal>N</literal> or <literal>IN</literal> online — that
+ is, without shutting down the cluster — in this fashion. An
+ initial node restart requires restarting each
+ <command>ndbd</command> process with the
+ <option>--initial</option> option.
+ </para>
+
+ <para>
+ A system restart requires a complete shutdown and restart of the
+ entire cluster. An initial system restart requires taking a backup
+ of the cluster, wiping the cluster file system after shutdown, and
+ then restoring from the backup following the restart.
+ </para>
+
+ <para>
+ In any cluster restart, all of the cluster's management servers
+ must be restarted in order for them to read the updated
+ configuration parameter values.
+ </para>
+
+ <important>
+ <para>
+ Values for numeric cluster parameters can generally be increased
+ without any problems, although it is advisable to do so
+ progressively, making such adjustments in relatively small
+ increments. However, decreasing the values of such parameters
+ — particularly those relating to memory usage and disk
+ space — is not to be undertaken lightly, and it is
+ recommended that you do so only following careful planning and
+ testing. In addition, it is the generally the case that
+ parameters relating to memory and disk usage which can be raised
+ using a simple node restart require an initial node restart to
+ be lowered.
+ </para>
+ </important>
+
+ <para>
+ Because some of these parameters can be used for configuring more
+ than one type of cluster node, they may appear in more than one of
+ the tables.
+ </para>
+
+ <note>
+ <para>
+ <literal>4294967039</literal> — which often appears as a
+ maximum value in these tables — is defined in the
+ <literal role="se">NDBCLUSTER</literal> sources as
+ <literal>MAX_INT_RNIL</literal> and is equal to
+ <literal>0xFFFFFEFF</literal>, or
+ <literal>2<superscript>32</superscript> −
+ 2<superscript>8</superscript> − 1</literal>.
+ </para>
+ </note>
+
+ <section id="mysql-cluster-config-params-ndbd">
+
+ <title>MySQL Cluster Data Node Configuration Parameters</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration parameters</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[ndbd] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[ndbd default] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ The following table provides information about parameters used
+ in the <literal>[ndbd]</literal> or <literal>[ndbd
+ default]</literal> sections of a <filename>config.ini</filename>
+ file for configuring MySQL Cluster data nodes. For detailed
+ descriptions and other additional information about each of
+ these parameters, see
+ <xref linkend="mysql-cluster-ndbd-definition"/>.
+ </para>
+
+ <para>
+ Beginning with MySQL Cluster NDB 6.4.0, these parameters also
+ apply to <command>ndbmtd</command>, which is a multi-threaded
+ version of <command>ndbd</command>. For more information, see
+ <xref linkend="mysql-cluster-programs-ndbmtd"/>.
+ </para>
+
+ <para>
+ <emphasis><emphasis role="bold">Restart Type</emphasis> Column
+ Values</emphasis>
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>N</literal>: Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IN</literal>: Initial Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>S</literal>: System Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IS</literal>: Initial System Restart
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ See <xref linkend="mysql-cluster-config-params-overview"/>, for
+ additional explanations of these abbreviations.
+ </para>
+
+ <table id="mysql-cluster-config-params-ndbd-table">
+ <title>MySQL Cluster Data Node Configuration Parameters</title>
+ <tgroup cols="6">
+ <colspec colwidth="30*"/>
+ <colspec colwidth="5*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="5*"/>
+ <tbody>
+ <row>
+ <entry><emphasis role="bold">Parameter Name</emphasis></entry>
+ <entry><emphasis role="bold">Type/Units</emphasis></entry>
+ <entry><emphasis role="bold">Default Value</emphasis></entry>
+ <entry><emphasis role="bold">Minimum Value</emphasis></entry>
+ <entry><emphasis role="bold">Maximum Value</emphasis></entry>
+ <entry><emphasis role="bold">Restart Type</emphasis></entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-arbitration">Arbitration</link></literal>
+ (<emphasis>added in MySQL Cluster NDB 7.0.7</emphasis>)</entry>
+ <entry>string (one of: <literal>Default</literal>, <literal>Disabled</literal>,
+ <literal>WaitExternal</literal>)</entry>
+ <entry><literal>Default</literal></entry>
+ <entry>—</entry>
+ <entry>—</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-arbitrationtimeout">ArbitrationTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>3000</entry>
+ <entry>10</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupdatabuffersize">BackupDataBufferSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry><emphasis>MySQL Cluster 6.4.3 and earlier</emphasis>: 2M;
+ <emphasis>MySQL Cluster NDB 7.0.4 and later</emphasis>:
+ 16M</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupdatadir">BackupDataDir</link></literal></entry>
+ <entry>string</entry>
+ <entry><filename><literal>FileSystemPath</literal>/BACKUP</filename></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backuplogbuffersize">BackupLogBufferSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry><emphasis>MySQL Cluster 6.4.3 and earlier</emphasis>: 2M;
+ <emphasis>MySQL Cluster NDB 7.0.4 and later</emphasis>:
+ 16M</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupmemory">BackupMemory</link></literal></entry>
+ <entry>bytes</entry>
+ <entry><emphasis>MySQL Cluster 6.4.3 and earlier</emphasis>: 4M;
+ <emphasis>MySQL Cluster NDB 7.0.4 and later</emphasis>:
+ 32M</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupreportfrequency">BackupReportFrequency</link></literal>
+ (Added in MySQL Cluster NDB 6.2.3)</entry>
+ <entry>seconds</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupwritesize">BackupWriteSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry><emphasis>MySQL Cluster 6.4.3 and earlier</emphasis>: 32K;
+ <emphasis>MySQL Cluster NDB 7.0.4 and later</emphasis>:
+ 256K</entry>
+ <entry>2K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-backupmaxwritesize">BackupMaxWriteSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry><emphasis>MySQL Cluster 6.4.3 and earlier</emphasis>: 256K;
+ <emphasis>MySQL Cluster NDB 7.0.4 and later</emphasis>:
+ 1M</entry>
+ <entry>2K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-batchsizeperlocalscan">BatchSizePerLocalScan</link></literal></entry>
+ <entry>integer</entry>
+ <entry>64</entry>
+ <entry>1</entry>
+ <entry>992</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-compressedbackup">CompressedBackup</link></literal>
+ (Added in MySQL Cluster NDB 6.3.7)</entry>
+ <entry>boolean</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-compressedlcp">CompressedLCP</link></literal>
+ (Added in MySQL Cluster NDB 6.3.7)</entry>
+ <entry>boolean</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-datadir">DataDir</link></literal></entry>
+ <entry>string</entry>
+ <entry><filename>.</filename></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-datamemory">DataMemory</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>80M</entry>
+ <entry>1M</entry>
+ <entry>1024G (subject to available system RAM and size of
+ <literal>IndexMemory</literal>)</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-diskcheckpointspeed">DiskCheckpointSpeed</link></literal>
+ (added in MySQL 5.1.12)</entry>
+ <entry>integer (number of bytes per second)</entry>
+ <entry>10M</entry>
+ <entry>1M</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-diskcheckpointspeedinrestart">DiskCheckpointSpeedInRestart</link></literal>
+ (added in MySQL 5.1.12)</entry>
+ <entry>integer (number of bytes per second)</entry>
+ <entry>100M</entry>
+ <entry>1M</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-diskiothreadpool">DiskIOThreadPool</link></literal>
+ (Added in MySQL Cluster NDB 6.4.0; named
+ <literal>ThreadPool</literal> prior to MySQL Cluster NDB
+ 6.4.3)</entry>
+ <entry>integer</entry>
+ <entry>8</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-diskless">Diskless</link></literal></entry>
+ <entry>true|false (<literal>1</literal>|<literal>0</literal>)</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-diskpagebuffermemory">DiskPageBufferMemory</link></literal>
+ (added in MySQL 5.1.6)</entry>
+ <entry>bytes</entry>
+ <entry>64M</entry>
+ <entry>4M</entry>
+ <entry>1024G</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-disksyncsize">DiskSyncSize</link></literal>
+ (added in MySQL 5.1.12)</entry>
+ <entry>integer (number of bytes)</entry>
+ <entry>4M</entry>
+ <entry>32K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-executeoncomputer">ExecuteOnComputer</link></literal></entry>
+ <entry>integer</entry>
+ <entry/>
+ <entry/>
+ <entry/>
+ <entry/>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-filesystempath">FileSystemPath</link></literal>
+ (Added in MySQL Cluster NDB 6.1.11)</entry>
+ <entry>string (directory path)</entry>
+ <entry>value specified for <literal>DataDir</literal></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-filesystempathdd">FileSystemPathDD</link></literal>
+ (Added in MySQL Cluster NDB 6.2.17, 6.3.22, and 6.4.3)</entry>
+ <entry>string (directory path)</entry>
+ <entry>value specified for <literal>FilesystemPath</literal>, if set;
+ otherwise, value of <literal>DataDir</literal></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-filesystempathdatafiles">FileSystemPathDataFiles</link></literal>
+ (Added in MySQL Cluster NDB 6.2.17, 6.3.22, and 6.4.3)</entry>
+ <entry>string (directory path)</entry>
+ <entry>value specified for <literal>FilesystemPathDD</literal>, if set;
+ otherwise, value specified for
+ <literal>FilesystemPath</literal>, if set; otherwise,
+ value of <literal>DataDir</literal></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-filesystempathundofiles">FileSystemPathUndoFiles</link></literal>
+ (Added in MySQL Cluster NDB 6.2.17, 6.3.22, and 6.4.3)</entry>
+ <entry>string (directory path)</entry>
+ <entry>value specified for <literal>FilesystemPathDD</literal>, if set;
+ otherwise, value specified for
+ <literal>FilesystemPath</literal>, if set; otherwise,
+ value of <literal>DataDir</literal></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-fragmentlogfilesize">FragmentLogFileSize</link></literal></entry>
+ <entry>integer (bytes)</entry>
+ <entry>16M</entry>
+ <entry>4M</entry>
+ <entry>1G</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-heartbeatintervaldbapi">HeartbeatIntervalDbApi</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>1500</entry>
+ <entry>100</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-heartbeatintervaldbdb">HeartbeatIntervalDbDb</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>1500</entry>
+ <entry>10</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-hostname">HostName</link></literal></entry>
+ <entry>string</entry>
+ <entry><literal>localhost</literal></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>S</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-id">Id</link></literal></entry>
+ <entry>integer</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>1</entry>
+ <entry>48</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-indexmemory">IndexMemory</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>18M</entry>
+ <entry>1M</entry>
+ <entry>1024G (subject to available system RAM and size of
+ <literal>DataMemory</literal>)</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-initfragmentlogfiles">InitFragmentLogFiles</link></literal>
+ (Added in MySQL Cluster NDB 6.3.19)</entry>
+ <entry>string</entry>
+ <entry>full</entry>
+ <entry>sparse</entry>
+ <entry>sparse</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-initiallogfilegroup">InitialLogFileGroup</link></literal>
+ (Added in MySQL Cluster NDB 6.2.17, 6.3.22, and 6.4.3)</entry>
+ <entry>string (see
+ <link linkend="ndbparam-ndbd-initiallogfilegroup">description</link>
+ for details)</entry>
+ <entry><emphasis>none</emphasis></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>S</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-initialnoofopenfiles">InitialNoOfOpenFiles</link></literal></entry>
+ <entry>integer</entry>
+ <entry>27</entry>
+ <entry>20</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-initialtablespace">InitialTablespace</link></literal>
+ (Added in MySQL Cluster NDB 6.2.17, 6.3.22, and 6.4.3)</entry>
+ <entry>string (see
+ <link linkend="ndbparam-ndbd-initialtablespace">description</link>
+ for details)</entry>
+ <entry><emphasis>none</emphasis></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>S</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-lockexecutethreadtocpu">LockExecuteThreadToCPU</link></literal>
+ (Added in MySQL Cluster NDB 6.3.4; changed in MySQL
+ Cluster NDB 7.0)</entry>
+ <entry><emphasis>MySQL Cluster NDB 6.3 and earlier</emphasis>: integer;
+ <emphasis>MySQL Cluster NDB 7.0 and later</emphasis>:
+ string</entry>
+ <entry><emphasis>MySQL Cluster NDB 6.4.3 and earlier</emphasis>: 65535;
+ <emphasis>MySQL Cluster NDB 7.0 and later</emphasis>:
+ N/A</entry>
+ <entry><emphasis>MySQL Cluster NDB 6.4.3 and earlier</emphasis>: 0;
+ <emphasis>MySQL Cluster NDB 7.0 and later</emphasis>:
+ N/A</entry>
+ <entry><emphasis>MySQL Cluster NDB 6.4.3 and earlier</emphasis>: 65535;
+ <emphasis>MySQL Cluster NDB 7.0 and later</emphasis>:
+ N/A</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-lockmaintthreadstocpu">LockMaintThreadsToCPU</link></literal>
+ (Added in MySQL Cluster NDB 6.3.4)</entry>
+ <entry>integer</entry>
+ <entry><emphasis>MySQL Cluster NDB 6.3</emphasis>: 65535; <emphasis>MySQL
+ Cluster NDB 7.0 and later</emphasis>: N/A</entry>
+ <entry>0</entry>
+ <entry>65535</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-lockpagesinmainmemory">LockPagesInMainMemory</link></literal></entry>
+ <entry><emphasis>As of MySQL 5.1.15 and MySQL Cluster NDB 6.1.1</emphasis>:
+ integer; <emphasis>previously</emphasis>: true|false
+ (<literal>1</literal>|<literal>0</literal>)</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry><emphasis>As of MySQL 5.1.15 and MySQL Cluster NDB 6.1.1</emphasis>: 2;
+ <emphasis>previously</emphasis>: 1</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelcheckpoint">LogLevelCheckpoint</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelcongestion">LogLevelCongestion</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelconnection">LogLevelConnection</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelerror">LogLevelError</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelinfo">LogLevelInfo</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelnoderestart">LogLevelNodeRestart</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelshutdown">LogLevelShutdown</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelstartup">LogLevelStartup</link></literal></entry>
+ <entry>integer</entry>
+ <entry>1</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-loglevelstatistic">LogLevelStatistic</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>15</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-longmessagebuffer">LongMessageBuffer</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>1M</entry>
+ <entry><emphasis>MySQL Cluster 6.4.3 and earlier</emphasis>: 1M;
+ <emphasis>MySQL Cluster NDB 7.0.4 and later</emphasis>:
+ 4M</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxallocate">MaxAllocate</link></literal>
+ (Added in MySQL Cluster NDB 6.1.12 and MySQL Cluster NDB
+ 6.2.3)</entry>
+ <entry>integer (bytes)</entry>
+ <entry>32M</entry>
+ <entry>1M</entry>
+ <entry>1G</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxbufferedepochs">MaxBufferedEpochs</link></literal>
+ (Added in MySQL Cluster NDB 6.2.14)</entry>
+ <entry>integer</entry>
+ <entry>100</entry>
+ <entry>0</entry>
+ <entry>100000</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxlcpstartdelay">MaxLCPStartDelay</link></literal>
+ (Added in MySQL Cluster NDB 6.3.23 and MySQL Cluster NDB
+ 6.4.3)</entry>
+ <entry>integer (seconds)</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>600</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofattributes">MaxNoOfAttributes</link></literal></entry>
+ <entry>integer</entry>
+ <entry>1000</entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofconcurrentindexoperations">MaxNoOfConcurrentIndexOperations</link></literal></entry>
+ <entry>integer</entry>
+ <entry>8K</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofconcurrentoperations">MaxNoOfConcurrentOperations</link></literal></entry>
+ <entry>integer</entry>
+ <entry>32768</entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofconcurrentscans">MaxNoOfConcurrentScans</link></literal></entry>
+ <entry>integer</entry>
+ <entry>256</entry>
+ <entry>2</entry>
+ <entry>500</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofconcurrenttransactions">MaxNoOfConcurrentTransactions</link></literal></entry>
+ <entry>integer</entry>
+ <entry>4096</entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>S</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="mysql-cluster-param-ndbmtd-maxnoofexecutionthreads">MaxNoOfExecutionThreads</link></literal>
+ (added in MySQL Cluster NDB 6.4.0; <emphasis>applies to
+ <command>ndbmtd</command> only</emphasis>)</entry>
+ <entry>integer</entry>
+ <entry>(as of MySQL Cluster NDB 7.0.4:) 2 (previously:
+ <emphasis>none</emphasis>)</entry>
+ <entry>2</entry>
+ <entry>8</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooffiredtriggers">MaxNoOfFiredTriggers</link></literal></entry>
+ <entry>integer</entry>
+ <entry>4000</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofindexes">MaxNoOfIndexes</link></literal>
+ (<emphasis>DEPRECATED</emphasis> — use
+ <literal>MaxNoOfOrderedIndexes</literal> or
+ <literal>MaxNoOfUniqueHashIndexes</literal> instead)</entry>
+ <entry>integer</entry>
+ <entry>128</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooflocaloperations">MaxNoOfLocalOperations</link></literal></entry>
+ <entry>integer</entry>
+ <entry><literal>UNDEFINED</literal></entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooflocalscans">MaxNoOfLocalScans</link></literal></entry>
+ <entry>integer</entry>
+ <entry><literal>UNDEFINED</literal> (see
+ <link linkend="ndbparam-ndbd-maxnooflocalscans">description</link>)</entry>
+ <entry>32</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofopenfiles">MaxNoOfOpenFiles</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0 (prior to MySQL 5.1.16: 40)</entry>
+ <entry>20</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooforderedindexes">MaxNoOfOrderedIndexes</link></literal></entry>
+ <entry>integer</entry>
+ <entry>128</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofsavedmessages">MaxNoOfSavedMessages</link></literal></entry>
+ <entry>integer</entry>
+ <entry>25</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooftables">MaxNoOfTables</link></literal></entry>
+ <entry>integer</entry>
+ <entry>128</entry>
+ <entry>8</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnooftriggers">MaxNoOfTriggers</link></literal></entry>
+ <entry>integer</entry>
+ <entry>768</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-maxnoofuniquehashindexes">MaxNoOfUniqueHashIndexes</link></literal></entry>
+ <entry>integer</entry>
+ <entry>64</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-memreportfrequency">MemReportFrequency</link></literal>
+ (Added in MySQL 5.1.16 and MySQL Cluster NDB 6.1.0)</entry>
+ <entry>integer (seconds)</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-nodegroup">NodeGroup</link></literal>
+ (Added in MySQL Cluster NDB 6.4.0)</entry>
+ <entry>integer</entry>
+ <entry><literal>UNDEFINED</literal> (normally determined by management server)</entry>
+ <entry>0</entry>
+ <entry>65535</entry>
+ <entry>SI</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofdiskpagestodiskafterrestartacc">NoOfDiskPagesToDiskAfterRestartACC</link></literal>
+ (<emphasis>DEPRECATED</emphasis> as of MySQL 5.1.6)</entry>
+ <entry>integer (number of 8KB pages per 100 milliseconds)</entry>
+ <entry>20 (= 20 * 80KB = 1.6MB/second)</entry>
+ <entry>1</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofdiskpagestodiskafterrestarttup">NoOfDiskPagesToDiskAfterRestartTUP</link></literal>
+ (<emphasis>DEPRECATED</emphasis> as of MySQL 5.1.6)</entry>
+ <entry>integer (number of 8KB pages per 100 milliseconds)</entry>
+ <entry>40 (= 40 * 80KB = 3.2MB/second)</entry>
+ <entry>1</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofdiskpagestodiskduringrestartacc">NoOfDiskPagesToDiskDuringRestartACC</link></literal>
+ (<emphasis>DEPRECATED</emphasis> as of MySQL 5.1.6)</entry>
+ <entry>integer (number of 8KB pages per 100 milliseconds)</entry>
+ <entry>20 (= 20 * 80KB = 1.6MB/second)</entry>
+ <entry>1</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofdiskpagestodiskduringrestarttup">NoOfDiskPagesToDiskDuringRestartTUP</link></literal>
+ (<emphasis>DEPRECATED</emphasis> as of MySQL 5.1.6)</entry>
+ <entry>integer (number of 8KB pages per 100 milliseconds)</entry>
+ <entry>40 (= 40 * 80KB = 3.2MB/second)</entry>
+ <entry>1</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-nooffragmentlogfiles">NoOfFragmentLogFiles</link></literal></entry>
+ <entry>integer</entry>
+ <entry>16</entry>
+ <entry>3</entry>
+ <entry>4294967039</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-noofreplicas">NoOfReplicas</link></literal></entry>
+ <entry>integer</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>1</entry>
+ <entry>4 (theoretical); 2 (supported)</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-odirect">ODirect</link></literal></entry>
+ <entry>boolean</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-realtimescheduler">RealTimeScheduler</link></literal>
+ (Added in MySQL Cluster NDB 6.3.4)</entry>
+ <entry>boolean</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-redobuffer">RedoBuffer</link></literal></entry>
+ <entry>bytes</entry>
+ <entry><emphasis>MySQL Cluster 6.4.3 and earlier</emphasis>: 8M;
+ <emphasis>MySQL Cluster NDB 7.0.4 and later</emphasis>:
+ 32M</entry>
+ <entry>1M</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-reservedsendbuffermemory">ReservedSendBufferMemory</link></literal>
+ (added in MySQL Cluster NDB 6.4.0)</entry>
+ <entry>bytes</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>256K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-restartonerrorinsert">RestartOnErrorInsert</link></literal>
+ (<emphasis>DEBUG BUILDS ONLY</emphasis>)</entry>
+ <entry>true|false (<literal>1</literal>|<literal>0</literal>)</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-schedulerexecutiontimer">SchedulerExecutionTimer</link></literal>
+ (added in MySQL Cluster NDB 6.3.4)</entry>
+ <entry>μseconds (integer)</entry>
+ <entry>50</entry>
+ <entry>0</entry>
+ <entry>11000</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-schedulerspintimer">SchedulerSpinTimer</link></literal>
+ (added in MySQL Cluster NDB 6.3.4)</entry>
+ <entry>μseconds (integer)</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>500</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-serverport">ServerPort</link></literal>
+ (<emphasis>OBSOLETE</emphasis>)</entry>
+ <entry>integer</entry>
+ <entry>1186</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-sharedglobalmemory">SharedGlobalmemory</link></literal>
+ (added in MySQL 5.1.6)</entry>
+ <entry>bytes</entry>
+ <entry>20M</entry>
+ <entry>0</entry>
+ <entry>65536G</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-startfailuretimeout">StartFailureTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-startpartialtimeout">StartPartialTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>30000</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-startpartitionedtimeout">StartPartitionedTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>60000</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-stoponerror">StopOnError</link></literal></entry>
+ <entry>true|false (<literal>1</literal>|<literal>0</literal>)</entry>
+ <entry>1</entry>
+ <entry>0</entry>
+ <entry>1</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-stringmemory">StringMemory</link></literal></entry>
+ <entry>integer or percentage (see
+ <link linkend="ndbparam-ndbd-stringmemory">description</link>
+ for details)</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>S</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-tcpbind-inaddr-any">TcpBind_INADDR_ANY</link></literal>
+ (Added in MySQL Cluster NDB 6.2.0)</entry>
+ <entry>true|false (<literal>1</literal>|<literal>0</literal>)</entry>
+ <entry>1</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweenepochs">TimeBetweenEpochs</link></literal>
+ (Added in MySQL Cluster NDB 6.2.5 and MySQL Cluster NDB
+ 6.3.2)</entry>
+ <entry>milliseconds</entry>
+ <entry>100</entry>
+ <entry>0</entry>
+ <entry>32000</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweenepochstimeout">TimeBetweenEpochsTimeout</link></literal>
+ (Added in MySQL Cluster NDB 6.2.7 and MySQL Cluster NDB
+ 6.3.4)</entry>
+ <entry>milliseconds</entry>
+ <entry>4000</entry>
+ <entry>0</entry>
+ <entry>32000</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweenglobalcheckpoints">TimeBetweenGlobalCheckpoints</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>2000</entry>
+ <entry>10</entry>
+ <entry>32000</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweeninactivetransactionabortcheck">TimeBetweenInactiveTransactionAbortCheck</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>1000</entry>
+ <entry>1000</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweenlocalcheckpoints">TimeBetweenLocalCheckpoints</link></literal></entry>
+ <entry>integer (number of 4-byte words as a base-2 logarithm)</entry>
+ <entry>20 (= <literal>4 * 2<superscript>20</superscript></literal> = 4MB write
+ operations)</entry>
+ <entry>0</entry>
+ <entry>31</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweenwatchdogcheck">TimeBetweenWatchDogCheck</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>6000</entry>
+ <entry>70</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-timebetweenwatchdogcheckinitial">TimeBetweenWatchDogCheckInitial</link></literal>
+ (added in MySQL 5.1.20)</entry>
+ <entry>milliseconds</entry>
+ <entry>6000</entry>
+ <entry>70</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-totalsendbuffermemory">TotalSendBufferMemory</link></literal>
+ (added in MySQL Cluster NDB 6.4.0)</entry>
+ <entry>bytes</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>256K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-transactionbuffermemory">TransactionBufferMemory</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>1M</entry>
+ <entry>1K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-transactiondeadlockdetectiontimeout">TransactionDeadlockDetectionTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>1200</entry>
+ <entry>50
+
+ <note>
+ <para>
+ Prior to MySQL Cluster NDB 6.2.18/6.3.24/7.0.5, 100
+ was the effective minimum.
+ </para>
+ </note></entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-transactioninactivetimeout">TransactionInactiveTimeout</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-undodatabuffer">UndoDataBuffer</link></literal>
+ (<emphasis>OBSOLETE</emphasis>)</entry>
+ <entry>bytes</entry>
+ <entry>16M</entry>
+ <entry>1M</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-ndbd-undoindexbuffer">UndoIndexBuffer</link></literal>
+ (<emphasis>OBSOLETE</emphasis>)</entry>
+ <entry>bytes</entry>
+ <entry>2M</entry>
+ <entry>1M</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <note>
+ <para>
+ To add new data nodes to a MySQL Cluster, it is necessary to
+ shut down the cluster completely, update the
+ <filename>config.ini</filename> file, and then restart the
+ cluster (that is, you must perform a system restart). All data
+ node processes must be started with the
+ <option>--initial</option> option.
+ </para>
+
+ <para>
+ Beginning in MySQL Cluster NDB 7.0, it is possible to add new
+ data node groups to a running cluster online. For more
+ information, see
+ <xref linkend="mysql-cluster-online-add-node"/>.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-config-params-mgm">
+
+ <title>MySQL Cluster Management Node Configuration Parameters</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration parameters</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[ndb_mgmd] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[mgm] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ The following table provides information about parameters used
+ in the <literal>[ndb_mgmd]</literal> or <literal>[mgm]</literal>
+ sections of a <filename>config.ini</filename> file for
+ configuring MySQL Cluster management nodes. For detailed
+ descriptions and other additional information about each of
+ these parameters, see
+ <xref linkend="mysql-cluster-mgm-definition"/>.
+ </para>
+
+ <para>
+ <emphasis><emphasis role="bold">Restart Type</emphasis> Column
+ Values</emphasis>
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>N</literal>: Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IN</literal>: Initial Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>S</literal>: System Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IS</literal>: Initial System Restart
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ See <xref linkend="mysql-cluster-config-params-overview"/>, for
+ additional explanations of these abbreviations.
+ </para>
+
+ <table id="mysql-cluster-config-params-mgm-table">
+ <title>MySQL Cluster Management Node Configuration Parameters</title>
+ <tgroup cols="6">
+ <colspec colwidth="30*"/>
+ <colspec colwidth="5*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="5*"/>
+ <tbody>
+ <row>
+ <entry><emphasis role="bold">Parameter Name</emphasis></entry>
+ <entry><emphasis role="bold">Type/Units</emphasis></entry>
+ <entry><emphasis role="bold">Default Value</emphasis></entry>
+ <entry><emphasis role="bold">Minimum Value</emphasis></entry>
+ <entry><emphasis role="bold">Maximum Value</emphasis></entry>
+ <entry><emphasis role="bold">Restart Type</emphasis></entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-arbitrationdelay">ArbitrationDelay</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-arbitrationrank">ArbitrationRank</link></literal></entry>
+ <entry>integer</entry>
+ <entry>1</entry>
+ <entry>0</entry>
+ <entry>2</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-datadir">DataDir</link></literal></entry>
+ <entry>string</entry>
+ <entry><filename>./</filename> (<command>ndb_mgmd</command> directory)</entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-executeoncomputer">ExecuteOnComputer</link></literal></entry>
+ <entry>integer</entry>
+ <entry/>
+ <entry/>
+ <entry/>
+ <entry/>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-hostname">HostName</link></literal></entry>
+ <entry>string</entry>
+ <entry><literal>localhost</literal></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-id">Id</link></literal></entry>
+ <entry>integer</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>1</entry>
+ <entry>(<emphasis>MySQL Cluster NDB 6.1.0 and earlier</emphasis>:) 63;
+ (<emphasis>MySQL Cluster NDB 6.1.1 and
+ later</emphasis>:) 255</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-logdestination">LogDestination</link></literal></entry>
+ <entry><literal>CONSOLE</literal>, <literal>SYSLOG</literal>, or
+ <literal>FILE</literal></entry>
+ <entry><literal>FILE</literal> (see
+ <xref linkend="mysql-cluster-mgm-definition"/>)</entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-portnumber">PortNumber</link></literal></entry>
+ <entry>integer</entry>
+ <entry>1186</entry>
+ <entry>1</entry>
+ <entry>65535</entry>
+ <entry>S</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-mgm-totalsendbuffermemory">TotalSendBufferMemory</link></literal>
+ (added in MySQL Cluster NDB 6.4.0)</entry>
+ <entry>bytes</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>256K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <note>
+ <para>
+ After making changes in a management node's
+ configuration, it is necessary to perform a rolling restart of
+ the cluster in order for the new configuration to take effect.
+ See <xref linkend="mysql-cluster-mgm-definition"/>, for more
+ information.
+ </para>
+
+ <para>
+ To add new management servers to a running MySQL Cluster, it
+ is also necessary perform a rolling restart of all cluster
+ nodes after modifying any existing
+ <filename>config.ini</filename> files. For more information
+ about issues arising when using multiple management nodes, see
+ <xref linkend="mysql-cluster-limitations-multiple-nodes"/>.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="mysql-cluster-config-params-api">
+
+ <title>MySQL Cluster SQL Node and API Node Configuration Parameters</title>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration parameters</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[SQL] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>[api] (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ The following table provides information about parameters used
+ in the <literal>[SQL]</literal> and <literal>[api]</literal>
+ sections of a <filename>config.ini</filename> file for
+ configuring MySQL Cluster SQL nodes and API nodes. For detailed
+ descriptions and other additional information about each of
+ these parameters, see
+ <xref linkend="mysql-cluster-api-definition"/>.
+ </para>
+
+ <note>
+ <para>
+ For a discussion of MySQL server options for MySQL Cluster,
+ see <xref linkend="mysql-cluster-program-options-mysqld"/>;
+ for information about MySQL server system variables relating
+ to MySQL Cluster, see
+ <xref linkend="mysql-cluster-system-variables"/>.
+ </para>
+ </note>
+
+ <para>
+ <emphasis><emphasis role="bold">Restart Type</emphasis> Column
+ Values</emphasis>
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>N</literal>: Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IN</literal>: Initial Node Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>S</literal>: System Restart
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>IS</literal>: Initial System Restart
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ See <xref linkend="mysql-cluster-config-params-overview"/>, for
+ additional explanations of these abbreviations.
+ </para>
+
+ <table id="mysql-cluster-config-params-api-table">
+ <title>MySQL Cluster SQL Node and API Node Configuration Parameters</title>
+ <tgroup cols="6">
+ <colspec colwidth="30*"/>
+ <colspec colwidth="5*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
+ <colspec colwidth="5*"/>
+ <tbody>
+ <row>
+ <entry><emphasis role="bold">Parameter Name</emphasis></entry>
+ <entry><emphasis role="bold">Type/Units</emphasis></entry>
+ <entry><emphasis role="bold">Default Value</emphasis></entry>
+ <entry><emphasis role="bold">Minimum Value</emphasis></entry>
+ <entry><emphasis role="bold">Maximum Value</emphasis></entry>
+ <entry><emphasis role="bold">Restart Type</emphasis></entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-arbitrationdelay">ArbitrationDelay</link></literal></entry>
+ <entry>milliseconds</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-arbitrationrank">ArbitrationRank</link></literal></entry>
+ <entry>integer</entry>
+ <entry>0</entry>
+ <entry>0</entry>
+ <entry>2</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-autoreconnect">AutoReconnect</link></literal>
+ (added in MySQL Cluster NDB 6.3.26 and MySQL Cluster NDB
+ 7.0.7)</entry>
+ <entry>boolean</entry>
+ <entry>false</entry>
+ <entry>false</entry>
+ <entry>true</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-batchbytesize">BatchByteSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>32K</entry>
+ <entry>1K</entry>
+ <entry>1M</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-batchsize">BatchSize</link></literal></entry>
+ <entry>integer</entry>
+ <entry>64</entry>
+ <entry>1</entry>
+ <entry>992</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-executeoncomputer">ExecuteOnComputer</link></literal></entry>
+ <entry>integer</entry>
+ <entry/>
+ <entry/>
+ <entry/>
+ <entry/>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-hostname">HostName</link></literal></entry>
+ <entry>string</entry>
+ <entry><emphasis>none</emphasis></entry>
+ <entry>N/A</entry>
+ <entry>N/A</entry>
+ <entry>IN</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-id">Id</link></literal></entry>
+ <entry>integer</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>1</entry>
+ <entry>(<emphasis>MySQL Cluster NDB 6.1.0 and earlier</emphasis>:) 63;
+ (<emphasis>MySQL Cluster NDB 6.1.1 and
+ later</emphasis>:) 255</entry>
+ <entry>IS</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-maxscanbatchsize">MaxScanBatchSize</link></literal></entry>
+ <entry>bytes</entry>
+ <entry>256K</entry>
+ <entry>32K</entry>
+ <entry>16M</entry>
+ <entry>N</entry>
+ </row>
+ <row>
+ <entry><literal><link linkend="ndbparam-api-totalsendbuffermemory">TotalSendBufferMemory</link></literal>
+ (added in MySQL Cluster NDB 6.4.0)</entry>
+ <entry>bytes</entry>
+ <entry><emphasis>None</emphasis></entry>
+ <entry>256K</entry>
+ <entry>4294967039</entry>
+ <entry>N</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <note>
+ <para>
+ To add new SQL or API nodes to the configuration of a running
+ MySQL Cluster, it is necessary to perform a rolling restart of
+ all cluster nodes after adding new <literal>[mysqld]</literal>
+ or <literal>[api]</literal> sections to the
+ <filename>config.ini</filename> file (or files, if you are
+ using more than one management server). This must be done
+ before the new SQL or API nodes can connect to the cluster.
+ </para>
+
+ <para>
+ It is <emphasis>not</emphasis> necessary to perform any
+ restart of the cluster if new SQL or API nodes can employ
+ previously unused API slots in the cluster configuration to
+ connect to the cluster.
+ </para>
+ </note>
+
+ </section>
+
+ </section>
+
+ <section id="mysql-cluster-config-lcp-params">
+
+ <title>Configuring MySQL Cluster Parameters for Local Checkpoints</title>
+
+ <indexterm>
+ <primary>DataMemory</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>IndexMemory</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskAfterRestartACC</primary>
+ <secondary>calculating</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>NoOfDiskPagesToDiskAfterRestartTUP</primary>
+ <secondary>calculating</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>NoOfFragmentLogFiles</primary>
+ <secondary>calculating</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>local checkpoints (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <remark role="note">
+ [js] Adapted from an item in Mikael Ronström's blog, 2006-07-11.
+ </remark>
+
+ <para>
+ The parameters discussed in
+ <link linkend="mysql-cluster-logging-and-checkpointing">Logging
+ and Checkpointing</link> and in
+ <link linkend="mysql-cluster-data-memory-index-memory-string-memory">Data
+ Memory, Index Memory, and String Memory</link> that are used to
+ configure local checkpoints for a MySQL Cluster do not exist in
+ isolation, but rather are very much interdepedent on each other.
+ In this section, we illustrate how these parameters —
+ including <literal>DataMemory</literal>,
+ <literal>IndexMemory</literal>,
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal>,
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal>, and
+ <literal>NoOfFragmentLogFiles</literal> — relate to one
+ another in a working Cluster.
+ </para>
+
+ <important>
+ <para>
+ The parameters
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> and
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal> were
+ deprecated in MySQL 5.1.6. From MySQL 5.1.6 through 5.1.11, disk
+ writes during LCPs took place at the maximum speed possible.
+ Beginning with MySQL 5.1.12, the speed and throughput for LCPs
+ are controlled using the parameters
+ <literal>DiskSyncSize</literal>,
+ <literal>DiskCheckpointSpeed</literal>, and
+ <literal>DiskCheckpointSpeedInRestart</literal>. See
+ <xref linkend="mysql-cluster-ndbd-definition"/>.
+ </para>
+ </important>
+
+ <para>
+ In this example, we assume that our application performs the
+ following numbers of types of operations per hour:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ 50000 selects
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 inserts
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 updates
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 deletes
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ We also make the following assumptions about the data used in the
+ application:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ We are working with a single table having 40 columns.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Each column can hold up to 32 bytes of data.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A typical <literal role="stmt">UPDATE</literal> run by the
+ application affects the values of 5 columns.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ No <literal>NULL</literal> values are inserted by the
+ application.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ A good starting point is to determine the amount of time that
+ should elapse between local checkpoints (LCPs). It is worth noting
+ that, in the event of a system restart, it takes 40-60 percent of
+ this interval to execute the REDO log — for example, if the
+ time between LCPs is 5 minutes (300 seconds), then it should take
+ 2 to 3 minutes (120 to 180 seconds) for the REDO log to be read.
+ </para>
+
+ <para>
+ The maximum amount of data per node can be assumed to be the size
+ of the <literal>DataMemory</literal> parameter. In this example,
+ we assume that this is 2 GB. The
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> parameter
+ represents the amount of data to be checkpointed per unit time
+ — however, this parameter is actually expressed as the
+ number of 8K memory pages to be checkpointed per 100 milliseconds.
+ 2 GB per 300 seconds is approximately 6.8 MB per second, or 700 KB
+ per 100 milliseconds, which works out to roughly 85 pages per 100
+ milliseconds.
+ </para>
+
+ <para>
+ Similarly, we can calculate
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal> in terms of
+ the time for local checkpoints and the amount of memory required
+ for indexes — that is, the <literal>IndexMemory</literal>.
+ Assuming that we allow 512 MB for indexes, this works out to
+ approximately 20 8-KB pages per 100 milliseconds for this
+ parameter.
+ </para>
+
+ <para>
+ Next, we need to determine the number of REDO log files required
+ — that is, fragment log files — the corresponding
+ parameter being <literal>NoOfFragmentLogFiles</literal>. We need
+ to make sure that there are sufficient REDO log files for keeping
+ records for at least 3 local checkpoints (in MySQL Cluster NDB
+ 6.3.8 and later, we need only allow for 2 local checkpoints). In a
+ production setting, there are always uncertainties — for
+ instance, we cannot be sure that disks always operate at top speed
+ or with maximum throughput. For this reason, it is best to err on
+ the side of caution, so we double our requirement and calculate a
+ number of fragment log files which should be enough to keep
+ records covering 6 local checkpoints (in MySQL Cluster NDB 6.3.8
+ and later, a number of fragment log files accommodating 4 local
+ checkpoints should be sufficient).
+ </para>
+
+ <para>
+ It is also important to remember that the disk also handles writes
+ to the REDO log, so if you find that the amount of data being
+ written to disk as determined by the values of
+ <literal>NoOfDiskPagesToDiskAfterRestartACC</literal> and
+ <literal>NoOfDiskPagesToDiskAfterRestartTUP</literal> is
+ approaching the amount of disk bandwidth available, you may wish
+ to increase the time between local checkpoints.
+ </para>
+
+ <para>
+ Given 5 minutes (300 seconds) per local checkpoint, this means
+ that we need to support writing log records at maximum speed for 6
+ * 300 = 1800 seconds (<emphasis>MySQL Cluster NDB 6.3.8 and
+ later</emphasis>: 4 * 300 = 1200 seconds). The size of a REDO log
+ record is 72 bytes plus 4 bytes per updated column value plus the
+ maximum size of the updated column, and there is one REDO log
+ record for each table record updated in a transaction, on each
+ node where the data reside. Using the numbers of operations set
+ out previously in this section, we derive the following:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ 50000 select operations per hour yields 0 log records (and
+ thus 0 bytes), since <literal role="stmt">SELECT</literal>
+ statements are not recorded in the REDO log.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 <literal role="stmt">DELETE</literal> statements per
+ hour is approximately 5 delete operations per second. (Since
+ we wish to be conservative in our estimate, we round up here
+ and in the following calculations.) No columns are updated by
+ deletes, so these statements consume only 5 operations * 72
+ bytes per operation = 360 bytes per second.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 <literal role="stmt">UPDATE</literal> statements per
+ hour is roughly the same as 5 updates per second. Each update
+ uses 72 bytes, plus 4 bytes per column * 5 columns updated,
+ plus 32 bytes per column * 5 columns — this works out to
+ 72 + 20 + 160 = 252 bytes per operation, and multiplying this
+ by 5 operation per second yields 1260 bytes per second.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 15000 <literal role="stmt">INSERT</literal> statements per
+ hour is equivalent to 5 insert operations per second. Each
+ insert requires REDO log space of 72 bytes, plus 4 bytes per
+ record * 40 columns, plus 32 bytes per column * 40 columns,
+ which is 72 + 160 + 1280 = 1512 bytes per operation. This
+ times 5 operations per second yields 7560 bytes per second.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ So the total number of REDO log bytes being written per second is
+ approximately 0 + 360 + 1260 + 7560 = 9180 bytes. Multiplied by
+ 1800 seconds, this yields 16524000 bytes required for REDO
+ logging, or approximately 15.75 MB. The unit used for
+ <literal>NoOfFragmentLogFiles</literal> represents a set of 4
+ 16-MB log files — that is, 64 MB. Thus, the minimum value
+ (3) for this parameter is sufficient for the scenario envisioned
+ in this example, since 3 times 64 = 192 MB, or about 12 times what
+ is required; the default value of 8 (or 512 MB) is more than ample
+ in this case.
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-config-send-buffers">
+
+ <title>Configuring MySQL Cluster Send Buffer Parameters</title>
+
+ <para>
+ Formerly, the NDB kernel used a send buffer whose size was fixed
+ at 2MB for every node in the cluster, which was allocated when the
+ node started. Because the size of this buffer could not be changed
+ after the cluster was started, it was necessary to make it large
+ enough in advance to accomodate the maximum possible load on any
+ transporter socket. However, this was an inefficient use of
+ memory, since much of it often went unused, and could result in
+ large amounts of resources being wasted when scaling up to many
+ API nodes.
+ </para>
+
+ <para>
+ Beginning with MySQL Cluster NDB 7.0, this problem is solved by
+ employing a unified send buffer whose memory is allocated
+ dynamically from a pool shared by all transporters. This means
+ that the size of the send buffer can be adjusted as necessary.
+ Configuration of the unified send buffer can accomplished by
+ setting the following parameters:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title><literal>TotalSendBufferMemory</literal></title>
+
+ <para>
+ This parameter can be set for all types of MySQL Cluster
+ nodes — that is, it can be set in the
+ <literal>[ndbd]</literal>, <literal>[mgm]</literal>, and
+ <literal>[api]</literal> (or <literal>[mysql]</literal>)
+ sections of the <filename>config.ini</filename> file. It
+ represents the total amount of memory (in bytes) to be
+ allocated by each node for which it is set for use among all
+ configured transporters. If set, its minimum is 256K; the
+ maximum is 4294967039.
+ </para>
+
+ </formalpara>
+
+ <para>
+ In order to be backward-compatible with existing
+ configurations, this parameter takes as its default value the
+ sum of the maximum send buffer sizes of all configured
+ transporters, plus an additional 32KB (one page) per
+ transporter. The maximum depends on the type of transporter,
+ as shown in the following table:
+
+ <informaltable>
+ <tgroup cols="2">
+ <colspec colwidth="30*"/>
+ <colspec colwidth="70*"/>
+ <thead>
+ <row>
+ <entry>Transporter</entry>
+ <entry>Maxmimum Send Buffer Size (bytes)</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>TCP</entry>
+ <entry><literal>SendBufferMemory</literal> (default = 2M)</entry>
+ </row>
+ <row>
+ <entry>SCI</entry>
+ <entry><literal>SendLimit</literal> (default = 8K) plus 16K</entry>
+ </row>
+ <row>
+ <entry>SHM</entry>
+ <entry>20K</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+
+ This allows existing configurations to function in close to
+ the same way as they did with MySQL Cluster NDB 6.3 and
+ earlier, with the same amount of memory and send buffer space
+ available to each transporter. However, memory that is unused
+ by one transporter is not available to other transporters.
+ </para>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title><literal>ReservedSendBufferMemory</literal></title>
+
+ <para>
+ This optional data node parameter, if set, gives an amount
+ of memory (in bytes) that is reserved for connections
+ between data nodes; this memory is not allocated to send
+ buffers used for communications with management servers or
+ API nodes. This provides a way to protect the cluster
+ against misbehaving API nodes that use excess send memory
+ and thus cause failures in communications internally in the
+ NDB kernel. If set, its the minimum permitted value for this
+ parameters is 256K; the maximum is 4294967039.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title><literal>OverloadLimit</literal></title>
+
+ <para>
+ This parameter is used in the <literal>config.ini</literal>
+ file <literal>[tcp]</literal> section, and denotes the
+ amount of unsent data (in bytes) that must be present in the
+ send buffer before the connection is considered overloaded.
+ When such an overload condition occurs, transactions that
+ affect the overloaded connection fail with NDB API Error
+ 1218 (<errortext>Send Buffers overloaded in NDB
+ kernel</errortext>) until the overload status passes. The
+ default value is 0; there is no defined maximum value for
+ this parameter.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title><literal>SendBufferMemory</literal></title>
+
+ <para>
+ In MySQL Cluster NDB 6.3 and earlier, this TCP configuration
+ parameter represented the amount of memory allocated at
+ startup for each configured TCP connection. Beginning with
+ MySQL Cluster NDB 7.0, this value denotes a hard limit for
+ how much memory (out of the total available — that is,
+ <literal>TotalSendBufferMemory</literal>) that may be used
+ by a single transporter. However, the sum of
+ <literal>TotalSendBufferMemory</literal> for all configured
+ transporters may be greater than
+ <literal>SendBufferMemory</literal>. This is a way to save
+ memory when many nodes are in use, as long as the maximum
+ amount of memory is never required by all transporters at
+ the same time.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
+</section>
Modified: trunk/refman-5.1/mysql-cluster.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster.xml 2009-07-30 17:01:52 UTC (rev 15883)
+++ trunk/refman-5.1/mysql-cluster.xml 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 694 bytes
@@ -389,7 +389,7 @@
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="mysql-cluster-multi-computer.xml"/>
- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="mysql-cluster-configuration.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dynxml-local-mysql-cluster-configuration.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dynxml-local-mysql-cluster-optvar.xml"/>
Modified: trunk/refman-5.1-maria/Makefile.depends
===================================================================
--- trunk/refman-5.1-maria/Makefile.depends 2009-07-30 17:01:52 UTC (rev 15883)
+++ trunk/refman-5.1-maria/Makefile.depends 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 1; 1157 bytes
@@ -1190,6 +1190,7 @@
../mysql-monitor-common/metadata/install-agent-core.idmap \
../mysql-monitor-common/metadata/install-unattended-core.idmap \
../mysql-monitor-common/metadata/install-upgrades-core.idmap \
+ ../mysql-monitor-common/metadata/mem-reference-core.idmap \
../ndbapi/metadata/class-ndboperation.idmap \
../ndbapi/metadata/class-ndbtransaction.idmap \
../ndbapi/metadata/class-table.idmap \
@@ -1223,7 +1224,7 @@
../refman-5.1/metadata/internationalization.idmap \
../refman-5.1/metadata/introduction.idmap \
../refman-5.1/metadata/language-structure-core.idmap \
- ../refman-5.1/metadata/mysql-cluster-configuration.idmap \
+ ../refman-5.1/metadata/mysql-cluster-configuration-core.idmap \
../refman-5.1/metadata/mysql-cluster-disk-data.idmap \
../refman-5.1/metadata/mysql-cluster-interconnects.idmap \
../refman-5.1/metadata/mysql-cluster-limitations.idmap \
Modified: trunk/refman-5.4/Makefile.depends
===================================================================
--- trunk/refman-5.4/Makefile.depends 2009-07-30 17:01:52 UTC (rev 15883)
+++ trunk/refman-5.4/Makefile.depends 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 6, Lines Added: 6, Lines Deleted: 5; 2884 bytes
@@ -1360,7 +1360,7 @@
dynxml_local_errors_problems_IMAGES =
dynxml_local_errors_problems_SOURCES = dynxml-local-errors-problems.xml $(dynxml_local_errors_problems_INCLUDES)
dynxml_local_errors_problems_IDMAPS = \
- ../refman-5.1/metadata/mysql-cluster-configuration.idmap \
+ ../refman-5.1/metadata/mysql-cluster-configuration-core.idmap \
../refman-common/metadata/bug-reports.idmap \
metadata/apis-c.idmap \
metadata/dba-log-files.idmap \
@@ -1474,7 +1474,7 @@
images/published/mysql-cfg-fig9.png
dynxml_local_installing_SOURCES = dynxml-local-installing.xml $(dynxml_local_installing_INCLUDES)
dynxml_local_installing_IDMAPS = \
- ../refman-5.1/metadata/mysql-cluster-configuration.idmap \
+ ../refman-5.1/metadata/mysql-cluster-configuration-core.idmap \
../refman-5.1/metadata/mysql-cluster-multi-computer.idmap \
../refman-5.1/metadata/mysql-cluster-programs-core.idmap \
../refman-5.1/metadata/news-5.1-core.idmap \
@@ -3472,6 +3472,7 @@
../mysql-monitor-common/metadata/install-agent-core.idmap \
../mysql-monitor-common/metadata/install-unattended-core.idmap \
../mysql-monitor-common/metadata/install-upgrades-core.idmap \
+ ../mysql-monitor-common/metadata/mem-reference-core.idmap \
../quick-guides/metadata/reservedwords-core.idmap \
../refman-4.1/metadata/introduction.idmap \
../refman-4.1/metadata/sql-syntax-data-definition.idmap \
@@ -3480,7 +3481,7 @@
../refman-5.1/metadata/errors-problems-core.idmap \
../refman-5.1/metadata/faqs.idmap \
../refman-5.1/metadata/introduction.idmap \
- ../refman-5.1/metadata/mysql-cluster-configuration.idmap \
+ ../refman-5.1/metadata/mysql-cluster-configuration-core.idmap \
../refman-5.1/metadata/mysql-cluster-disk-data.idmap \
../refman-5.1/metadata/mysql-cluster-limitations.idmap \
../refman-5.1/metadata/mysql-cluster-management.idmap \
@@ -4408,7 +4409,7 @@
programs_using_SOURCES = programs-using.xml $(programs_using_INCLUDES)
programs_using_IDMAPS = \
../refman-5.0/metadata/windows-config-wizard.idmap \
- ../refman-5.1/metadata/mysql-cluster-configuration.idmap \
+ ../refman-5.1/metadata/mysql-cluster-configuration-core.idmap \
../refman-5.1/metadata/mysql-cluster-multi-computer.idmap \
metadata/dba-multiple-servers.idmap \
metadata/dba-mysqld-server-core.idmap \
@@ -4462,7 +4463,7 @@
programs_SOURCES = programs.xml $(programs_INCLUDES)
programs_IDMAPS = \
../refman-5.0/metadata/windows-config-wizard.idmap \
- ../refman-5.1/metadata/mysql-cluster-configuration.idmap \
+ ../refman-5.1/metadata/mysql-cluster-configuration-core.idmap \
../refman-5.1/metadata/mysql-cluster-multi-computer.idmap \
metadata/apis-c.idmap \
metadata/backup.idmap \
Modified: trunk/refman-6.0/Makefile.depends
===================================================================
--- trunk/refman-6.0/Makefile.depends 2009-07-30 17:01:52 UTC (rev 15883)
+++ trunk/refman-6.0/Makefile.depends 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 0; 676 bytes
@@ -3520,6 +3520,7 @@
../mysql-monitor-common/metadata/install-agent-core.idmap \
../mysql-monitor-common/metadata/install-unattended-core.idmap \
../mysql-monitor-common/metadata/install-upgrades-core.idmap \
+ ../mysql-monitor-common/metadata/mem-reference-core.idmap \
../query-browser/metadata/query-browser.idmap \
../quick-guides/metadata/reservedwords-core.idmap \
../refman-4.1/metadata/introduction.idmap \
Modified: trunk/topic-guides/topics-5.1/Makefile.depends
===================================================================
--- trunk/topic-guides/topics-5.1/Makefile.depends 2009-07-30 17:01:52 UTC (rev 15883)
+++ trunk/topic-guides/topics-5.1/Makefile.depends 2009-07-30 19:12:22 UTC (rev 15884)
Changed blocks: 3, Lines Added: 3, Lines Deleted: 3; 10196 bytes
@@ -100,7 +100,7 @@
../../common/fixedchars.ent \
../../common/phrases.ent \
../../refman-4.1/mysql-cluster-faq.xml \
- ../../refman-5.1/mysql-cluster-configuration.xml \
+ ../../refman-5.1/mysql-cluster-configuration-core.xml \
../../refman-5.1/mysql-cluster-disk-data.xml \
../../refman-5.1/mysql-cluster-glossary.xml \
../../refman-5.1/mysql-cluster-interconnects.xml \
@@ -199,7 +199,7 @@
../../common/phrases.ent \
../../refman-4.1/mysql-cluster-faq.xml \
../../refman-5.1/legalnotice.en.xml \
- ../../refman-5.1/mysql-cluster-configuration.xml \
+ ../../refman-5.1/mysql-cluster-configuration-core.xml \
../../refman-5.1/mysql-cluster-disk-data.xml \
../../refman-5.1/mysql-cluster-glossary.xml \
../../refman-5.1/mysql-cluster-interconnects.xml \
@@ -1400,7 +1400,7 @@
# This rules sets the rebuild for fragments of an arby file when a source file has changed
-mysql-cluster-excerpt-aspec.xml.mysql-cluster-programs.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-faq.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-replication.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-configuration.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-interconnects.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-glossary.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-overview.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster.all.preface.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-disk-data.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-management.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-upgrade-downgrade.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-limitations.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-options-variables.none.chapter.xml mysql-cluster-excerpt-aspec.xm!
l.mysql-cluster-security.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-multi-computer.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-roadmap.none.chapter.xml: ../../refman-5.1/../refman-common/images/published/replicas-groups-1-2.png ../../refman-5.1/metadata/mysql-cluster-multi-computer.idmap ../../refman-5.1/mysql-cluster-security.xml ../../refman-5.1/mysql-cluster.xml ../../refman-5.1/metadata/mysql-cluster-management.idmap ../../refman-5.1/metadata/mysql-cluster-replication.idmap ../../refman-5.1/mysql-cluster-configuration.xml ../../refman-5.1/../refman-common/images/published/rolling-restarts.png mysql-cluster-excerpt-aspec.xml ../../refman-5.1/../refman-common/images/published/cluster-components-1.png ../../refman-5.1/mysql-cluster-replication.xml ../../refman-5.1/metadata/mysql-cluster-roadmap.idmap ../../refman-5.1/../refman-common/images/published/cluster-security-network-2.png ../../refman-5.1/../refman-common/images/published/rep!
licas-groups-1-1.png ../../refman-5.1/metadata/mysql-cluster.i!
dmap ../
../refman-5.1/../refman-common/images/published/cluster-security-network-1.png ../../refman-5.1/metadata/mysql-cluster-security.idmap ../../refman-5.1/metadata/mysql-cluster-upgrade-downgrade.idmap ../../refman-5.1/metadata/mysql-cluster-limitations.idmap ../../refman-5.1/../refman-common/images/published/cluster-security-network-3.png all-entities.ent ../../refman-5.1/mysql-cluster-overview.xml ../../refman-5.1/mysql-cluster-management.xml ../../refman-5.1/../refman-common/images/published/cluster-replication-overview.png ../../refman-5.1/mysql-cluster-disk-data.xml ../../common/phrases.ent ../../refman-5.1/mysql-cluster-glossary.xml ../../refman-5.1/mysql-cluster-interconnects.xml ../../refman-5.1/metadata/mysql-cluster-configuration.idmap ../../refman-common/urls.ent ../../refman-5.1/metadata/mysql-cluster-disk-data.idmap ../../refman-5.1/../refman-common/images/published/cluster-replication-binlog-injector.png ../../refman-5.1/mysql-cluster-multi-computer.xml ../../refma!
n-5.1/versions.ent ../../refman-5.1/../refman-common/images/published/ndb-size-pl-1.png mysql-cluster-excerpt-base.xml ../../refman-5.1/../refman-common/images/published/mysql-cluster-upgrade-downgrade-6-x.png ../../common/fixedchars.ent ../../refman-5.1/../refman-common/images/published/cluster-circular-replication-2.png ../../refman-5.1/mysql-cluster-limitations.xml ../../refman-5.1/../refman-common/images/published/mysql-cluster-upgrade-downgrade-5-1.png ../../refman-5.1/../refman-common/images/published/cluster-replication-multi-master-mysqlds.png ../../refman-5.1/../refman-common/images/published/cluster-replication-ipv6.png ../../refman-5.1/metadata/mysql-cluster-overview.idmap ../../refman-5.1/metadata/mysql-cluster-interconnects.idmap ../../refman-5.1/../refman-common/images/published/multi-comp-1.png ../../refman-5.1/mysql-cluster-roadmap.xml ../../refman-5.1/../refman-common/images/published/cluster-circular-replication-1.png ../../refman-5.1/mysql-cluster-program!
s-core.xml ../../refman-5.1/mysql-cluster-upgrade-downgrade.xm!
l ../../
refman-5.1/metadata/mysql-cluster-programs-core.idmap ../../refman-5.1/metadata/mysql-cluster-glossary.idmap ../../refman-5.1/../refman-common/images/published/cluster-replication-multi-master.png ../../refman-4.1/mysql-cluster-faq.xml ../../refman-5.1/mysql-cluster-optvar-core.xml ../../refman-5.1/metadata/mysql-cluster-optvar-core.idmap
+mysql-cluster-excerpt-aspec.xml.mysql-cluster-programs.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-faq.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-replication.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-configuration.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-interconnects.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-glossary.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-overview.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster.all.preface.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-disk-data.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-management.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-upgrade-downgrade.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-limitations.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-options-variables.none.chapter.xml mysql-cluster-excerpt-aspec.xm!
l.mysql-cluster-security.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-multi-computer.none.chapter.xml mysql-cluster-excerpt-aspec.xml.mysql-cluster-roadmap.none.chapter.xml: ../../refman-5.1/../refman-common/images/published/replicas-groups-1-2.png ../../refman-5.1/metadata/mysql-cluster-multi-computer.idmap ../../refman-5.1/mysql-cluster-security.xml ../../refman-5.1/mysql-cluster.xml ../../refman-5.1/metadata/mysql-cluster-management.idmap ../../refman-5.1/metadata/mysql-cluster-replication.idmap ../../refman-5.1/../refman-common/images/published/rolling-restarts.png mysql-cluster-excerpt-aspec.xml ../../refman-5.1/../refman-common/images/published/cluster-components-1.png ../../refman-5.1/mysql-cluster-replication.xml ../../refman-5.1/metadata/mysql-cluster-roadmap.idmap ../../refman-5.1/../refman-common/images/published/cluster-security-network-2.png ../../refman-5.1/../refman-common/images/published/replicas-groups-1-1.png ../../refman-5.1/metadata/my!
sql-cluster.idmap ../../refman-5.1/../refman-common/images/pub!
lished/c
luster-security-network-1.png ../../refman-5.1/mysql-cluster-configuration-core.xml ../../refman-5.1/metadata/mysql-cluster-security.idmap ../../refman-5.1/metadata/mysql-cluster-upgrade-downgrade.idmap ../../refman-5.1/metadata/mysql-cluster-limitations.idmap ../../refman-5.1/../refman-common/images/published/cluster-security-network-3.png all-entities.ent ../../refman-5.1/mysql-cluster-overview.xml ../../refman-5.1/mysql-cluster-management.xml ../../refman-5.1/../refman-common/images/published/cluster-replication-overview.png ../../refman-5.1/mysql-cluster-disk-data.xml ../../common/phrases.ent ../../refman-5.1/mysql-cluster-glossary.xml ../../refman-5.1/mysql-cluster-interconnects.xml ../../refman-common/urls.ent ../../refman-5.1/metadata/mysql-cluster-disk-data.idmap ../../refman-5.1/../refman-common/images/published/cluster-replication-binlog-injector.png ../../refman-5.1/mysql-cluster-multi-computer.xml ../../refman-5.1/versions.ent ../../refman-5.1/../refman-common/im!
ages/published/ndb-size-pl-1.png mysql-cluster-excerpt-base.xml ../../refman-5.1/../refman-common/images/published/mysql-cluster-upgrade-downgrade-6-x.png ../../common/fixedchars.ent ../../refman-5.1/../refman-common/images/published/cluster-circular-replication-2.png ../../refman-5.1/metadata/mysql-cluster-configuration-core.idmap ../../refman-5.1/mysql-cluster-limitations.xml ../../refman-5.1/../refman-common/images/published/mysql-cluster-upgrade-downgrade-5-1.png ../../refman-5.1/../refman-common/images/published/cluster-replication-multi-master-mysqlds.png ../../refman-5.1/../refman-common/images/published/cluster-replication-ipv6.png ../../refman-5.1/metadata/mysql-cluster-overview.idmap ../../refman-5.1/metadata/mysql-cluster-interconnects.idmap ../../refman-5.1/../refman-common/images/published/multi-comp-1.png ../../refman-5.1/mysql-cluster-roadmap.xml ../../refman-5.1/../refman-common/images/published/cluster-circular-replication-1.png ../../refman-5.1/mysql-clust!
er-programs-core.xml ../../refman-5.1/mysql-cluster-upgrade-do!
wngrade.
xml ../../refman-5.1/metadata/mysql-cluster-programs-core.idmap ../../refman-5.1/metadata/mysql-cluster-glossary.idmap ../../refman-5.1/../refman-common/images/published/cluster-replication-multi-master.png ../../refman-4.1/mysql-cluster-faq.xml ../../refman-5.1/mysql-cluster-optvar-core.xml ../../refman-5.1/metadata/mysql-cluster-optvar-core.idmap
$(MAKE) mysql-cluster-excerpt.arbitraryforce
# This rules sets the fragments of a final arby file to be dependent for the -arbitrary (true) target
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r15884 - in trunk: dynamic-docs/command-optvars mysql-monitor-2.0 mysql-monitor-2.1 mysql-monitor-common ndbapi quick-g... | jon.stephens | 30 Jul |
