bk commit - mysqldoc@docsrva tree (paul:1.2654)

[paul]

Below is the list of changes that have just been committed into a local
mysqldoc repository of paul. When paul 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.2654 05/05/12 07:05:49 paul@stripped +1 -0
  Merge bk://mysqldoc@stripped
  into frost.snake.net:/Volumes/frost2/MySQL/bk/mysqldoc

  Docs/manual.texi
    1.2842 05/05/12 07:05:42 paul@stripped +0 -0
    Auto merged

# 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:	paul
# Host:	frost.snake.net
# Root:	/Volumes/frost2/MySQL/bk/mysqldoc/RESYNC

--- 1.2841/Docs/manual.texi	2005-05-11 22:15:19 -05:00
+++ 1.2842/Docs/manual.texi	2005-05-12 07:05:42 -05:00
@@ -68397,47 +68397,56 @@
 table that has some matching rows in the child table is dependent on 
 the @emph{referential action} specified using @code{ON UPDATE} and
 @code{ON DETETE} subclauses of the @code{FOREIGN KEY} clause. When
-the user attempts to delete a row from a parnt table, and there
+the user attempts to delete or update a row from a parent table, and there
 are one or more matching rows in the child table, @code{InnoDB}
 supports five options regarding the action to be taken:
 
 @itemize @bullet
 
-@item @code{CASCADE}: Delete the row from the parent table and
-automatically delete the matching rows in the child table. 
+@item @code{CASCADE}: Delete or update the row from the parent table and
+automatically delete or update the matching rows in the child table. 
 @code{ON DELETE CASCADE} is available starting from MySQL 3.23.50
 and @code{ON UPDATE CASCADE} is available starting from 4.0.8.
 
-@item @code{SET NULL}: Delete the row from the parent table and
+@item @code{SET NULL}: Delete or update the row from the parent table and
 set the foreign key column(s) in the child table to @code{NULL}.
 This is only valid if the foreign key columns do not have the
-@code{NOT NULL} qualifier specified. @code{ON DELETE CASCADE} 
-is available starting from MySQL 3.23.50 and @code{ON UPDATE CASCADE} 
+@code{NOT NULL} qualifier specified. @code{ON DELETE SET NULL} 
+is available starting from MySQL 3.23.50 and @code{ON UPDATE SET NULL} 
 is available starting from 4.0.8.
 
 @item @code{SET DEFAULT}: @code{InnoDB} rejects table definitions 
-containing @code{ON DELETE SET DEFAULT} clauses.
+containing @code{ON DELETE SET DEFAULT} or @code{ON UPDATE SET DEFAULT}
+clauses.
 
 @item @code{NO ACTION}: In @code{ANSI SQL-92} standard, 
 @code{NO ACTION} means @emph{no action} in the sense that an attempt 
 to delete or update a primary key value will not be allowed to 
 proceed if there is a related foreign key value in the referenced 
 table (Gruber, Mastering SQL, 2000:181). Starting from 4.0.18
-@code{InnoDB} rejects the delete operation from the parent
+@code{InnoDB} rejects the delete or update operation for the parent
 table.
 
-@item @code{RESTRICT}: Rejects the delete operation from the
-parent table
+@item @code{RESTRICT}: Rejects the delete or update operation for the
+parent table. @code{NO ACTION} and @code{RESTRICT} are the same as 
+omitting the @code{ON DELETE} or @code{ON UPDATE} clause. 
+(Some database systems have deferred checks, and @code{NO ACTION} is a 
+deferred check. In MySQL, foreign key constraints are checked 
+immediately, so @code{NO ACTION} and @code{RESTRICT} are the same.)
 
 @end itemize
 
 @code{InnoDB} supports the same options when the candidate key in
-the parent table is update. With @code{CASCADE}, the foreign key 
+the parent table updated. With @code{CASCADE}, the foreign key 
 column(s) in the child table are set to new value(s) of the
 candidate key in the parent table. In the same way, the updates
 cascade if updated column(s) in the child table reference
 foreign keys in another table.
 
+Note that @code{InnoDB} supports foreign key references within a table
+and in these cases child table really means dependent records 
+within the table.
+
 @code{InnoDB} needs indexes on foreign keys and referenced keys so that
 foreign key checks can be fast and not require a table scan.  Starting with
 MySQL 4.1.2, these indexes are created automatically.  In older versions,
@@ -74131,16 +74140,18 @@
 @subsubsection MySQL Cluster TCP/IP Connections
 
 TCP/IP is the default transport mechanism for establishing connections in
-MySQL Cluster. It is actually not necessary to define connections because
+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.
+node and the management server. (For one exception to this rule, see
+@strong{MySQL Cluster TCP/IP Connections Using Crossover} later in this
+section.)
 
 It is only necessary to define a connection in order to override the default
 connection parameters. In that case it is necessary to define at least
 @var{NodeId1}, @var{NodeId2}, and the parameters to change.
 
-It is also possible to change the default values fro these parameters by setting
+It is also possible to change the default values for these parameters by setting
 them in the @code{[TCP DEFAULT]} section.
 
 @table @code
@@ -74180,6 +74191,55 @@
 socket. There is seldom any need to change this parameter from its default value
 of 64KB, except possibly in order to save memory.
 @end table
+
+@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.
+
+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:
+
+@example
+  # Management Server
+  [NDB_MGMD]
+  Id=1
+  HostName=172.23.72.20
+
+  # SQL Node
+  [MYSQLD]
+  Id=2
+  HostName=172.23.72.21
+
+  # Storage 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
+@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
+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.
 
 @node MySQL Cluster SHM Definition, MySQL Cluster SCI Definition, MySQL Cluster TCP
Definition, MySQL Cluster Config File
 @subsubsection MySQL Cluster Shared-Memory Connections