Below is the list of changes that have just been committed into a local
mysqldoc repository of jon. When jon does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.2673 05/05/18 01:14:13 jon@stripped +1 -0
Cluster Chapter:
- General: Terminology change
- storage node -> data node (Vinay)
- Change History: misc. cleanup
Docs/manual.texi
1.2862 05/05/18 01:14:08 jon@stripped +331 -340
Cluster Chapter:
- General: Terminology change
- storage node -> data node (Vinay)
- Change History: misc. cleanup
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: jon
# Host: gigan.site
# Root: /home/jon/bk/mysqldoc
--- 1.2861/Docs/manual.texi 2005-05-17 14:04:16 +10:00
+++ 1.2862/Docs/manual.texi 2005-05-18 01:14:08 +10:00
@@ -71580,22 +71580,21 @@
engine.
A MySQL Cluster consists of a set of computers, each running a number of
-processes including MySQL servers, storage nodes for NDB Cluster, management
+processes including MySQL servers, data nodes for NDB Cluster, management
servers, and (possibly) specialised data access programs. The relationship of
-these components in a cluster are shown here:
+these components in a cluster is shown here:
@image{Images/cluster-components-1,550,688,Components of a MySQL Cluster,png}
-All these programs
-work together to form MySQL Cluster. When data is stored in the NDB Cluster
-storage engine, the tables are stored in the storage nodes for NDB Cluster. Such
+All these programs work together to form a MySQL Cluster. When data is stored in
+the NDB Cluster storage engine, the tables are stored in the data nodes. Such
tables are directly accessible from all other MySQL servers in the cluster.
Thus, in a payroll application storing data in a cluster, if one application
updates the salary of an employee, all other MySQL servers that query this data
can see this change immediately.
-The data stored in the storage nodes for MySQL Cluster can be mirrored; the
-cluster can handle failures of individual storage nodes with no other impact
+The data stored in the data nodes for MySQL Cluster can be mirrored; the
+cluster can handle failures of individual data nodes with no other impact
than that a small number of transactions are aborted due to losing the
transaction state. Since transactional applications are expected to handle
transaction failure, this should not be a source of problems.
@@ -71649,12 +71648,11 @@
command @command{ndb_mgmd}.
@item
- The @strong{storage node} (or @strong{data node}): This is the type of node
- that stores the cluster's data. There are as many storage nodes as there are
- replicas, times the number of fragments. For example, with two replicas, each
- having two fragments, you will need four storage nodes. It is not necessary to
- have more than one replica. A storage node is started with the command
- @command{ndbd}.
+ The @strong{data node}: This is the type of node that stores the cluster's
+ data. There are as many data nodes as there are replicas, times the number of
+ fragments. For example, with two replicas, each having two fragments, you will
+ need four data nodes. It is not necessary to have more than one replica. A
+ data node is started with the command @command{ndbd}.
@item
The @strong{SQL node}: This is the node that accesses the cluster data. In the
@@ -71675,7 +71673,7 @@
The management server (MGM node) manages the cluster configuration file and the
cluster log. Each node in the cluster retrieves the configuration data from the
management server, and so requires a way to determine where the management
-server resides. When interesting events occur in the storage nodes, the nodes
+server resides. When interesting events occur in the data nodes, the nodes
transfer information about these events to the management server, which then
writes the information to the cluster log.
@@ -71759,7 +71757,7 @@
@item Management (MGM) node @tab 192.168.0.10
@item MySQL server (SQL) node @tab 192.168.0.20
@item Storage (NDBD) node "A" @tab 192.168.0.30
- @item Storage node "B" @tab 192.168.0.40
+ @item data node "B" @tab 192.168.0.40
@end multitable
This may be made clearer in the following diagram:
@@ -71800,7 +71798,7 @@
available for download from the MySQL AB website. As this database takes up
a relatively small amount of space, we assume that each machine has 256 MB
RAM, which should be sufficient for running the operating system and host NDB
- process, and (for the storage nodes) for storing the database.
+ process, and (for the data nodes) for storing the database.
@end enumerate
@@ -71955,7 +71953,7 @@
chgrp -R mysql .
@end example
- Note that the data directory on each machine hosting a storage node is
+ Note that the data directory on each machine hosting a data node is
@file{/usr/local/mysql/data}. We will make use of this piece of information
when we configure the management node. (See @ref{Multi-Config}.)
@@ -72024,7 +72022,7 @@
@itemize @bullet
@item
- Each storage node or SQL node will require a @file{my.cnf} file that provides
+ Each data node or SQL node will require a @file{my.cnf} file that provides
two pieces of information: a @strong{connectstring} telling the node where to
find the MGM node, and a line telling the MySQL server on this host (the
machine hosting the data node) to run in NDB mode.
@@ -72034,15 +72032,15 @@
@item
The management node will need a @file{config.ini} file telling it how
many replicas are to be maintained, how much memory to allocate for data
- and indexes on each storage node, where to find the storage nodes, where
- data will be saved to disk on each storage node, and where to find any SQL
+ and indexes on each data node, where to find the data nodes, where
+ data will be saved to disk on each data node, and where to find any SQL
nodes.
@end itemize
@subsubheading Configuring the Storage and SQL Nodes
-The @file{my.cnf} file needed for the storage nodes is fairly simple. The
+The @file{my.cnf} file needed for the data nodes is fairly simple. The
configuration file should be located in the @file{/etc} directory and can be
edited (and created if necessary) using any text editor, for example:
@@ -72050,7 +72048,7 @@
vi /etc/my.cnf
@end example
-For each storage node and SQL node in our example setup, @file{my.cnf} should
+For each data node and SQL node in our example setup, @file{my.cnf} should
look like this:
@example
@@ -72063,7 +72061,7 @@
@end example
After entering the above, save this file and exit the text editor. Do this for
-the machines hosting storage node "A", storage node "B", and the SQL node.
+the machines hosting data node "A", data node "B", and the SQL node.
@subsubheading Configuring the Management Node
@@ -72084,7 +72082,7 @@
@example
-[NDBD DEFAULT] # Options affecting ndbd processes on all storage nodes:
+[NDBD DEFAULT] # Options affecting ndbd processes on all data nodes:
NoOfReplicas=2 # Number of replicas
DataMemory=80M # How much memory to allocate for data storage
IndexMemory=52M # How much memory to allocate for index storage
@@ -72104,14 +72102,14 @@
hostname=192.168.0.10 # Hostname or IP address of MGM node
datadir=/var/lib/mysql-cluster # Directory for MGM node logfiles
-[NDBD] # Options for storage node "A":
- # (one [NDBD] section per storage node)
+[NDBD] # Options for data node "A":
+ # (one [NDBD] section per data node)
hostname=192.168.0.30 # Hostname or IP address
-datadir=/usr/local/mysql/data # Directory for this storage node's datafiles
+datadir=/usr/local/mysql/data # Directory for this data node's datafiles
-[NDBD] # Options for storage node "B":
+[NDBD] # Options for data node "B":
hostname=192.168.0.40 # Hostname or IP address
-datadir=/usr/local/mysql/data # Directory for this storage node's datafiles
+datadir=/usr/local/mysql/data # Directory for this data node's datafiles
[MYSQLD] # SQL node options:
hostname=192.168.0.20 # Hostname or IP address
@@ -72136,7 +72134,7 @@
backups, see @ref{MySQL Cluster Backup Configuration}.
@strong{Note}: The default port for Cluster management nodes is 1186; the
-default port for storage nodes is 2202.
+default port for data nodes is 2202.
@node Multi-Initial, Multi-Load-Data-Queries, Multi-Config, Multi-Computer
@subsection Initial Startup
@@ -72162,8 +72160,8 @@
process} for details.)
@item
- On each of the storage node hosts, run this command to start the NDBD process
- for the first time:
+ On each of the data node hosts, run this command to start the NDBD process for
+ the first time:
@example
shell> ndbd --initial
@@ -72318,11 +72316,11 @@
It is important to note that NDB Cluster in MySQL 4.1 and MySQL 5.0 does not
support autodiscovery of databases. (See
@ref{MySQL Cluster Limitations in 4.1}.) This means that, once the
- @strong{world} database and its tables have been created on one storage node,
- you will need to issue the command @command{CREATE DATABASE world;} (beginning
+ @strong{world} database and its tables have been created on one data node,you
+ will need to issue the command @command{CREATE DATABASE world;} (beginning
with MySQL 5.0.2, you may use @command{CREATE SCHEMA world;} instead) followed
- by @command{FLUSH TABLES;} on each storage node in the cluster. This will
- cause the node recognise the database and read its table definitions.
+ by @command{FLUSH TABLES;} on each data node in the cluster. This will cause
+ the node to recognise the database and read its table definitions.
Running @command{SELECT} queries on the SQL node is no different than running
them on any other instance of a MySQL server. To run queries from the command
@@ -72493,7 +72491,7 @@
@end example
@item
- On each of the storage node hosts (192.168.0.30 and 192.168.0.40):
+ On each of the data node hosts (192.168.0.30 and 192.168.0.40):
@example
shell> ndbd
@@ -72576,7 +72574,7 @@
you require more information about the latter.)
You will find Cluster configuration easiest if you have already have all
-management and storage nodes running first; this is likely to be the most
+management and data nodes running first; this is likely to be the most
time-consuming part of the configuration. Editing the @file{my.cnf} file is
fairly straightforward, and this section will cover only any differences from
configuring MySQL without clustering.
@@ -72602,11 +72600,11 @@
@code{DataDir} as necessary for your system.
@example
-# file "config.ini" - showing minimal setup consisting of 1 storage node,
+# 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.
-# Storage nodes must to provide a hostname but MySQL Servers are not required
+# 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
@@ -72656,9 +72654,9 @@
@end example
This is because the @code{--initial} option will delete all existing data and
-log files (as well as all table metadata) for this storage node and create new
+log files (as well as all table metadata) for this data node and create new
ones. One exception to this rule is when restarting the cluster and restoring
-from backup after adding new storage nodes.
+from backup after adding new data nodes.
@c TODO: xref here to startup options
@@ -72765,7 +72763,7 @@
* MySQL Cluster Connectstring:: The MySQL Cluster @code{connectstring}
* MySQL Cluster Computer Definition:: Defining the Computers Making up a MySQL Cluster
* MySQL Cluster MGM Definition:: Defining the MySQL Cluster Management Server
-* MySQL Cluster DB Definition:: Defining MySQL Cluster Storage Nodes
+* MySQL Cluster DB Definition:: Defining MySQL Cluster Data Nodes
* MySQL Cluster API Definition:: Defining the SQL Nodes in a MySQL Cluster
* MySQL Cluster TCP Definition:: MySQL Cluster TCP/IP Connections
* MySQL Cluster Direct TCP Definition:: MySQL Cluster TCP/IP Connections Using Direct Connections
@@ -72787,7 +72785,7 @@
server, which then distributes the information contained in this file to all
processes participating in the cluster. @file{config.ini} contains a
description of each node involved in the cluster. This includes configuration
- parameters for storage nodes and configuration parameters for connections
+ parameters for data nodes and configuration parameters for connections
between all nodes in the cluster.
@end itemize
@@ -72864,34 +72862,32 @@
@c more [mysql_cluster] settings to come later...
Currently the configuration file is in INI format, and is named
-@file{config.ini} by default. It is read by @command{ndb_mgmd} at
-startup and it can be placed anywhere. Its location and name are
-specified by using @code{--config-file=[<path>]<filename>} on the
-command line with @command{ndb_mgmd}. If the configuration file is not
-specified, @command{ndb_mgmd} will by default try to read a
-@file{config.ini} located in the current working directory.
+@file{config.ini} by default. It is read by @command{ndb_mgmd} at startup and
+can be placed anywhere. Its location and name are specified by using
+@code{--config-file=[@var{<path>}]@var{<filename>}} on the command line with
+@command{ndb_mgmd}. If the configuration file is not specified,
+@command{ndb_mgmd} will by default try to read a @file{config.ini} file located
+in the current working directory.
Default values are defined for most parameters, and can also be specified in
@file{config.ini}. To create a default value section, simply add the word
-@code{DEFAULT} to the section name. For example, storage nodes are configured
-using @code{[NDBD]} sections. If all storage nodes use the same data memory
-size, and this is not the same as the default size, create an @code{[NDBD
-DEFAULT]} section containing a @code{DataMemory} line to specify the default
-data memory size for all data nodes.
-
-The INI format consists of sections preceded by section headings
-(surrounded by square brackets), followed by the appropriate parameter
-names and values. One deviation from the standard format is that the
-parameter name and value can be separated by a colon (@samp{:}) as well
-as the equals sign (@samp{=}); another is that sections are not
-uniquely identified by name. Instead, unique entries (such as two
-different nodes of the same type) are identified by a unique ID.
+@code{DEFAULT} to the section name. For example, data nodes are configured using
+@code{[NDBD]} sections. If all data nodes use the same data memory size, and
+this is not the same as the default size, create an @code{[NDBD DEFAULT]}
+section containing a @code{DataMemory} line to specify the default data memory
+size for all data nodes.
+
+The INI format consists of sections preceded by section headings (surrounded by
+square brackets), followed by the appropriate parameter names and values. One
+deviation from the standard format is that the parameter name and value can be
+separated by a colon (@samp{:}) as well as the equals sign (@samp{=}); another
+is that sections are not uniquely identified by name. Instead, unique entries
+(such as two different nodes of the same type) are identified by a unique ID.
At a minimum, the 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 storage nodes and two MySQL
-servers is shown below:
+consisting of one management server, two data nodes and two MySQL servers is shown below:
@example
# file "config.ini" - 2 data nodes and 2 SQL nodes
@@ -72927,7 +72923,7 @@
@code{[COMPUTER]}: Defines the the cluster hosts.
@item
-@code{[NDBD]}: Defines the cluster's storage nodes.
+@code{[NDBD]}: Defines the cluster's data nodes.
@item
@code{[MYSQLD]}: Defines the cluster's MySQL server nodes.
@@ -72947,9 +72943,9 @@
@end itemize
-Note that each node has its own section in the @file{config.ini}. For
-instance, since this cluster has two storage nodes, the configuration
-file contains two sections defining these nodes.
+Note that each node has its own section in the @file{config.ini}. For instance,
+since this cluster has two data nodes, the configuration file contains two
+sections defining these nodes.
One can define @code{DEFAULT} values for each section. As of MySQL
4.1.5, all parameter names are case-insensitive.
@@ -73170,11 +73166,11 @@
@node MySQL Cluster DB Definition, MySQL Cluster API Definition, MySQL Cluster MGM Definition, MySQL Cluster Config File
-@subsubsection Defining MySQL Cluster Storage Nodes
+@subsubsection Defining MySQL Cluster Data Nodes
-The @code{[NDBD]} section is used to configure the behavior of the storage
-nodes. There are many parameters which control buffer sizes, pool
-sizes, timeouts, and so forth. The only mandatory parameters are:
+The @code{[NDBD]} section is used to configure the behavior of the cluster's
+data nodes. There are many parameters which control buffer sizes, pool sizes,
+timeouts, and so forth. The only mandatory parameters are:
@itemize @-
@@ -73188,15 +73184,15 @@
These need to be defined in the @code{[NDBD DEFAULT]} section.
-Most storage node parameters are set in the @code{[NDBD DEFAULT]} section. Only
-those parameters explicitly stated as being possible set locally local values
-are allowed to be changed in the @code{[NDBD]} section. @code{HostName},
-@code{Id} and @code{ExecuteOnComputer} @emph{must} be defined in the local
-@code{[NDBD]} section.
+Most data node parameters are set in the @code{[NDBD DEFAULT]} section. Only
+those parameters explicitly stated as being able to set local values are allowed
+to be changed in the @code{[NDBD]} section. @code{HostName}, @code{Id} and
+@code{ExecuteOnComputer} @emph{must} be defined in the local @code{[NDBD]}
+section.
-@subsubheading Identifying Storage Nodes
+@subsubheading Identifying Data Nodes
-The @code{Id} value (that is, the the storage node identifier) can be allocated
+The @code{Id} value (that is, the the data node identifier) can be allocated
on the command line when the node is started or in the configuration file.
For each parameter it is possible to use @code{k}, @code{M}, or @code{G} as a
@@ -73234,16 +73230,16 @@
that all store the same information.
Node groups are formed implicitly. The first node group is formed by the set of
-storage 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 storage nodes and that @code{NoOfReplicas} is set to 2. The four storage
-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, as in this situation a single hardware failure
-would cause the entire cluster to crash.
+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 @code{NoOfReplicas} 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, as in this situation a single hardware failure would cause
+the entire cluster to crash.
-If no node IDs are provided then the order of the storage nodes will be the
+If no node IDs are provided then 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 @code{SHOW}
command.
@@ -73307,12 +73303,12 @@
The memory space allocated by @code{DataMemory} consists of 32KB pages, which
are allocated to table fragments. Each table is normally partitioned into the
-same number of fragments as there are storage nodes in the cluster. Thus, for
-each node, there are the same number of fragments as are set in
-@code{NoOfReplicas}. 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.
-Performing a node recovery also will compress the partition because all records
-are inserted into empty partitions from other live nodes.
+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 @code{NoOfReplicas}.
+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. Performing a node recovery
+also will compress the partition because all records are inserted into empty
+partitions from other live nodes.
The @code{DataMemory} memory space also contains UNDO information: For each
update, a copy of the unaltered record is allocated in the @code{DataMemory}.
@@ -73399,12 +73395,12 @@
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 2 replicas, then there will be two node groups. Thus, the
-total data memory available is 2*@code{DataMemory} for each storage node.
+total data memory available is 2*@code{DataMemory} for each data node.
-It is highly recommended that @code{DataMemory} and @code{IndexMemory} be set
-to the same values for all nodes. Since data is distributed evenly over all
-nodes in the cluster the maximum amount of space available is no better than
-that of the smallest node in the cluster.
+It is highly recommended that @code{DataMemory} and @code{IndexMemory} be set to
+the same values for all nodes. Since data is distributed evenly over all nodes
+in the cluster the maximum amount of space available is no better than that of
+the smallest node in the cluster.
@code{DataMemory} and @code{IndexMemory} can be changed, but decreasing either
of these can be risky; doing so can easily lead to a node or even an entire
@@ -73412,7 +73408,7 @@
Increasing these values should be quite okay, 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, then restarting the management server
-followed by restarting each storage node in turn.
+followed by restarting each data node in turn.
Updates do not increase the amount of index memory used. Inserts take effect
immediately; however, rows are not actually deleted until the transaction is
@@ -73473,10 +73469,10 @@
records for rollback, lock queues, and other purposes.
This parameter should be set to the number of records to be updated
-simultaneously in transactions, divided by the number of Cluster storage nodes.
-For example, in a cluster which has 4 storage nodes and which is expected to
-handle 1,000,000 concurrent updates using transactions, you should set this
-value to 1000000 / 4 = 250000.
+simultaneously in transactions, divided by the number of cluster data nodes. For
+example, in a cluster which has 4 data nodes and which is expected to handle
+1,000,000 concurrent updates using transactions, you should set this value to
+1000000 / 4 = 250000.
Read queries which set locks also cause operation records to be created. Some
extra space is allocated in the individual nodes to accomodate cases where the
@@ -73606,15 +73602,15 @@
This parameter specifies the number of scans possible in the transaction
co-ordinator. If the number of local scan records is not provided, it is
calculated as the product of @code{MaxNoOfConcurrentScans} and the number
-of storage nodes in the system.
+of data nodes in the system.
@item [NDBD]MaxNoOfLocalScans
Specifies the number of local scan records if many scans are not fully
parallelized.
@item [NDBD]BatchSizePerLocalScan
-This parameter is used to calculate the number of lock records which needs
-to be there to handle many concurrent scan operations.
+This parameter is used to calculate the number of lock records which needs to be
+there to handle many concurrent scan operations.
The default value is 64; this value has a strong connection to the
@code{ScanBatchSize} defined in the SQL nodes.
@@ -73743,7 +73739,7 @@
@subsubheading Boolean Parameters
-The behavior of storage nodes is also affected by a set of parameters taking
+The behavior of data nodes is also affected by a set of parameters taking on
boolean values. These parameters can be specified as @strong{TRUE} by setting
them equal to @strong{1} or @strong{Y}, and as @strong{FALSE} by setting them
equal to @strong{0} or @strong{N}.
@@ -73751,8 +73747,8 @@
@table @code
@item [NDBD]LockPagesInMainMemory
For a number of operating systems, including Solaris and Linux, it is possible
-to lock a process into memory and avoid any swapping to disk. This can be used
-to help guarantee the cluster's real-time characteristics.
+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.
By default, this feature is disabled.
@@ -73792,7 +73788,7 @@
@subsubheading Controlling Timeouts, Intervals, and Disk Paging
There are a number of parameters specifying timeouts and intervals between
-various actions in Cluster storage nodes. Most of the timeout values are
+various actions in Cluster data nodes. Most of the timeout values are
specified in milliseconds. Any exceptions to this will be mentioned below.
@table @code
@@ -73824,15 +73820,15 @@
The default timeout is 60000 milliseconds (60 seconds).
@item [NDBD]StartFailureTimeout
-If a storage node has not completed its startup sequence within the time
-specified by this parameter, then the node startup will fail. Setting this
-parameter to @strong{0} means that no storage node timeout is applied.
-
-The default value is 60000 milliseconds (60 seconds). For storage nodes
-containing extremely large amounts of data, this parameter should be increased.
-For example, in the case of a storage node containing several gigabytes of data,
-it could very well take 10-15 minutes (that is, 600,000 to 1,000,000
-milliseconds) to perform a node restart.
+If a data node has not completed its startup sequence within the time specified
+by this parameter, then the node startup will fail. Setting this parameter to
+@strong{0} means that no data node timeout is applied.
+
+The default value is 60000 milliseconds (60 seconds). For data nodes containing
+extremely large amounts of data, this parameter should be increased. For
+example, in the case of a storage node containing several gigabytes of data, a
+period as long as 10-15 minutes (that is, 600,000 to 1,000,000 milliseconds)
+might be required in order to to perform a node restart.
@item [NDBD]HeartbeatIntervalDbDb
One of the primary methods of discovering failed nodes is by the use
@@ -73849,24 +73845,25 @@
increments.
@item [NDBD]HeartbeatIntervalDbApi
-Each storage 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 "dead", in which case all ongoing transactions are
-completed and all resources released. The SQL node cannot reconnect until the
-completion of all activities started by the previous MySQL instance have been
-completed. The three-heartbeat criteria for this determination are the same as
-described for @code{HeartbeatIntervalDbDb}.
+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 "dead", in which case all ongoing transactions are completed and
+all resources released. The SQL node cannot reconnect until the completion of
+all activities started by the previous MySQL instance have been completed. The
+three-heartbeat criteria for this determination are the same as described for
+@code{HeartbeatIntervalDbDb}.
The default interval is 1500 milliseconds (1.5 seconds). This interval can vary
-between indidivual storage nodes because each storage node watches the MySQL
-servers connected to it, independently of all other storage nodes.
+between indidivual data nodes because each storage node watches the MySQL
+servers connected to it, independently of all other data nodes.
@item [NDBD]TimeBetweenLocalCheckpoints
This parameter is an exception in that it doesn't specify a time to wait before
-starting a new local checkpoint; it is used to ensure that local checkpoints a
-re not performed in a cluster where not so many 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.
+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.
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
@@ -73998,7 +73995,7 @@
The default value is 20 (1.6MB per second).
@item [NDBD]ArbitrationTimeout
-This parameter specifies the time that the storage node will wait for a response
+This parameter specifies the time that the data node will wait for a response
from the arbitrator to an arbitration message. If this is exceeded, then it is
assumed that the network has split.
@@ -74240,7 +74237,7 @@
64. The maximum size is 992.
@item [MYSQLD]MaxScanBatchSize
-The batch size is the size of each batch sent from each storage node. Most scans
+The batch size is the size of each batch sent from each data node. Most scans
are performed in parallel in order 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.
@@ -74254,9 +74251,9 @@
TCP/IP is the default transport mechanism for establishing connections in
MySQL Cluster. It is normally not necessary to define connections because
-Cluster automatically set ups a connection between each of the storage nodes,
-between each storage node and all MySQL server nodes, and between each storage
-node and the management server. (For one exception to this rule, see
+Cluster automatically set ups a connection between each of the data nodes,
+between each data node and all MySQL server nodes, and between each data node
+and the management server. (For one exception to this rule, see
@strong{MySQL Cluster TCP/IP Connections Using Crossover} later in this
section.)
@@ -74308,16 +74305,16 @@
@node MySQL Cluster Direct TCP Definition, MySQL Cluster SHM Definition, MySQL Cluster TCP Definition, MySQL Cluster Config File
@subsubsection MySQL Cluster TCP/IP Connections Using Direct Connections
-Setting up a cluster using direct connections between storage nodes requires
-specifying explicitly the crossover IP addresses of the storage nodes so
-connected in the @code{[TCP]} section of the cluster @file{config.ini} file.
+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 @code{[TCP]} section of the cluster @file{config.ini} file.
In the following example, we envision a cluster with at least 4 hosts, one each
-for a management server, an SQL node, and two storage nodes. The cluster as a
-whole resides on the 172.23.72.* subnet of a LAN. In addition to the usual
-network connections, the two storage nodes are connected directly using a
-standard crossover cable, and communicate with one another directly using IP
-addresses in the 1.1.0.* address range as shown:
+for a management server, an SQL node, and two data nodes. The cluster as a whole
+resides on the 172.23.72.* 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 1.1.0.* address range as shown:
@example
# Management Server
@@ -74330,7 +74327,7 @@
Id=2
HostName=172.23.72.21
- # Storage Nodes
+ # Data Nodes
[NDBD]
Id=3
HostName=172.23.72.22
@@ -74347,13 +74344,13 @@
HostName2=1.1.0.2
@end example
-The use of direct connections between storage nodes can improve the cluster's
-overall efficiency by allowing the storage nodes to bypass an Ethernet device
-switch, hub, or router, thus cutting down on the cluster's latency. It is
+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 in order to take the best advantage of direct connections
-in this fashion with more than 2 storage nodes, you will need to have a direct
-connection between each storage node and every other storage node in the
-same node group.
+in this fashion with more than 2 data nodes, you will need to have a direct
+connection between each data node and every other data node in the same node
+group.
@node MySQL Cluster SHM Definition, MySQL Cluster SCI Definition, MySQL Cluster Direct TCP Definition, MySQL Cluster Config File
@subsubsection MySQL Cluster Shared-Memory Connections
@@ -74556,10 +74553,10 @@
Given this information, the MySQL server will be a full participant in the
cluster. (We sometimes refer to a @command{mysqld} process running in this
-manner as an SQL node.) It will be fully aware of all cluster storage nodes
-as well as their status, and will establish connections to all storage nodes. In
-this case, is able to use any storage node as a transaction coordinator and
-to access storage node data for reading and updating.
+manner as an SQL node.) It will be fully aware of all cluster data nodes as well
+as their status, and will establish connections to all data nodes. In this case,
+it is able to use any data node as a transaction coordinator and to access
+node data for reading and updating.
@node ndbd process, ndb_mgmd process, mysqld process, MySQL Cluster Process Management
@@ -74572,7 +74569,7 @@
In a MySQL Cluster, a set of @command{ndbd} processes co-operate in handling
data. These processes can execute on the same computer (host) or on different
-computers. The correspondences between storage nodes and Cluster hosts is
+computers. The correspondences between data nodes and Cluster hosts is
completely configurable.
@c TODO: Insert figure here?
@@ -74969,7 +74966,7 @@
The management client has the following basic commands.
In the listing that follows, @var{<id>} denotes either a database node ID or the
keyword @code{ALL}, which indicates that the command should be applied to all
-of the cluster's storage nodes.
+of the cluster's data nodes.
@table @code
@@ -74980,17 +74977,17 @@
Displays information on the cluster's status.
@item @var{<id>} START
-Starts the storage node identified by @var{<id>} (or all storage nodes).
+Starts the data node identified by @var{<id>} (or all data nodes).
@item @var{<id>} STOP
-Stops the storage node identified by @var{<id>} (or all storage nodes).
+Stops the data node identified by @var{<id>} (or all data nodes).
@item @var{<id>} RESTART [-N] [-I]
-Restarts the storage node identified by @var{<id>} (or all storage nodes).
+Restarts the data node identified by @var{<id>} (or all data nodes).
@item @var{<id>} STATUS
-Displays status information for the storage node identified by @var{<id>} (or
-all storage nodes).
+Displays status information for the data node identified by @var{<id>} (or for
+all data nodes).
@item ENTER SINGLE USER MODE @var{<id>}
Enters single-user mode, whereby only the MySQL server identified by the node ID
@@ -75020,11 +75017,11 @@
MySQL Cluster provides two types of event log. These are the @strong{cluster
log}, which includes events generated by all cluster nodes, and @strong{node
-logs}, which are local to each storage node.
+logs}, which are local to each data node.
Output generated by cluster event logging can have multiple destinations
including a file, the management server console window, or @code{syslog}. Output
-generated by node event logging is written to the storage node's console window.
+generated by node event logging is written to the data node's console window.
Both sorts of event logs can be set to log different subsets of events.
@@ -75085,16 +75082,15 @@
@end table
-The following table describes the default setting (for all storage nodes) of
-the cluster log category threshold. If an event has a priority with a value
-lower than or equal to the priority threshold, then it is reported in the
-cluster log.
+The following table describes the default setting (for all data nodes) of the
+cluster log category threshold. If an event has a priority with a value lower
+than or equal to the priority threshold, then it is reported in the cluster log.
-Note that events are reported per storage node, and that the threshold can be
-set to different values on different nodes.
+Note that events are reported per data node, and that the threshold can be set
+to different values on different nodes.
@multitable @columnfractions .30 .70
-@item @strong{Category} @tab @strong{Default threshold (All storage nodes)}
+@item @strong{Category} @tab @strong{Default threshold (All data nodes)}
@item @code{STARTUP} @tab @strong{7}
@item @code{SHUTDOWN} @tab @strong{7}
@item @code{STATISTICS} @tab @strong{7}
@@ -75158,11 +75154,11 @@
@item @strong{Event} @tab @strong{Priority} @tab @strong{Severity Level}
@tab @strong{Description}
-@item DB nodes connected @tab 8 @tab INFO @tab Storage nodes connected
-@item DB nodes disconnected @tab 8 @tab INFO @tab Storage nodes disconnected
-@item Communication closed @tab 8 @tab INFO @tab SQL or storage node
+@item DB nodes connected @tab 8 @tab INFO @tab Data nodes connected
+@item DB nodes disconnected @tab 8 @tab INFO @tab Data nodes disconnected
+@item Communication closed @tab 8 @tab INFO @tab SQL node or data node
connection closed
-@item Communication opened @tab 8 @tab INFO @tab SQL or storage node
+@item Communication opened @tab 8 @tab INFO @tab SQL node or data node
connection opened
@end multitable
@@ -75228,10 +75224,10 @@
establish communication, or other problem
@item DB node neighbours @tab 8 @tab INFO
-@tab Shows neighbouring storage nodes
+@tab Shows neighbouring data nodes
@item DB node start phase @var{X} completed @tab 4 @tab INFO
-@tab A storage node start phase has been completed
+@tab A data node start phase has been completed
@item Node has been successfully included into the cluster @tab 3 @tab INFO
@tab Displays the node, managing node, and dynamic ID
@@ -75243,10 +75239,10 @@
@tab NDB Cluster nodes started
@item DB node shutdown initiated @tab 1 @tab INFO
-@tab Shutdown of storage node has commenced
+@tab Shutdown of data node has commenced
@item DB node shutdown aborted @tab 1 @tab INFO
-@tab Unable to shut down storage node normally
+@tab Unable to shut down data node normally
@end multitable
@@ -75413,7 +75409,7 @@
be restarted.
The command @command{EXIT SINGLE USER MODE} changes the state of the cluster's
-storage nodes from single user mode to normal mode. MySQL Servers waiting for a
+data nodes from single user mode to normal mode. MySQL Servers waiting for a
connection (that is, for the cluster to become ready and available), are now
allowed to connect. The MySQL Server denoted as the single-user SQL node
continues to run (if it is connected), during and after the state change.
@@ -75435,7 +75431,7 @@
@item Issue the @command{EXIT SINGLE USER MODE} command
- @item Restart the cluster's storage nodes
+ @item Restart the cluster's data nodes
@end enumerate
@@ -75780,8 +75776,8 @@
routing indexes to all nodes. However, this requires only 100 milliseconds or so
to complete and should be acceptable for most high-availability cases.
-By placing cluster storage nodes properly within the switched architecture, it
-is possible to use 2 switches to build a structure whereby 16 computers can be
+By placing cluster data nodes properly within the switched architecture, it is
+possible to use 2 switches to build a structure whereby 16 computers can be
interconnected and no single failure can hinder more than one computer. With 32
computers and 2 switches it is possible to configure the cluster in such a
manner that no single failure can cause the loss of more than two nodes; in this
@@ -75973,8 +75969,8 @@
are for small accesses of 20 records per access. The difference between serial
and batched access decreases by a factor of 3 to 4 when using 2 kB records
instead. SCI Sockets were not tested with 2 kB records. Tests were performed on
-a cluster with 2 storage nodes running on 2 dual-CPU machines equipped with
-AMD MP1900+ processors.
+a cluster with 2 data nodes running on 2 dual-CPU machines equipped with AMD
+MP1900+ processors.
@example
Access type: TCP/IP sockets SCI Socket
@@ -76143,16 +76139,19 @@
InnoDB):
@itemize @asis
@item All machines used in the cluster must have the same architecture; that
- is, all machines hosting nodes must be either big-endian or
- little-endian, and you cannot use a mixture of both. For example, you cannot
- have a management node running on a PPC which directs a storage node that is
- running on an x86 machine. This restriction does not apply to machines simply
- running @command{mysql} or other clients that may be accessing the cluster's
- SQL nodes.
- @item It is not possible to make online schema changes such as
- those accomplished using @code{ALTER TABLE} or @code{CREATE INDEX}. (However,
- you can import or create a table that uses a different storage engine, then
- convert it to NDB using @code{ALTER TABLE @var{tbl_name} ENGINE=NDBCLUSTER;}.)
+ is, all machines hosting nodes must be either big-endian or little-endian, and
+ you cannot use a mixture of both. For example, you cannot have a management
+ node running on a PPC which directs a data node that is running on an x86
+ machine. This restriction does not apply to machines simply running
+ @command{mysql} or other clients that may be accessing the cluster's SQL
+ nodes.
+ @item It is not possible to make online schema changes such as those
+ accomplished using @code{ALTER TABLE} or @code{CREATE INDEX}, as the NDB
+ Cluster does not support autodiscovery of such changes. (However, you can
+ import or create a table that uses a different storage engine, then convert it
+ to NDB using @code{ALTER TABLE @var{tbl_name} ENGINE=NDBCLUSTER;}. In such a
+ case, you will need to issue a @code{FLUSH TABLES} command to force the
+ cluster to pick up the change.)
@item Online adding or dropping nodes is not possible (the cluster must be
restarted in such cases).
@item When using multiple management servers one must give nodes explicit IDs
@@ -76161,9 +76160,9 @@
@item When using multiple management servers one must take extreme care to
have the same configurations for all management servers. No special checks for
this are performed by the cluster.
- @item The maximum number of storage nodes is 48.
+ @item The maximum number of data nodes is 48.
@item The total maximum number of nodes in a MySQL Cluster is 63. This number
- includes all MySQL Servers (SQL nodes), storage nodes, and management servers.
+ includes all MySQL Servers (SQL nodes), data nodes, and management servers.
@end itemize
@end itemize
@@ -76241,7 +76240,7 @@
A major benefit of this change is that queries are now executed in parallel.
This means that queries against non-indexed columns can run as much as 5 to 10
-times, @emph{times the number of storage nodes}, faster than previously, since
+times, @emph{times the number of data nodes}, faster than previously, since
multiple CPUs can work on the query in parallel.
@item
@@ -76348,14 +76347,13 @@
In a replication setup, a master MySQL server updates one or more slaves.
Transactions are committed sequentially, and a slow transaction can cause the
slave to lag behind the master. This means that if the master fails, it is
-possible that the slave might not have recorded the last few transactions.
-If a transaction-safe engine such as InnoDB is being used, then a transaction
-will either be complete on the slave or not applied at all, but replication does
-not guarantee that all data on the master and the slave will be consistent at
-all times. In MySQL Cluster, all storage nodes are kept in synch, and a
-transaction committed by any one storage node is committed for all storage
-nodes. In the event of a storage node failure, all remaining storage nodes will
-remain in a consistent state.
+possible that the slave might not have recorded the last few transactions. If a
+transaction-safe engine such as InnoDB is being used, then a transaction will
+either be complete on the slave or not applied at all, but replication does not
+guarantee that all data on the master and the slave will be consistent at all
+times. In MySQL Cluster, all data nodes are kept in synch, and a transaction
+committed by any one data node is committed for all data nodes. In the event of
+a data node failure, all remaining data nodes will remain in a consistent state.
In short, whereas MySQL replication is asynchronous, MySQL Cluster is
synchronous.
@@ -76379,20 +76377,20 @@
A minimum of three computers is required to run a viable cluster. However, the
minimum @strong{recommended} number of computers in a MySQL Cluster is four: one
each to run the management and SQL nodes, and two computers to serve as storage
-nodes. The purpose of the two storage nodes is to provide redundancy; the
+nodes. The purpose of the two data nodes is to provide redundancy; the
management node must run on a separate machine in order to guarantee continued
-arbitration services in the event that one of the storage nodes fails.
+arbitration services in the event that one of the data nodes fails.
@item
@emph{What do the different computers do in a cluster?}
A MySQL Cluster has both a physical and logical organization, with computers
-being the physical elements. The logical or functional elements of
-a cluster are referred to as @strong{nodes}, and a computer housing a cluster
-node is sometimes referred to as a @strong{cluster host}. Ideally, there will
-be one node per cluster host, although it is possible to run multiple nodes on a
-single host. There are three types of nodes, each corresponding to a
-specific role within the cluster. These are:
+being the physical elements. The logical or functional elements of a cluster are
+referred to as @strong{nodes}, and a computer housing a cluster node is
+sometimes referred to as a @strong{cluster host}. Ideally, there will be one
+node per cluster host, although it is possible to run multiple nodes on a single
+host. There are three types of nodes, each corresponding to a specific role
+within the cluster. These are:
@enumerate
@@ -76404,9 +76402,8 @@
Cluster via the MGM node is @command{ndb_mgm}.
@item
- @strong{storage node (data node)}: Stores and replicates data. Storage node
- functionality is handled by an instance of the NDB storage node
- process @command{ndbd}.
+ @strong{data node}: Stores and replicates data. Data node functionality is
+ handled by an instance of the NDB data node process @command{ndbd}.
@item
@strong{SQL node}: This is simply an instance of MySQL Server
@@ -76419,15 +76416,14 @@
@item
@emph{With which operating systems can I use Cluster?}
-As of MySQL 4.1.10, MySQL Cluster is officially supported on Linux, Mac OS X,
+As of MySQL 4.1.12, MySQL Cluster is officially supported on Linux, Mac OS X,
and Solaris. We are working to add Cluster support for other platforms,
-including Windows (Windows support expected in MySQL 5.0), and our goal is
-eventually to offer Cluster on all platforms for which MySQL itself is
-supported.
+including Windows (expected in MySQL 5.0), and our goal is eventually to offer
+MySQL Cluster on all platforms for which MySQL itself is supported.
It may be possible to run Cluster processes on other operating systems
-(including Windows), but Cluster on any but the three mentioned here should be
-considered alpha software and not for production use.
+(including Windows), but Cluster on any but the three platforms mentioned here
+should be considered alpha software only and not for production use.
@item
@emph{What are the hardware requirements for running MySQL Cluster?}
@@ -76435,10 +76431,10 @@
Cluster should run on any platform for which NDB-enabled binaries are
available. Naturally, faster CPUs and more memory will improve performance, and
64-bit CPUs will likely be more effective than 32-bit processors. There must be
-sufficent memory on machines used for storage nodes to hold each node's share of
-the database (see @strong{How much RAM does Cluster require?} for more info).
-Nodes can communicate via a standard TCP/IP network and hardware. For SCI
-support, special networking hardware is required.
+sufficent memory on machines used for data nodes to hold each node's share of
+the database (see @strong{How much RAM do I Need?} for more info). Nodes can
+communicate via a standard TCP/IP network and hardware. For SCI support, special
+networking hardware is required.
@c Ref: SCI, Fragments, Replicas
@@ -76456,7 +76452,8 @@
conditions, as MySQL Cluster was designed and implemented with the assumption
that it would be run under conditions guaranteeing dedicated high-speed
connectivity such as that found in a LAN setting using 100 Mbps or gigabit
-Ethernet. We neither test nor warrant its performance using anything slower.
+Ethernet. We neither test nor warrant its performance using anything slower than
+this.
@item
@emph{Do I have to learn a new programming or query language to use Cluster?}
@@ -76544,11 +76541,11 @@
system and any applications running on the cluster computers.
You can use the following formula for obtaining a rough estimate of how much
-RAM is needed for each storage node in the cluster:
+RAM is needed for each data node in the cluster:
@example
-(SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfStorageNodes
+(SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfDataNodes
@end example
@@ -76604,12 +76601,12 @@
provide sufficient RAM for all table data and all indexes, @emph{including the
primary key required by NDB}.
-It is also worth noting that all storage nodes should have the same amount of
-RAM, as no storage node in a cluster can use more memory than the least amount
-available to any individual storage node. In other words, if there are three
-computers hosting Cluster storage nodes, with two of these having three
-gigabytes of RAM available to store Cluster data, and one having only one GB
-RAM, then each storage node can devote only one GB for Cluster.
+It is also worth noting that all data nodes should have the same amount of RAM,
+as no data node in a cluster can use more memory than the least amount available
+to any individual data node. In other words, if there are three computers
+hosting Cluster data nodes, with two of these having three gigabytes of RAM
+available to store Cluster data, and one having only one GB RAM, then each data
+node can devote only one GB to clustering.
@item
@emph{In the event of a catstrophic failure --- say, for instance, the whole
@@ -76644,9 +76641,9 @@
@item
@emph{Can I add nodes to a cluster without restarting it?}
-Not at present. A simple restart is all that is required for adding new MGM
-or SQL nodes to a Cluster. When adding storage nodes the process is more complex
-and requires the following steps:
+Not at present. A simple restart is all that is required for adding new MGM or
+SQL nodes to a Cluster. When adding data nodes the process is more complex, and
+requires the following steps:
@itemize @bullet
@@ -76665,7 +76662,7 @@
@end itemize
In future, we hope to implement "hot" reconfiguration capability for MySQL
-Cluster in order to minimize if not eliminate requirements for restarting the
+Cluster in order to minimize (if not eliminate) requirements for restarting the
cluster when adding new nodes.
@item
@@ -76797,7 +76794,7 @@
Start the management node with the @command{ndb_mgmd} command.
@item
- Start each storage node with the @command{ndbd} command.
+ Start each data node with the @command{ndbd} command.
@item
Start each MySQL server (SQL node) using @command{mysqld_safe --user=mysql &}.
@@ -76811,8 +76808,8 @@
@item
@emph{What happens to cluster data when the cluster is shut down?}
-The data held in memory by the cluster's storage nodes is written to disk, and
-is reloaded in memory the next time that the cluster is started.
+The data held in memory by the cluster's data nodes is written to disk, and is
+reloaded in memory the next time that the cluster is started.
To shut down the cluster, enter the following in a shell on the machine hosting
the MGM node:
@@ -76847,12 +76844,12 @@
be done only as part of a rolling upgrade procedure.
@item
-@emph{Can I run two storage nodes on a single host? Two SQL nodes?}
+@emph{Can I run two data nodes on a single host? Two SQL nodes?}
-Yes, it is possible to do this. In the case of multiple storage nodes, each
-node must use a different data directory. If you want to run multiple SQL nodes
-on one machine, then each instance of @command{mysqld} must use a different
-TCP/IP port.
+Yes, it is possible to do this. In the case of multiple stdata nodes, each node
+must use a different data directory. If you want to run multiple SQL nodes on
+one machine, then each instance of @command{mysqld} must use a different TCP/IP
+port.
@item
@emph{Can I use hostnames with MySQL Cluster?}
@@ -76948,20 +76945,20 @@
restores from them, and so forth.
@item @strong{SQL (MySQL server) nodes}: Instances of MySQL Server which
- serve as front ends to data kept in the cluster's @strong{storage nodes}.
+ serve as front ends to data kept in the cluster's @strong{data nodes}.
Clients desiring to store, retrieve, or update data can access an SQL node
just as they would any other MySQL Server, employing the usual
authentication methods and API's; the underlying distribution of data
between node groups is transparent to users and applications. SQL nodes
access the cluster's databases as a whole without regard to the data's
- distribution across different storage nodes or cluster hosts.
+ distribution across different data nodes or cluster hosts.
- @item @strong{Data nodes} (also referred to as @strong{storage nodes}):
- These nodes store the actual data. Table data fragments are stored in a
- set of node groups; each node group stores a different subset of the table
- data. Each of the nodes making up a node group stores a replica of the
- fragment for which that node group is responsible. Currently a single
- cluster can support a total of up to 48 data nodes.
+ @item @strong{Data nodes}: These nodes store the actual data. Table data
+ fragments are stored in a set of node groups; each node group stores a
+ different subset of the table data. Each of the nodes making up a node
+ group stores a replica of the fragment for which that node group is
+ responsible. Currently a single cluster can support up to 48 data nodes
+ total.
@end itemize
@@ -77010,8 +77007,8 @@
facilitate load balancing between machines and nodes.
@item @strong{Replica}: Under the NDB storage engine, each table fragment has
- number of replicas stored on other storage nodes in order to provide
- redundancy. Currently there may be up 4 replicas per fragment.
+ number of replicas stored on other data nodes in order to provide redundancy.
+ Currently there may be up 4 replicas per fragment.
@item @strong{Transporter}: A protocol providing data transfer between nodes.
MySQL Cluster currently supports 4 different types of transporter connections:
@@ -117754,33 +117751,33 @@
Functionality added or changed:
@itemize @bullet
@item
-Many queries in MySQL Cluster are executed as range scans or full
-table scans. All queries that don't use a unique hash index or the
-primary hash index use this access method. In a distributed
-system it is crucial that batching is properly performed.
-
-In previous version the batch size was fixed to 16 per storage node.
-In this version it is configurable per MySQL Server. So for queries
-using lots of large scans it is appropriate to set this parameter
-rather large and for queries using lots of small scans only fetching
-a small amount of records it is appropriate to set it low.
-
-The performance of queries can easily change as much as 40% based on
-how this variable is set.
-
-In future versions more logic will be made to assess the batch size
-on per query basis. Thus the semantics of this new configuration
-variable @code{ScanBatchSize} is likely to change.
-
-@item
-The fixed size overhead of the ndbd process was greatly decreased. Also
-overhead per operation record was greatly decreased and also overhead
-per table and index was greatly decreased.
-
-A number of new configuration variables was introduced to be able to
-configure more buffers in the system. Configuration variables to
-specify the number of tables, unique hash indexes and ordered indexes
-was introduced as well.
+Many queries in MySQL Cluster are executed as range scans or full table scans.
+All queries that don't use a unique hash index or the primary hash index use
+this access method. In a distributed system it is crucial that batching is
+properly performed.
+
+In previous versions, the batch size was fixed to 16 per data node. In this
+version it is configurable per MySQL Server. So for queries using lots of large
+scans it is appropriate to set this parameter rather large and for queries using
+many small scans only fetching a small amount of records it is appropriate to
+set it low.
+
+The performance of queries can easily change as much as 40% based on how this
+variable is set.
+
+In future versions more logic will be implemented for assessing the batch size
+on a per-query basis. Thus, the semantics of the new configuration variable
+@code{ScanBatchSize} are likely to change.
+
+@item
+The fixed size overhead of the ndbd process has been greatly decreased. This is
+also true for the overhead per operation record as well as overhead per table
+and index.
+
+A number of new configuration variables have been introduced to enable
+configuration of system buffers. Configuration variables for specifying the
+numbers of tables, unique hash indexes, and ordered indexes have also been
+introduced.
New configuration variables:
@code{MaxNoOfOrderedIndexes}, @code{MaxNoOfUniqueHashIndexes}
@@ -117790,20 +117787,19 @@
@item
In previous versions @code{ALTER TABLE}, @code{TRUNCATE TABLE}, and @code{LOAD
-DATA} were performed as one big transaction. In this version, all those
-statements are automatically separated into a number of transactions.
+DATA} were performed as one big transaction. In this version, all of these
+statements are automatically separated into several distinct transactions.
-This removes the limitation that one could not change very large tables
-due to the @code{MaxNoOfConcurrentOperations} parameter.
+This removes the limitation that one could not change very large tables due to
+the @code{MaxNoOfConcurrentOperations} parameter.
@item
-The online backup feature of MySQL Cluster now also backs up the
-indexes such that the restore ensures that both data and indexes are
-restored.
+MySQL CLuster's online backup feature now backs up indexes so that both data and
+indexes are restored.
@item
In previous versions it was not possible to use @code{NULL} in indexes. This
-is now possible in all indexes.
+is now possible for all supported index types.
@item
Much work has been put onto making @code{AUTO_INCREMENT} features work as for
@@ -117811,22 +117807,21 @@
supported by @code{MyISAM}.
@item
-In previous version,s @command{mysqld} would crash if the cluster wasn't
-started and the @code{--ndbcluster} option was used. Now @command{mysqld}
- handles cluster crashes and starts without crashing.
-
-@item
-The @code{-i} option for initial startup has been removed from
-@command{ndbd}. Initial startup still can be specified by using the
-@code{--initial} option. The reason is to ensure that it is clearer what
-takes place when using the @code{--initial} option. This option completely
-removes all data from the disk and should only be used at initial start, in
-certain software upgrade cases, and in some cases when node restarts don't
-work as a workaround.
+In earlier versions, @command{mysqld} would crash if the cluster wasn't started
+with the @code{--ndbcluster} option. Now @command{mysqld} handles cluster
+crashes and starts without crashing.
+
+@item
+The @code{-i} option for initial startup of @command{ndbd} has been removed.
+Initial startup still can be specified by using the @code{--initial} option. The
+reason for this is to ensure that it is clear what takes place when using
+@code{--initial}: this option completely removes all data from the disk and
+should only be used at initial start, in certain software upgrade cases, and in
+some cases as a workaround when nodes cannot be restarted successfully.
@item
-The management client (@command{ndb_mgm}) now has more commands and more
-information is printed in some commands such as @code{show}.
+The management client (@command{ndb_mgm}) now has additional commands and more
+information is printed for some commands such as @code{show}.
@item
In previous versions, the files were called @file{ndb_0..} when it wasn't
@@ -117835,58 +117830,55 @@
named @file{ndb_pid..}, where pid is the process ID assigned by the OS.
@item
-The default parameters have changed for @command{ndb_mgmd} and
-@command{ndbd}. In particular, they are now started as daemons by default.
-The @code{-n} option was removed since it could confusion as to whether its
-meaning is nostart or nodaemon.
+The default parameters have changed for @command{ndb_mgmd} and @command{ndbd}.
+In particular, they are now started as daemons by default. The @code{-n} option
+has been removed since it could cause confusion as to its meaning (nostart or
+nodaemon).
@item
In the configuration file, you can now use @code{[NDBD]} as an alias for
@code{[DB]}, @code{[MYSQLD]} as an alias for @code{[API]}, and
-@code{[NDB_MGMD]} as an alias for @code{[MGM]}. @strong{Note}: @code{[NDBD]},
-@code{[MYSQLD]}, and @code{[NDB_MGMD]} are now the preferred designations,
-although the older ones will continue to be supported for some time in order to
-provide backwards compatibility.
+@code{[NDB_MGMD]} as an alias for @code{[MGM]}. @strong{Note}: In fact,
+@code{[NDBD]}, @code{[MYSQLD]}, and @code{[NDB_MGMD]} are now the preferred
+designations, although the older ones will continue to be supported for some
+time to come in order to maintain backwards compatibility.
@item
-Many more checks of the consistency of the configuration have been
-introduced to provide quicker feedback on configuration errors.
+Many more checks for consistency in configuration have been introduced to in
+order to provide quicker feedback on configuration errors.
@item
In the connect string, it is now possible to use both @samp{;} and @samp{,}
-as the separator between entries. So "nodeid=2,host=localhost:2200" is
+as the separator between entries. Thus, "nodeid=2,host=localhost:2200" is
equivalent to "nodeid=2;host=localhost:2200".
-In the configuration, it is possible to use @samp{:} or @samp{=} as the
-assignment symbol. Thus @code{MaxNoOfOrderedIndexes : 128} and
-@code{MaxNoOfOrderedIndexes = 128} are equivalent.
+In the configuration file, it is also possible to use @samp{:} or @samp{=} for
+assignment values. For example, @code{MaxNoOfOrderedIndexes : 128} and
+@code{MaxNoOfOrderedIndexes = 128} are equivalent expressions.
@item
-The configuration variable names are now case insensitive so
-@code{MaxNoOfOrderedIndexes: 128}
-is equivalent to
+The configuration variable names are now case insensitive, so
+@code{MaxNoOfOrderedIndexes: 128} is equivalent to
@code{MAXNOOFORDEREDINDEXES = 128}.
@item
It is possible now to set the backup directory separately from the
-@code{FileSystemPath} by using the @code{BackupDir} config variable.
+@code{FileSystemPath} by using the @code{BackupDir} configuration variable.
-Log files and trace files can now be put in any directory by setting
-the @code{DataDir} configuration variable.
+Log files and trace files can now be placed in any directory by setting the
+@code{DataDir} configuration variable.
@code{FileSystemPath} is no longer mandatory and defaults to @code{DataDir}.
@item
-It is now supported to perform queries involving tables from different
-databases in MySQL.
+Queries involving tables from different databases are now supported.
@item
It is now possible to update the primary key.
@item
-The performance of the ordered index has been greatly improved,
-particularly the maintenance of the index at updates, inserts and
-deletes.
+The performance of ordered indexes has been greatly improved, particularly the
+maintenance of indexes on updates, inserts and deletes.
@end itemize
@@ -117922,9 +117914,9 @@
Functionality added or changed:
@itemize @bullet
@item
-This was the first MySQL Cluster release in 5.0. Actually almost all
-attention was on getting 4.1 stable so it is not recommended to use
-MySQL 5.0.1 for MySQL Cluster usage.
+This was the first MySQL Cluster release in the 5.0 series. As nearly all
+attention was still focused on getting 4.1 stable, it is not recommended to use
+MySQL 5.0.1 for MySQL Cluster.
@end itemize
Bugs fixed:
@@ -117938,8 +117930,7 @@
Functionality added or changed:
@itemize @bullet
@item
-This was the first MySQL Cluster release so all the functionality was
-new.
+This was the first MySQL Cluster release so all functionality was new.
@end itemize
Bugs fixed:
| Thread |
|---|
| • bk commit - mysqldoc@docsrva tree (jon:1.2673) | jon | 17 May |
