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.2482 05/02/08 15:33:28 jon@stripped +1 -0
More general edits/fixes for Cluster chapter.
Docs/manual.cluster.texi
1.17 05/02/08 15:33:26 jon@stripped +30 -35
More general edits/fixes.
# 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.16/Docs/manual.cluster.texi 2005-02-08 02:58:14 +10:00
+++ 1.17/Docs/manual.cluster.texi 2005-02-08 15:33:26 +10:00
@@ -1216,8 +1216,6 @@
@code{100k} means 10 * 1024 = 102400.) Parameters and values are currently
case-sensitive.
-@c *** END EDIT / JS / 2005-02-01 13.40 GMT ***
-
@table @code
@item [NBDB]Id
This is the node ID used as the address of the node for all cluster internal
@@ -1404,29 +1402,26 @@
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 it is dangerous to
-decrease them because that can easily lead to a node or even an entire Cluster
-that is unable to restart due to there being insufficient memory space.
+@code{DataMemory} and @code{IndexMemory} can be changed, but decreasing eith
+ of these can be risky; doing so can easily lead to a node or even an entire
+Cluster that is unable to restart due to there being insufficient memory space.
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
+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.
-@c <Whuh...?>
-
-@c More @code{IndexMemory} is not used due to updates but inserts are inserted
-@c immediately and deletes are not deleted until the transaction is committed.
-
-@c </Whuh...?>
+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.
The default value for @code{IndexMemory} is 18MB. The minimum is 1MB.
@end table
-The next three parameters are important because they affect the number of
-parallel transactions and the sizes of transactions that can be handled by the
-system. @code{MaxNoOfConcurrentTransactions} sets the number of parallel
-transactions possible in a node; @code{MaxNoOfConcurrentOperations} sets the
-number of records that can be in update phase or locked simultaneously.
+The next three parameters which we discuss are important because they affect the
+number of parallel transactions and the sizes of transactions that can be
+handled by the system. @code{MaxNoOfConcurrentTransactions} sets the number of
+parallel transactions possible in a node; @code{MaxNoOfConcurrentOperations}
+sets the number of records that can be in update phase or locked simultaneously.
Both of these parameters (especially @code{MaxNoOfConcurrentOperations}) are
likely targets for users setting specific values and not using the default
@@ -1437,25 +1432,25 @@
@item [NDBD]MaxNoOfConcurrentTransactions
For each active transaction in the cluster there must be a record in one of the
cluster nodes. The task of co-ordinating transactions is spread amongst the
-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.
-
-@c *** STOP POINT ***
-
-Actually transaction records are allocated to MySQL servers, normally there
-is at least one transaction record allocated in the cluster per connection
-that uses or have used a table in the cluster. Thus one should ensure that
-there is more transaction records in the cluster than there are concurrent
+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.
+
+Transaction records are allocated to individual MySQL servers. Normally there is
+at least one transaction record allocated per connection that using any
+table in the cluster. For this reason, one should ensure that there are more
+transaction records in the cluster than there are concurrent
connections to all MySQL servers in the cluster.
-This parameter has to be the same in all nodes in the cluster.
+This parameter must be set to the same value for all cluster nodes.
+
+@c What does the following really mean? If we shouldn't change this, then why
+@c is there an option to do so?
-Changing this parameter is never safe and can cause a cluster crash. When a
-node crashes one of the node (actually the oldest surviving node) will
-build up the transaction state of all transactions ongoing in the crashed
-node at the time of the crash. It is thus important that this node has as
-many transaction records as the failed node.
+Changing this parameter is never safe and can cause a cluster to crash. When a
+node crashes one of the node (actually the oldest surviving node) will build up
+the transaction state of all transactions ongoing in the crashed node at the
+time of the crash. It is thus important that this node has as many transaction
+records as the failed node.
The default value for this parameter is 4096.
@@ -1508,7 +1503,7 @@
about 1KB per record. This figure will shrink in future 5.x versions.
@item [DB]MaxNoOfLocalOperations
-By default this parameter is calculated as 1.1 *
+By default, this parameter is calculated as 1.1 *
@code{MaxNoOfConcurrentOperations}
which fits systems with many simultaneous, not very large transactions. If
the configuration needs to handle one very large transaction at a time and
| Thread |
|---|
| • bk commit - mysqldoc tree (jon:1.2482) | jon | 8 Feb |
