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

[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.2656 05/05/12 08:45:59 paul@stripped +1 -0
  manual.texi:
    Minor tweaks.

  Docs/manual.texi
    1.2844 05/05/12 08:45:48 paul@stripped +12 -12
    Minor tweaks.

# 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

--- 1.2843/Docs/manual.texi	2005-05-12 07:13:43 -05:00
+++ 1.2844/Docs/manual.texi	2005-05-12 08:45:48 -05:00
@@ -32776,7 +32776,7 @@
 slave with this option before you make the slave read its own events which you
 want the slave SQL thread to execute.
 
-@item --report-host=@var{host}
+@item --report-host=@var{slave_name}
 The hostname or IP number of the slave to be reported to the master during
 slave registration. This value appears in the output of @code{SHOW SLAVE
 HOSTS} on the master server. Leave the value unset if you do not want the
@@ -32785,17 +32785,17 @@
 after the slave connects. Due to @code{NAT} and other routing issues, that IP
 may not be valid for connecting to the slave from the master or other hosts.
 
-@c For
-@c the moment, this option is of no real interest; it is meant for failover
+@c For the moment, this option is of no real interest; it is meant for failover
 @c replication, which is not implemented yet.
 
 This option is available as of MySQL 4.0.0.
 
-@item --report-port=@var{port_number}
-The TCP/IP port for connecting to the slave, to be reported to the
+@item --report-port=@var{slave_port}
+The TCP/IP port number for connecting to the slave, to be reported to the
 master during slave registration.  Set it only if the slave is listening
 on a non-default port or if you have a special tunnel from the master or
 other clients to the slave. If you are not sure, leave this option unset.
+
 @c For the moment, this option is of no real interest; it is meant for failover
 @c replication, which is not implemented yet.
 
@@ -63957,7 +63957,7 @@
 @end example
 
 Displays a list of slaves currently registered with the master.
-Any slave not started with the @code{--report-host=slave_name}
+Any slave not started with the @code{--report-host=@var{slave_name}}
 option is not visible in that list.
 @c end_description_for_help_topic
 
@@ -70801,7 +70801,7 @@
 A symptom of fragmentation is that a table takes more space than it 'should
 take'. How much exactly is that, is difficult to determine. All InnoDB data
 and indexes are stored in B-trees, and their fillfactor may vary
-50 % - 100 %. Another symptom of fragmentation is that a table scan:
+50 % to 100 %. Another symptom of fragmentation is that a table scan:
 @example
 SELECT COUNT(*) FROM t WHERE a_non_indexed_column <> 12345;
 @end example
@@ -72943,7 +72943,7 @@
 @table @code
 @item [NDB_MGMD]Id
 Each node in the cluster has a unique identity, which is represented by an
-integer value in the range 1 - 63 inclusive. This ID is used by all internal
+integer value in the range 1 to 63 inclusive. This ID is used by all internal
 cluster messages for addressing the node.
 
 @item [NDB_MGMD]ExecuteOnComputer
@@ -74929,7 +74929,7 @@
   @code{CONNECTION}, @code{ERROR}, or @code{INFO}.
 
   @item
-  @emph{Priority}: This is represented by a number 1 - 15 inclusive, where 1
+  @emph{Priority}: This is represented by a number 1 to 15 inclusive, where 1
   indicates "most important" and 15 "least important".
 
   @item
@@ -75472,7 +75472,7 @@
 than it was created from. For example, suppose that a backup with backup ID
 @strong{12}, created in a cluster with two database nodes having the node IDs
 @strong{2} and @strong{3} is to be restored to a cluster with four nodes. Then
-@command{ndb_restore} must be run twice - once for each database node in the
+@command{ndb_restore} must be run twice --- once for each database node in the
 cluster where the backup was taken.
 
 @strong{Note}: For rapid restoration, the data may be restored in parallel,
@@ -76479,8 +76479,8 @@
 RAM, then each storage node can devote only one GB for Cluster.
 
 @item
-@emph{In the event of a catstrophic failure - say, for instance, the whole city
-lost power AND my UPS failed - would I lose all my data?}
+@emph{In the event of a catstrophic failure --- say, for instance, the whole
+city lost power AND my UPS failed --- would I lose all my data?}
 
 All committed transactions are logged. Therefore, while it is possible that some
 data could be lost in the event of a catastrophe, this should be quite limited.