List:Commits« Previous MessageNext Message »
From:paul Date:January 29 2006 7:08pm
Subject:svn commit - mysqldoc@docsrva: r1105 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-29 20:08:40 +0100 (Sun, 29 Jan 2006)
New Revision: 1105

Log:
 r6862@frost:  paul | 2006-01-29 13:08:32 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/connector-j.xml
   trunk/refman-4.1/database-administration.xml
   trunk/refman-4.1/replication.xml
   trunk/refman-5.0/connector-j.xml
   trunk/refman-5.0/database-administration.xml
   trunk/refman-5.0/replication.xml
   trunk/refman-5.1/connector-j.xml
   trunk/refman-5.1/database-administration.xml
   trunk/refman-5.1/replication.xml


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6858
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6862
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588

Modified: trunk/refman-4.1/connector-j.xml
===================================================================
--- trunk/refman-4.1/connector-j.xml	2006-01-29 14:19:31 UTC (rev 1104)
+++ trunk/refman-4.1/connector-j.xml	2006-01-29 19:08:40 UTC (rev 1105)
@@ -4106,7 +4106,7 @@
 
     <!-- Don't use autoReconnect=true, it's going away eventually
          and it's a crutch for older connection pools that couldn't
-         test connections. You need to decide if your application is
+         test connections. You need to decide whether your application is
          supposed to deal with SQLExceptions (hint, it should), and
          how much of a performance penalty you're willing to pay
          to ensure 'freshness' of the connection -->

Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml	2006-01-29 14:19:31 UTC (rev 1104)
+++ trunk/refman-4.1/database-administration.xml	2006-01-29 19:08:40 UTC (rev 1105)
@@ -19720,14 +19720,7 @@
       <para>
         The error log file contains information indicating when
         <command>mysqld</command> was started and stopped and also any
-        critical errors that occur while the server is running.
-      </para>
-
-      <para>
-        If <command>mysqld</command> dies unexpectedly and
-        <command>mysqld_safe</command> needs to restart it,
-        <command>mysqld_safe</command> writes a <literal>restarted
-        mysqld</literal> message to the error log. If
+        critical errors that occur while the server is running. If
         <command>mysqld</command> notices a table that needs to be
         automatically checked or repaired, it writes a message to the
         error log.
@@ -19741,6 +19734,13 @@
       </para>
 
       <para>
+        If <command>mysqld</command> dies unexpectedly and
+        <command>mysqld_safe</command> needs to restart it,
+        <command>mysqld_safe</command> writes a <literal>restarted
+        mysqld</literal> message to the error log.
+      </para>
+
+      <para>
         Beginning with MySQL 4.0.10, you can specify where
         <command>mysqld</command> stores the error log file with the
         <option>--log-error[=<replaceable>file_name</replaceable>]</option>
@@ -19768,8 +19768,8 @@
       <para>
         If you do not specify <option>--log-error</option>, or (on
         Windows) if you use the <option>--console</option> option,
-        errors are written to stderr, the standard error output. Usually
-        this is your terminal.
+        errors are written to <literal>stderr</literal>, the standard
+        error output. Usually this is your terminal.
       </para>
 
       <para>
@@ -19829,8 +19829,8 @@
         the order that it receives them. This may be different from the
         order in which they are executed. This is in contrast to the
         update log and the binary log, which are written after the query
-        is executed, but before any locks are released. (The query log
-        also contains all statements, whereas the update and binary logs
+        is executed, but before any locks are released. (Also, the query
+        log contains all statements, whereas the update and binary logs
         do not contain statements that only select data.)
       </para>
 
@@ -19842,10 +19842,10 @@
       </para>
 
 <programlisting>
-shell&gt; <userinput>mv hostname.log hostname-old.log</userinput>
+shell&gt; <userinput>mv <replaceable>host_name</replaceable>.log <replaceable>host_name</replaceable>-old.log</userinput>
 shell&gt; <userinput>mysqladmin flush-logs</userinput>
-shell&gt; <userinput>cp hostname-old.log to-backup-directory</userinput>
-shell&gt; <userinput>rm hostname-old.log</userinput>
+shell&gt; <userinput>cp <replaceable>host_name</replaceable>-old.log <replaceable>backup-directory</replaceable></userinput>
+shell&gt; <userinput>rm <replaceable>host_name</replaceable>-old.log</userinput>
 </programlisting>
 
       <para>
@@ -19955,7 +19955,7 @@
         rows). Statements are stored in the form of
         <quote>events</quote> that describe the modifications. The
         binary log also contains information about how long each
-        statement took that updated the database.
+        statement took that updated data.
       </para>
 
       <para>
@@ -19977,18 +19977,14 @@
 
       <para>
         The primary purpose of the binary log is to be able to update
-        the database during a restore operation as fully as possible,
+        databases during a restore operation as fully as possible,
         because the binary log contains all updates done after a backup
-        was made.
+        was made. The binary log is also used on master replication
+        servers as a record of the statements to be sent to slave
+        servers. See <xref linkend="replication"/>.
       </para>
 
       <para>
-        The binary log is also used on master replication servers as a
-        record of the statements to be sent to slave servers. See
-        <xref linkend="replication"/>.
-      </para>
-
-      <para>
         Running the server with the binary log enabled makes performance
         about 1% slower. However, the benefits of the binary log for
         restore operations and in allowing you to set up replication
@@ -19997,39 +19993,41 @@
 
       <para>
         When started with the
-        <option>--log-bin[=<replaceable>file_name</replaceable>]</option>
+        <option>--log-bin[=<replaceable>base_name</replaceable>]</option>
         option, <command>mysqld</command> writes a log file containing
         all SQL commands that update data. If no
-        <replaceable>file_name</replaceable> value is given, the default
+        <replaceable>base_name</replaceable> value is given, the default
         name is the name of the host machine followed by
-        <literal>-bin</literal>. If file name is given, but it does not
-        contain a path, the file is written in the data directory. It is
-        recommended to specify a filename, see
+        <literal>-bin</literal>. If the basename is given, but not as an
+        absolute pathname, the server writes the file in the data
+        directory. It is recommended that you specify a basename; see
         <xref linkend="open-bugs"/>, for the reason.
       </para>
 
       <para>
         If you supply an extension in the log name (for example,
-        <option>--log-bin=<replaceable>file_name.extension</replaceable></option>),
+        <option>--log-bin=<replaceable>base_name.extension</replaceable></option>),
         the extension is silently removed and ignored.
       </para>
 
       <para>
         <command>mysqld</command> appends a numeric extension to the
-        binary log name. The number is incremented each time you start
-        the server or flush the logs. A new binary log also is created
-        automatically when the current log's size reaches
-        <literal>max_binlog_size</literal>. A binary log may become
+        binary log basename. The number increases each time the server
+        creates a new log file, thus creating an ordered series of
+        files. The server creates a new binary log file each time it
+        starts or flushes the logs. The server also creates a new binary
+        log file automatically when the current log's size reaches
+        <literal>max_binlog_size</literal>. A binary log file may become
         larger than <literal>max_binlog_size</literal> if you are using
-        large transactions: A transaction is written to the binary log
-        in one piece, never split between binary logs.
+        large transactions because a transaction is written to the file
+        in one piece, never split between files.
       </para>
 
       <para>
         To keep track of which binary log files have been used,
         <command>mysqld</command> also creates a binary log index file
         that contains the names of all used binary log files. By default
-        this has the same name as the binary log file, with the
+        this has the same basename as the binary log file, with the
         extension <literal>'.index'</literal>. You can change the name
         of the binary log index file with the
         <option>--log-bin-index[=<replaceable>file_name</replaceable>]</option>
@@ -20049,16 +20047,16 @@
 
       <para>
         You can delete all binary log files with the <literal>RESET
-        MASTER</literal> statement, or only some of them with
+        MASTER</literal> statement, or a subset of them with
         <literal>PURGE MASTER LOGS</literal>. See
         <xref linkend="reset"/>, and
         <xref linkend="replication-master-sql"/>.
       </para>
 
       <para>
-        The binary log format has some known limitations which can
-        affect recovery from backups, especially in old versions. These
-        caveats which also affect replication are listed at
+        The binary log format has some known limitations that can affect
+        recovery from backups, especially in old versions. These
+        caveats, which also affect replication, are listed at
         <xref linkend="replication-features"/>. One caveat which does
         not affect replication but only recovery with
         <literal>mysqlbinlog</literal>: before MySQL 4.1,
@@ -20076,6 +20074,14 @@
         discussion that follows this option list.
       </para>
 
+      <para>
+        If you are using replication, the options described here affect
+        which statements are sent by a master server to its slaves.
+        There are also options for slave servers that control which
+        statements received from the master to execute or ignore. For
+        details, see <xref linkend="replication-options"/>.
+      </para>
+
       <itemizedlist>
 
         <listitem>
@@ -20084,20 +20090,21 @@
           </para>
 
           <para>
-            Tells the master that it should log updates to the binary
-            log if the default database (that is, the one selected by
-            <literal>USE</literal>) is
-            <replaceable>db_name</replaceable>. All other databases that
-            are not explicitly mentioned are ignored. If you use this,
-            you should ensure that you only do updates in the default
-            database.
+            Tell the server to restrict binary logging to updates for
+            which the default database is
+            <replaceable>db_name</replaceable> (that is, the database
+            selected by <literal>USE</literal>). All other databases
+            that are not explicitly mentioned are ignored. If you use
+            this option, you should ensure that you do updates only in
+            the default database.
           </para>
 
           <para>
-            Observe that there is an exception to the
-            <literal>CREATE/ALTER/DROP DATABASE</literal> statements,
-            which use the database manipulated to decide if it should
-            log the statement rather than the default database.
+            There is an exception to this for <literal>CREATE
+            DATABASE</literal>, <literal>ALTER DATABASE</literal>, and
+            <literal>DROP DATABASE</literal> statements. The server uses
+            the database named in the statement (not the default
+            database) to decide whether it should log the statement.
           </para>
 
           <para>
@@ -20108,6 +20115,11 @@
             amount=amount+1000;</literal>, this statement is
             <emphasis>not</emphasis> written into the binary log.
           </para>
+
+          <para>
+            To log multiple databases, use multiple options, specifying
+            the option once for each database.
+          </para>
         </listitem>
 
         <listitem>
@@ -20116,14 +20128,24 @@
           </para>
 
           <para>
-            Tells the master that updates where the default database
-            (that is, the one selected by <literal>USE</literal>) is
-            <replaceable>db_name</replaceable> should not be stored in
-            the binary log. If you use this, you should ensure that you
-            only do updates in the default database.
+            Tell the server to suppress binary logging of updates for
+            which the default database is
+            <replaceable>db_name</replaceable> (that is, the database
+            selected by <literal>USE</literal>). If you use this option,
+            you should ensure that you do updates only in the default
+            database.
           </para>
 
           <para>
+            As with the <option>--binlog-do-db</option> option, there is
+            an exception for the <literal>CREATE DATABASE</literal>,
+            <literal>ALTER DATABASE</literal>, and <literal>DROP
+            DATABASE</literal> statements. The server uses the database
+            named in the statement (not the default database) to decide
+            whether it should log the statement.
+          </para>
+
+          <para>
             An example of what does not work as you might expect: If the
             server is started with
             <literal>binlog-ignore-db=sales</literal>, and you run
@@ -20133,38 +20155,29 @@
           </para>
 
           <para>
-            Similar to the case for <option>--binlog-do-db</option>,
-            there is an exception to the <literal>CREATE
-            DATABASE</literal>, <literal>ALTER DATABASE</literal>, and
-            <literal>DROP DATABASE</literal> statements, which use the
-            database manipulated to decide if it should log the
-            statement rather than the default database.
+            To ignore multiple databases, use multiple options,
+            specifying the option once for each database.
           </para>
         </listitem>
 
       </itemizedlist>
 
       <para>
-        To log or ignore multiple databases, use multiple options,
-        specifying the appropriate option once for each database.
-      </para>
-
-      <para>
         The server evaluates the options for logging or ignoring updates
-        to the binary log according to the following rules. Observe that
-        there is an exception for
-        <literal>CREATE</literal>/<literal>ALTER</literal>/<literal>DROP
-        DATABASE</literal> statements. In those cases, the database
-        being <emphasis>created, altered, or dropped</emphasis> replaces
-        the default database in the following rules.
+        to the binary log according to the following rules. As described
+        previously, there is an exception for the <literal>CREATE
+        DATABASE</literal>, <literal>ALTER DATABASE</literal>, and
+        <literal>DROP DATABASE</literal> statements. In those cases, the
+        database being <emphasis>created, altered, or dropped</emphasis>
+        replaces the default database in the following rules.
       </para>
 
       <orderedlist>
 
         <listitem>
           <para>
-            Are there <literal>binlog-do-db</literal> or
-            <literal>binlog-ignore-db</literal> rules?
+            Are there <option>--binlog-do-db</option> or
+            <option>--binlog-ignore-db</option> rules?
           </para>
 
           <itemizedlist>
@@ -20186,8 +20199,8 @@
 
         <listitem>
           <para>
-            There are some rules (<literal>binlog-do-db</literal> or
-            <literal>binlog-ignore-db</literal> or both). Is there a
+            There are some rules (<option>--binlog-do-db</option>,
+            <option>--binlog-ignore-db</option>, or both). Is there a
             default database (has any database been selected by
             <literal>USE</literal>?)?
           </para>
@@ -20213,7 +20226,7 @@
         <listitem>
           <para>
             There is a default database. Are there some
-            <literal>binlog-do-db</literal> rules?
+            <option>--binlog-do-db</option> rules?
           </para>
 
           <itemizedlist>
@@ -20221,7 +20234,7 @@
             <listitem>
               <para>
                 Yes: Does the default database match any of the
-                <literal>binlog-do-db</literal> rules?
+                <option>--binlog-do-db</option> rules?
               </para>
 
               <itemizedlist>
@@ -20253,9 +20266,9 @@
 
         <listitem>
           <para>
-            There are some <literal>binlog-ignore-db</literal> rules.
+            There are some <option>--binlog-ignore-db</option> rules.
             Does the default database match any of the
-            <literal>binlog-ignore-db</literal> rules?
+            <option>--binlog-ignore-db</option> rules?
           </para>
 
           <itemizedlist>
@@ -20279,10 +20292,10 @@
 
       <para>
         For example, a slave running with only
-        <literal>binlog-do-db=sales</literal> does not write to the
+        <option>--binlog-do-db=sales</option> does not write to the
         binary log any statement for which the default database is
         different from <literal>sales</literal> (in other words,
-        <literal>binlog-do-db</literal> can sometimes mean <quote>ignore
+        <option>--binlog-do-db</option> can sometimes mean <quote>ignore
         other databases</quote>).
       </para>
 

Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml	2006-01-29 14:19:31 UTC (rev 1104)
+++ trunk/refman-4.1/replication.xml	2006-01-29 19:08:40 UTC (rev 1105)
@@ -2453,14 +2453,14 @@
         </para>
 
         <para>
-          Makes the slave print more messages to the error log about
-          what it is doing. For example, it warns you that it succeeded
-          in reconnecting after a network/connection failure, and warns
-          you about how each slave thread started. This option is
-          enabled by default as of MySQL 4.0.19 and 4.1.2; to disable
-          it, use <option>--skip-log-warnings</option>. As of MySQL
-          4.0.21 and 4.1.3, aborted connections are not logged to the
-          error log unless the value is greater than 1.
+          Make the slave print more messages to the error log about what
+          it is doing. For example, it warns you that it succeeded in
+          reconnecting after a network/connection failure, and warns you
+          about how each slave thread started. This option is enabled by
+          default as of MySQL 4.0.19 and 4.1.2; to disable it, use
+          <option>--skip-log-warnings</option>. As of MySQL 4.0.21 and
+          4.1.3, aborted connections are not logged to the error log
+          unless the value is greater than 1.
         </para>
 
         <para>
@@ -2612,10 +2612,10 @@
         </para>
 
         <para>
-          This option causes the slave to allow no updates except from
-          slave threads or from users with the <literal>SUPER</literal>
-          privilege. This can be useful to ensure that a slave server
-          accepts no updates from clients.
+          Cause the slave to allow no updates except from slave threads
+          or from users with the <literal>SUPER</literal> privilege.
+          This can be useful to ensure that a slave server accepts no
+          updates from clients.
         </para>
 
         <para>
@@ -2675,7 +2675,7 @@
         </para>
 
         <para>
-          Disables or enables automatic purging of relay logs as soon as
+          Disable or enable automatic purging of relay logs as soon as
           they are not needed any more. The default value is 1
           (enabled). This is a global variable that can be changed
           dynamically with <literal>SET GLOBAL
@@ -2693,7 +2693,7 @@
         </para>
 
         <para>
-          Places an upper limit on the total size of all relay logs on
+          Place an upper limit on the total size of all relay logs on
           the slave (a value of 0 means <quote>unlimited</quote>). This
           is useful for a slave server host that has limited disk space.
           When the limit is reached, the I/O thread stops reading binary
@@ -2723,8 +2723,8 @@
         </para>
 
         <para>
-          Tells the slave to restrict replication to statements where
-          the default database (that is, the one selected by
+          Tell the slave to restrict replication to statements where the
+          default database (that is, the one selected by
           <literal>USE</literal>) is <replaceable>db_name</replaceable>.
           To specify more than one database, use this option multiple
           times, once for each database. Note that this does not
@@ -2774,9 +2774,9 @@
         </para>
 
         <para>
-          Tells the slave thread to restrict replication to the
-          specified table. To specify more than one table, use this
-          option multiple times, once for each table. This works for
+          Tell the slave thread to restrict replication to the specified
+          table. To specify more than one table, use this option
+          multiple times, once for each table. This works for
           cross-database updates, in contrast to
           <option>--replicate-do-db</option>. See
           <xref linkend="replication-rules"/>.
@@ -3956,8 +3956,9 @@
       perform a computation similar to the one just shown that
       accurately predicts what will happen on your system if you add
       <replaceable>N</replaceable> replication slaves. However,
-      answering the following questions should help you decide if and by
-      how much replication will improve the performance of your system:
+      answering the following questions should help you decide whether
+      and by how much replication will improve the performance of your
+      system:
     </para>
 
     <itemizedlist>

Modified: trunk/refman-5.0/connector-j.xml
===================================================================
--- trunk/refman-5.0/connector-j.xml	2006-01-29 14:19:31 UTC (rev 1104)
+++ trunk/refman-5.0/connector-j.xml	2006-01-29 19:08:40 UTC (rev 1105)
@@ -4106,7 +4106,7 @@
 
     &lt;!-- Don't use autoReconnect=true, it's going away eventually
          and it's a crutch for older connection pools that couldn't
-         test connections. You need to decide if your application is
+         test connections. You need to decide whether your application is
          supposed to deal with SQLExceptions (hint, it should), and
          how much of a performance penalty you're willing to pay
          to ensure 'freshness' of the connection --&gt;

Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml	2006-01-29 14:19:31 UTC (rev 1104)
+++ trunk/refman-5.0/database-administration.xml	2006-01-29 19:08:40 UTC (rev 1105)
@@ -21840,14 +21840,7 @@
       <para>
         The error log file contains information indicating when
         <command>mysqld</command> was started and stopped and also any
-        critical errors that occur while the server is running.
-      </para>
-
-      <para>
-        If <command>mysqld</command> dies unexpectedly and
-        <command>mysqld_safe</command> needs to restart it,
-        <command>mysqld_safe</command> writes a <literal>restarted
-        mysqld</literal> message to the error log. If
+        critical errors that occur while the server is running. If
         <command>mysqld</command> notices a table that needs to be
         automatically checked or repaired, it writes a message to the
         error log.
@@ -21861,6 +21854,13 @@
       </para>
 
       <para>
+        If <command>mysqld</command> dies unexpectedly and
+        <command>mysqld_safe</command> needs to restart it,
+        <command>mysqld_safe</command> writes a <literal>restarted
+        mysqld</literal> message to the error log.
+      </para>
+
+      <para>
         You can specify where <command>mysqld</command> stores the error
         log file with the
         <option>--log-error[=<replaceable>file_name</replaceable>]</option>
@@ -21877,8 +21877,8 @@
       <para>
         If you do not specify <option>--log-error</option>, or (on
         Windows) if you use the <option>--console</option> option,
-        errors are written to stderr, the standard error output. Usually
-        this is your terminal.
+        errors are written to <literal>stderr</literal>, the standard
+        error output. Usually this is your terminal.
       </para>
 
       <para>
@@ -21919,10 +21919,10 @@
       <para>
         <command>mysqld</command> writes statements to the query log in
         the order that it receives them. This may be different from the
-        order in which they are executed. This is in contrast to the
-        update log and the binary log, which are written after the query
-        is executed, but before any locks are released. (The query log
-        also contains all statements, whereas the binary log does not
+        order in which they are executed. This is in contrast to the the
+        binary log, for which statements are written after they are
+        executed, but before any locks are released. (Also, the query
+        log contains all statements, whereas the binary log does not
         contain statements that only select data.)
       </para>
 
@@ -21934,10 +21934,10 @@
       </para>
 
 <programlisting>
-shell&gt; <userinput>mv hostname.log hostname-old.log</userinput>
+shell&gt; <userinput>mv <replaceable>host_name</replaceable>.log <replaceable>host_name</replaceable>-old.log</userinput>
 shell&gt; <userinput>mysqladmin flush-logs</userinput>
-shell&gt; <userinput>cp hostname-old.log to-backup-directory</userinput>
-shell&gt; <userinput>rm hostname-old.log</userinput>
+shell&gt; <userinput>cp <replaceable>host_name</replaceable>-old.log <replaceable>backup-directory</replaceable></userinput>
+shell&gt; <userinput>rm <replaceable>host_name</replaceable>-old.log</userinput>
 </programlisting>
 
       <para>
@@ -21972,7 +21972,7 @@
         <literal>DELETE</literal> which matched no rows). Statements are
         stored in the form of <quote>events</quote> that describe the
         modifications. The binary log also contains information about
-        how long each statement took that updated the database.
+        how long each statement took that updated data.
       </para>
 
       <para>
@@ -21994,18 +21994,14 @@
 
       <para>
         The primary purpose of the binary log is to be able to update
-        the database during a restore operation as fully as possible,
+        databases during a restore operation as fully as possible,
         because the binary log contains all updates done after a backup
-        was made.
+        was made. The binary log is also used on master replication
+        servers as a record of the statements to be sent to slave
+        servers. See <xref linkend="replication"/>.
       </para>
 
       <para>
-        The binary log is also used on master replication servers as a
-        record of the statements to be sent to slave servers. See
-        <xref linkend="replication"/>.
-      </para>
-
-      <para>
         Running the server with the binary log enabled makes performance
         about 1% slower. However, the benefits of the binary log for
         restore operations and in allowing you to set up replication
@@ -22014,39 +22010,41 @@
 
       <para>
         When started with the
-        <option>--log-bin[=<replaceable>file_name</replaceable>]</option>
+        <option>--log-bin[=<replaceable>base_name</replaceable>]</option>
         option, <command>mysqld</command> writes a log file containing
         all SQL commands that update data. If no
-        <replaceable>file_name</replaceable> value is given, the default
+        <replaceable>base_name</replaceable> value is given, the default
         name is the name of the host machine followed by
-        <literal>-bin</literal>. If file name is given, but it does not
-        contain a path, the file is written in the data directory. It is
-        recommended to specify a filename, see
+        <literal>-bin</literal>. If the basename is given, but not as an
+        absolute pathname, the server writes the file in the data
+        directory. It is recommended that you specify a basename; see
         <xref linkend="open-bugs"/>, for the reason.
       </para>
 
       <para>
         If you supply an extension in the log name (for example,
-        <option>--log-bin=<replaceable>file_name.extension</replaceable></option>),
+        <option>--log-bin=<replaceable>base_name.extension</replaceable></option>),
         the extension is silently removed and ignored.
       </para>
 
       <para>
         <command>mysqld</command> appends a numeric extension to the
-        binary log name. The number is incremented each time you start
-        the server or flush the logs. A new binary log also is created
-        automatically when the current log's size reaches
-        <literal>max_binlog_size</literal>. A binary log may become
+        binary log basename. The number increases each time the server
+        creates a new log file, thus creating an ordered series of
+        files. The server creates a new binary log file each time it
+        starts or flushes the logs. The server also creates a new binary
+        log file automatically when the current log's size reaches
+        <literal>max_binlog_size</literal>. A binary log file may become
         larger than <literal>max_binlog_size</literal> if you are using
-        large transactions: A transaction is written to the binary log
-        in one piece, never split between binary logs.
+        large transactions because a transaction is written to the file
+        in one piece, never split between files.
       </para>
 
       <para>
         To keep track of which binary log files have been used,
         <command>mysqld</command> also creates a binary log index file
         that contains the names of all used binary log files. By default
-        this has the same name as the binary log file, with the
+        this has the same basename as the binary log file, with the
         extension <literal>'.index'</literal>. You can change the name
         of the binary log index file with the
         <option>--log-bin-index[=<replaceable>file_name</replaceable>]</option>
@@ -22063,15 +22061,15 @@
 
       <para>
         You can delete all binary log files with the <literal>RESET
-        MASTER</literal> statement, or only some of them with
+        MASTER</literal> statement, or a subset of them with
         <literal>PURGE MASTER LOGS</literal>. See
         <xref linkend="reset"/>, and
         <xref linkend="replication-master-sql"/>.
       </para>
 
       <para>
-        The binary log format has some known limitations which can
-        affect recovery from backups. See
+        The binary log format has some known limitations that can affect
+        recovery from backups. See
         <xref linkend="replication-features"/>.
       </para>
 
@@ -22086,6 +22084,14 @@
         discussion that follows this option list.
       </para>
 
+      <para>
+        If you are using replication, the options described here affect
+        which statements are sent by a master server to its slaves.
+        There are also options for slave servers that control which
+        statements received from the master to execute or ignore. For
+        details, see <xref linkend="replication-options"/>.
+      </para>
+
       <itemizedlist>
 
         <listitem>
@@ -22094,22 +22100,21 @@
           </para>
 
           <para>
-            Tells the master that it should log updates to the binary
-            log if the default database (that is, the one selected by
-            <literal>USE</literal>) is
-            <replaceable>db_name</replaceable>. All other databases that
-            are not explicitly mentioned are ignored. If you use this,
-            you should ensure that you only do updates in the default
-            database.
+            Tell the server to restrict binary logging to updates for
+            which the default database is
+            <replaceable>db_name</replaceable> (that is, the database
+            selected by <literal>USE</literal>). All other databases
+            that are not explicitly mentioned are ignored. If you use
+            this option, you should ensure that you do updates only in
+            the default database.
           </para>
 
           <para>
-            Observe that there is an exception to this as regards the
-            <literal>CREATE DATABASE</literal>, <literal>ALTER
-            DATABASE</literal>, and <literal>DROP DATABASE</literal>
-            statements, which use the database manipulated to decide if
-            it should log the statement rather than the default
-            database.
+            There is an exception to this for <literal>CREATE
+            DATABASE</literal>, <literal>ALTER DATABASE</literal>, and
+            <literal>DROP DATABASE</literal> statements. The server uses
+            the database named in the statement (not the default
+            database) to decide whether it should log the statement.
           </para>
 
           <para>
@@ -22120,6 +22125,11 @@
             amount=amount+1000;</literal>, this statement is
             <emphasis>not</emphasis> written into the binary log.
           </para>
+
+          <para>
+            To log multiple databases, use multiple options, specifying
+            the option once for each database.
+          </para>
         </listitem>
 
         <listitem>
@@ -22128,14 +22138,24 @@
           </para>
 
           <para>
-            Tells the master that updates where the default database
-            (that is, the one selected by <literal>USE</literal>) is
-            <replaceable>db_name</replaceable> should not be stored in
-            the binary log. If you use this, you should ensure that you
-            only do updates in the default database.
+            Tell the server to suppress binary logging of updates for
+            which the default database is
+            <replaceable>db_name</replaceable> (that is, the database
+            selected by <literal>USE</literal>). If you use this option,
+            you should ensure that you do updates only in the default
+            database.
           </para>
 
           <para>
+            As with the <option>--binlog-do-db</option> option, there is
+            an exception for the <literal>CREATE DATABASE</literal>,
+            <literal>ALTER DATABASE</literal>, and <literal>DROP
+            DATABASE</literal> statements. The server uses the database
+            named in the statement (not the default database) to decide
+            whether it should log the statement.
+          </para>
+
+          <para>
             An example of what does not work as you might expect: If the
             server is started with
             <literal>binlog-ignore-db=sales</literal>, and you run
@@ -22145,38 +22165,29 @@
           </para>
 
           <para>
-            Similar to the case for <option>--binlog-do-db</option>,
-            there is an exception to the <literal>CREATE
-            DATABASE</literal>, <literal>ALTER DATABASE</literal>, and
-            <literal>DROP DATABASE</literal> statements, which use the
-            database manipulated to decide if it should log the
-            statement rather than the default database.
+            To ignore multiple databases, use multiple options,
+            specifying the option once for each database.
           </para>
         </listitem>
 
       </itemizedlist>
 
       <para>
-        To log or ignore multiple databases, use multiple options,
-        specifying the appropriate option once for each database.
-      </para>
-
-      <para>
         The server evaluates the options for logging or ignoring updates
-        to the binary log according to the following rules. Observe that
-        there is an exception for
-        <literal>CREATE</literal>/<literal>ALTER</literal>/<literal>DROP
-        DATABASE</literal> statements. In those cases, the database
-        being <emphasis>created, altered, or dropped</emphasis> replaces
-        the default database in the following rules.
+        to the binary log according to the following rules. As described
+        previously, there is an exception for the <literal>CREATE
+        DATABASE</literal>, <literal>ALTER DATABASE</literal>, and
+        <literal>DROP DATABASE</literal> statements. In those cases, the
+        database being <emphasis>created, altered, or dropped</emphasis>
+        replaces the default database in the following rules.
       </para>
 
       <orderedlist>
 
         <listitem>
           <para>
-            Are there <literal>binlog-do-db</literal> or
-            <literal>binlog-ignore-db</literal> rules?
+            Are there <option>--binlog-do-db</option> or
+            <option>--binlog-ignore-db</option> rules?
           </para>
 
           <itemizedlist>
@@ -22198,8 +22209,8 @@
 
         <listitem>
           <para>
-            There are some rules (<literal>binlog-do-db</literal> or
-            <literal>binlog-ignore-db</literal> or both). Is there a
+            There are some rules (<option>--binlog-do-db</option>,
+            <option>--binlog-ignore-db</option>, or both). Is there a
             default database (has any database been selected by
             <literal>USE</literal>?)?
           </para>
@@ -22225,7 +22236,7 @@
         <listitem>
           <para>
             There is a default database. Are there some
-            <literal>binlog-do-db</literal> rules?
+            <option>--binlog-do-db</option> rules?
           </para>
 
           <itemizedlist>
@@ -22233,7 +22244,7 @@
             <listitem>
               <para>
                 Yes: Does the default database match any of the
-                <literal>binlog-do-db</literal> rules?
+                <option>--binlog-do-db</option> rules?
               </para>
 
               <itemizedlist>
@@ -22265,9 +22276,9 @@
 
         <listitem>
           <para>
-            There are some <literal>binlog-ignore-db</literal> rules.
+            There are some <option>--binlog-ignore-db</option> rules.
             Does the default database match any of the
-            <literal>binlog-ignore-db</literal> rules?
+            <option>--binlog-ignore-db</option> rules?
           </para>
 
           <itemizedlist>
@@ -22291,10 +22302,10 @@
 
       <para>
         For example, a slave running with only
-        <literal>binlog-do-db=sales</literal> does not write to the
+        <option>--binlog-do-db=sales</option> does not write to the
         binary log any statement for which the default database is
         different from <literal>sales</literal> (in other words,
-        <literal>binlog-do-db</literal> can sometimes mean <quote>ignore
+        <option>--binlog-do-db</option> can sometimes mean <quote>ignore
         other databases</quote>).
       </para>
 

Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml	2006-01-29 14:19:31 UTC (rev 1104)
+++ trunk/refman-5.0/replication.xml	2006-01-29 19:08:40 UTC (rev 1105)
@@ -2346,11 +2346,11 @@
         </para>
 
         <para>
-          Makes the slave print more messages to the error log about
-          what it is doing. For example, it warns you that it succeeded
-          in reconnecting after a network/connection failure, and
-          informs you as to how each slave thread started. This option
-          is enabled by default; to disable it, use
+          Make the slave print more messages to the error log about what
+          it is doing. For example, it warns you that it succeeded in
+          reconnecting after a network/connection failure, and informs
+          you as to how each slave thread started. This option is
+          enabled by default; to disable it, use
           <option>--skip-log-warnings</option>. Aborted connections are
           not logged to the error log unless the value is greater than
           <literal>1</literal>.
@@ -2495,12 +2495,11 @@
         </para>
 
         <para>
-          This option causes the slave not to allow any updates except
-          from slave threads or from users having the
-          <literal>SUPER</literal> privilege. This can be useful to
-          ensure that a slave server accepts no updates from clients. As
-          of MySQL 5.0.16, this option does not apply to
-          <literal>TEMPORARY</literal> tables.
+          Cause the slave to allow no updates except from slave threads
+          or from users having the <literal>SUPER</literal> privilege.
+          This can be useful to ensure that a slave server accepts no
+          updates from clients. As of MySQL 5.0.16, this option does not
+          apply to <literal>TEMPORARY</literal> tables.
         </para>
       </listitem>
 
@@ -2556,7 +2555,7 @@
         </para>
 
         <para>
-          Disables or enables automatic purging of relay logs as soon as
+          Disable or enable automatic purging of relay logs as soon as
           they are not needed any more. The default value is 1
           (enabled). This is a global variable that can be changed
           dynamically with <literal>SET GLOBAL
@@ -2570,7 +2569,7 @@
         </para>
 
         <para>
-          Places an upper limit on the total size of all relay logs on
+          Place an upper limit on the total size of all relay logs on
           the slave (a value of 0 means <quote>unlimited</quote>). This
           is useful for a slave server host that has limited disk space.
           When the limit is reached, the I/O thread stops reading binary
@@ -2599,8 +2598,8 @@
         </para>
 
         <para>
-          Tells the slave to restrict replication to statements where
-          the default database (that is, the one selected by
+          Tell the slave to restrict replication to statements where the
+          default database (that is, the one selected by
           <literal>USE</literal>) is <replaceable>db_name</replaceable>.
           To specify more than one database, use this option multiple
           times, once for each database. Note that this does not
@@ -2650,9 +2649,9 @@
         </para>
 
         <para>
-          Tells the slave thread to restrict replication to the
-          specified table. To specify more than one table, use this
-          option multiple times, once for each table. This works for
+          Tell the slave thread to restrict replication to the specified
+          table. To specify more than one table, use this option
+          multiple times, once for each table. This works for
           cross-database updates, in contrast to
           <option>--replicate-do-db</option>. See
           <xref linkend="replication-rules"/>.
@@ -3849,8 +3848,9 @@
       perform a computation similar to the one just shown that
       accurately predicts what will happen on your system if you add
       <replaceable>N</replaceable> replication slaves. However,
-      answering the following questions should help you decide if and by
-      how much replication will improve the performance of your system:
+      answering the following questions should help you decide whether
+      and by how much replication will improve the performance of your
+      system:
     </para>
 
     <itemizedlist>

Modified: trunk/refman-5.1/connector-j.xml
===================================================================
--- trunk/refman-5.1/connector-j.xml	2006-01-29 14:19:31 UTC (rev 1104)
+++ trunk/refman-5.1/connector-j.xml	2006-01-29 19:08:40 UTC (rev 1105)
@@ -4106,7 +4106,7 @@
 
     &lt;!-- Don't use autoReconnect=true, it's going away eventually
          and it's a crutch for older connection pools that couldn't
-         test connections. You need to decide if your application is
+         test connections. You need to decide whether your application is
          supposed to deal with SQLExceptions (hint, it should), and
          how much of a performance penalty you're willing to pay
          to ensure 'freshness' of the connection --&gt;

Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml	2006-01-29 14:19:31 UTC (rev 1104)
+++ trunk/refman-5.1/database-administration.xml	2006-01-29 19:08:40 UTC (rev 1105)
@@ -21849,14 +21849,7 @@
       <para>
         The error log file contains information indicating when
         <command>mysqld</command> was started and stopped and also any
-        critical errors that occur while the server is running.
-      </para>
-
-      <para>
-        If <command>mysqld</command> dies unexpectedly and
-        <command>mysqld_safe</command> needs to restart it,
-        <command>mysqld_safe</command> writes a <literal>restarted
-        mysqld</literal> message to the error log. If
+        critical errors that occur while the server is running. If
         <command>mysqld</command> notices a table that needs to be
         automatically checked or repaired, it writes a message to the
         error log.
@@ -21870,6 +21863,13 @@
       </para>
 
       <para>
+        If <command>mysqld</command> dies unexpectedly and
+        <command>mysqld_safe</command> needs to restart it,
+        <command>mysqld_safe</command> writes a <literal>restarted
+        mysqld</literal> message to the error log.
+      </para>
+
+      <para>
         You can specify where <command>mysqld</command> stores the error
         log file with the
         <option>--log-error[=<replaceable>file_name</replaceable>]</option>
@@ -21886,8 +21886,8 @@
       <para>
         If you do not specify <option>--log-error</option>, or (on
         Windows) if you use the <option>--console</option> option,
-        errors are written to stderr, the standard error output. Usually
-        this is your terminal.
+        errors are written to <literal>stderr</literal>, the standard
+        error output. Usually this is your terminal.
       </para>
 
       <para>
@@ -21928,10 +21928,10 @@
       <para>
         <command>mysqld</command> writes statements to the query log in
         the order that it receives them. This may be different from the
-        order in which they are executed. This is in contrast to the
-        update log and the binary log, which are written after the query
-        is executed, but before any locks are released. (The query log
-        also contains all statements, whereas the binary log does not
+        order in which they are executed. This is in contrast to the the
+        binary log, for which statements are written after they are
+        executed, but before any locks are released. (Also, the query
+        log contains all statements, whereas the binary log does not
         contain statements that only select data.)
       </para>
 
@@ -21943,10 +21943,10 @@
       </para>
 
 <programlisting>
-shell&gt; <userinput>mv hostname.log hostname-old.log</userinput>
+shell&gt; <userinput>mv <replaceable>host_name</replaceable>.log <replaceable>host_name</replaceable>-old.log</userinput>
 shell&gt; <userinput>mysqladmin flush-logs</userinput>
-shell&gt; <userinput>cp hostname-old.log to-backup-directory</userinput>
-shell&gt; <userinput>rm hostname-old.log</userinput>
+shell&gt; <userinput>cp <replaceable>host_name</replaceable>-old.log <replaceable>backup-directory</replaceable></userinput>
+shell&gt; <userinput>rm <replaceable>host_name</replaceable>-old.log</userinput>
 </programlisting>
 
       <para>
@@ -21981,7 +21981,7 @@
         <literal>DELETE</literal> which matched no rows). Statements are
         stored in the form of <quote>events</quote> that describe the
         modifications. The binary log also contains information about
-        how long each statement took that updated the database.
+        how long each statement took that updated data.
       </para>
 
       <para>
@@ -22003,18 +22003,14 @@
 
       <para>
         The primary purpose of the binary log is to be able to update
-        the database during a restore operation as fully as possible,
+        databases during a restore operation as fully as possible,
         because the binary log contains all updates done after a backup
-        was made.
+        was made. The binary log is also used on master replication
+        servers as a record of the statements to be sent to slave
+        servers. See <xref linkend="replication"/>.
       </para>
 
       <para>
-        The binary log is also used on master replication servers as a
-        record of the statements to be sent to slave servers. See
-        <xref linkend="replication"/>.
-      </para>
-
-      <para>
         Running the server with the binary log enabled makes performance
         about 1% slower. However, the benefits of the binary log for
         restore operations and in allowing you to set up replication
@@ -22023,39 +22019,41 @@
 
       <para>
         When started with the
-        <option>--log-bin[=<replaceable>file_name</replaceable>]</option>
+        <option>--log-bin[=<replaceable>base_name</replaceable>]</option>
         option, <command>mysqld</command> writes a log file containing
         all SQL commands that update data. If no
-        <replaceable>file_name</replaceable> value is given, the default
+        <replaceable>base_name</replaceable> value is given, the default
         name is the name of the host machine followed by
-        <literal>-bin</literal>. If file name is given, but it does not
-        contain a path, the file is written in the data directory. It is
-        recommended to specify a filename, see
+        <literal>-bin</literal>. If the basename is given, but not as an
+        absolute pathname, the server writes the file in the data
+        directory. It is recommended that you specify a basename; see
         <xref linkend="open-bugs"/>, for the reason.
       </para>
 
       <para>
         If you supply an extension in the log name (for example,
-        <option>--log-bin=<replaceable>file_name.extension</replaceable></option>),
+        <option>--log-bin=<replaceable>base_name.extension</replaceable></option>),
         the extension is silently removed and ignored.
       </para>
 
       <para>
         <command>mysqld</command> appends a numeric extension to the
-        binary log name. The number is incremented each time you start
-        the server or flush the logs. A new binary log also is created
-        automatically when the current log's size reaches
-        <literal>max_binlog_size</literal>. A binary log may become
+        binary log basename. The number increases each time the server
+        creates a new log file, thus creating an ordered series of
+        files. The server creates a new binary log file each time it
+        starts or flushes the logs. The server also creates a new binary
+        log file automatically when the current log's size reaches
+        <literal>max_binlog_size</literal>. A binary log file may become
         larger than <literal>max_binlog_size</literal> if you are using
-        large transactions: A transaction is written to the binary log
-        in one piece, never split between binary logs.
+        large transactions because a transaction is written to the file
+        in one piece, never split between files.
       </para>
 
       <para>
         To keep track of which binary log files have been used,
         <command>mysqld</command> also creates a binary log index file
         that contains the names of all used binary log files. By default
-        this has the same name as the binary log file, with the
+        this has the same basename as the binary log file, with the
         extension <literal>'.index'</literal>. You can change the name
         of the binary log index file with the
         <option>--log-bin-index[=<replaceable>file_name</replaceable>]</option>
@@ -22072,15 +22070,15 @@
 
       <para>
         You can delete all binary log files with the <literal>RESET
-        MASTER</literal> statement, or only some of them with
+        MASTER</literal> statement, or a subset of them with
         <literal>PURGE MASTER LOGS</literal>. See
         <xref linkend="reset"/>, and
         <xref linkend="replication-master-sql"/>.
       </para>
 
       <para>
-        The binary log format has some known limitations which can
-        affect recovery from backups. See
+        The binary log format has some known limitations that can affect
+        recovery from backups. See
         <xref linkend="replication-features"/>.
       </para>
 
@@ -22095,6 +22093,14 @@
         discussion that follows this option list.
       </para>
 
+      <para>
+        If you are using replication, the options described here affect
+        which statements are sent by a master server to its slaves.
+        There are also options for slave servers that control which
+        statements received from the master to execute or ignore. For
+        details, see <xref linkend="replication-options"/>.
+      </para>
+
       <itemizedlist>
 
         <listitem>
@@ -22103,22 +22109,21 @@
           </para>
 
           <para>
-            Tells the master that it should log updates to the binary
-            log if the default database (that is, the one selected by
-            <literal>USE</literal>) is
-            <replaceable>db_name</replaceable>. All other databases that
-            are not explicitly mentioned are ignored. If you use this,
-            you should ensure that you only do updates in the default
-            database.
+            Tell the server to restrict binary logging to updates for
+            which the default database is
+            <replaceable>db_name</replaceable> (that is, the database
+            selected by <literal>USE</literal>). All other databases
+            that are not explicitly mentioned are ignored. If you use
+            this option, you should ensure that you do updates only in
+            the default database.
           </para>
 
           <para>
-            Observe that there is an exception to this as regards the
-            <literal>CREATE DATABASE</literal>, <literal>ALTER
-            DATABASE</literal>, and <literal>DROP DATABASE</literal>
-            statements, which use the database manipulated to decide if
-            it should log the statement rather than the default
-            database.
+            There is an exception to this for <literal>CREATE
+            DATABASE</literal>, <literal>ALTER DATABASE</literal>, and
+            <literal>DROP DATABASE</literal> statements. The server uses
+            the database named in the statement (not the default
+            database) to decide whether it should log the statement.
           </para>
 
           <para>
@@ -22129,6 +22134,11 @@
             amount=amount+1000;</literal>, this statement is
             <emphasis>not</emphasis> written into the binary log.
           </para>
+
+          <para>
+            To log multiple databases, use multiple options, specifying
+            the option once for each database.
+          </para>
         </listitem>
 
         <listitem>
@@ -22137,14 +22147,24 @@
           </para>
 
           <para>
-            Tells the master that updates where the default database
-            (that is, the one selected by <literal>USE</literal>) is
-            <replaceable>db_name</replaceable> should not be stored in
-            the binary log. If you use this, you should ensure that you
-            only do updates in the default database.
+            Tell the server to suppress binary logging of updates for
+            which the default database is
+            <replaceable>db_name</replaceable> (that is, the database
+            selected by <literal>USE</literal>). If you use this option,
+            you should ensure that you do updates only in the default
+            database.
           </para>
 
           <para>
+            As with the <option>--binlog-do-db</option> option, there is
+            an exception for the <literal>CREATE DATABASE</literal>,
+            <literal>ALTER DATABASE</literal>, and <literal>DROP
+            DATABASE</literal> statements. The server uses the database
+            named in the statement (not the default database) to decide
+            whether it should log the statement.
+          </para>
+
+          <para>
             An example of what does not work as you might expect: If the
             server is started with
             <literal>binlog-ignore-db=sales</literal>, and you run
@@ -22154,38 +22174,29 @@
           </para>
 
           <para>
-            Similar to the case for <option>--binlog-do-db</option>,
-            there is an exception to the <literal>CREATE
-            DATABASE</literal>, <literal>ALTER DATABASE</literal>, and
-            <literal>DROP DATABASE</literal> statements, which use the
-            database manipulated to decide if it should log the
-            statement rather than the default database.
+            To ignore multiple databases, use multiple options,
+            specifying the option once for each database.
           </para>
         </listitem>
 
       </itemizedlist>
 
       <para>
-        To log or ignore multiple databases, use multiple options,
-        specifying the appropriate option once for each database.
-      </para>
-
-      <para>
         The server evaluates the options for logging or ignoring updates
-        to the binary log according to the following rules. Observe that
-        there is an exception for
-        <literal>CREATE</literal>/<literal>ALTER</literal>/<literal>DROP
-        DATABASE</literal> statements. In those cases, the database
-        being <emphasis>created, altered, or dropped</emphasis> replaces
-        the default database in the following rules.
+        to the binary log according to the following rules. As described
+        previously, there is an exception for the <literal>CREATE
+        DATABASE</literal>, <literal>ALTER DATABASE</literal>, and
+        <literal>DROP DATABASE</literal> statements. In those cases, the
+        database being <emphasis>created, altered, or dropped</emphasis>
+        replaces the default database in the following rules.
       </para>
 
       <orderedlist>
 
         <listitem>
           <para>
-            Are there <literal>binlog-do-db</literal> or
-            <literal>binlog-ignore-db</literal> rules?
+            Are there <option>--binlog-do-db</option> or
+            <option>--binlog-ignore-db</option> rules?
           </para>
 
           <itemizedlist>
@@ -22207,8 +22218,8 @@
 
         <listitem>
           <para>
-            There are some rules (<literal>binlog-do-db</literal> or
-            <literal>binlog-ignore-db</literal> or both). Is there a
+            There are some rules (<option>--binlog-do-db</option>,
+            <option>--binlog-ignore-db</option>, or both). Is there a
             default database (has any database been selected by
             <literal>USE</literal>?)?
           </para>
@@ -22234,7 +22245,7 @@
         <listitem>
           <para>
             There is a default database. Are there some
-            <literal>binlog-do-db</literal> rules?
+            <option>--binlog-do-db</option> rules?
           </para>
 
           <itemizedlist>
@@ -22242,7 +22253,7 @@
             <listitem>
               <para>
                 Yes: Does the default database match any of the
-                <literal>binlog-do-db</literal> rules?
+                <option>--binlog-do-db</option> rules?
               </para>
 
               <itemizedlist>
@@ -22274,9 +22285,9 @@
 
         <listitem>
           <para>
-            There are some <literal>binlog-ignore-db</literal> rules.
+            There are some <option>--binlog-ignore-db</option> rules.
             Does the default database match any of the
-            <literal>binlog-ignore-db</literal> rules?
+            <option>--binlog-ignore-db</option> rules?
           </para>
 
           <itemizedlist>
@@ -22300,10 +22311,10 @@
 
       <para>
         For example, a slave running with only
-        <literal>binlog-do-db=sales</literal> does not write to the
+        <option>--binlog-do-db=sales</option> does not write to the
         binary log any statement for which the default database is
         different from <literal>sales</literal> (in other words,
-        <literal>binlog-do-db</literal> can sometimes mean <quote>ignore
+        <option>--binlog-do-db</option> can sometimes mean <quote>ignore
         other databases</quote>).
       </para>
 

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-29 14:19:31 UTC (rev 1104)
+++ trunk/refman-5.1/replication.xml	2006-01-29 19:08:40 UTC (rev 1105)
@@ -369,7 +369,7 @@
 
     </itemizedlist>
 -->
-      
+
     <para>
       Row-based replication causes <emphasis>most</emphasis> changes to
       be written to the binary log using the row-based format. Some
@@ -2511,11 +2511,11 @@
         </para>
 
         <para>
-          Makes the slave print more messages to the error log about
-          what it is doing. For example, it warns you that it succeeded
-          in reconnecting after a network/connection failure, and
-          informs you as to how each slave thread started. This option
-          is enabled by default; to disable it, use
+          Make the slave print more messages to the error log about what
+          it is doing. For example, it warns you that it succeeded in
+          reconnecting after a network/connection failure, and informs
+          you as to how each slave thread started. This option is
+          enabled by default; to disable it, use
           <option>--skip-log-warnings</option>. Aborted connections are
           not logged to the error log unless the value is greater than
           <literal>1</literal>.
@@ -2660,12 +2660,11 @@
         </para>
 
         <para>
-          This option causes the slave not to allow any updates except
-          from slave threads or from users having the
-          <literal>SUPER</literal> privilege. This can be useful to
-          ensure that a slave server accepts no updates from clients.
-          This option does not apply to <literal>TEMPORARY</literal>
-          tables.
+          Cause the slave to allow no updates except from slave threads
+          or from users having the <literal>SUPER</literal> privilege.
+          This can be useful to ensure that a slave server accepts no
+          updates from clients. This option does not apply to
+          <literal>TEMPORARY</literal> tables.
         </para>
       </listitem>
 
@@ -2721,7 +2720,7 @@
         </para>
 
         <para>
-          Disables or enables automatic purging of relay logs as soon as
+          Disable or enable automatic purging of relay logs as soon as
           they are not needed any more. The default value is 1
           (enabled). This is a global variable that can be changed
           dynamically with <literal>SET GLOBAL
@@ -2735,7 +2734,7 @@
         </para>
 
         <para>
-          Places an upper limit on the total size of all relay logs on
+          Place an upper limit on the total size of all relay logs on
           the slave (a value of 0 means <quote>unlimited</quote>). This
           is useful for a slave server host that has limited disk space.
           When the limit is reached, the I/O thread stops reading binary
@@ -2764,8 +2763,8 @@
         </para>
 
         <para>
-          Tells the slave to restrict replication to statements where
-          the default database (that is, the one selected by
+          Tell the slave to restrict replication to statements where the
+          default database (that is, the one selected by
           <literal>USE</literal>) is <replaceable>db_name</replaceable>.
           To specify more than one database, use this option multiple
           times, once for each database. Note that this does not
@@ -2815,9 +2814,9 @@
         </para>
 
         <para>
-          Tells the slave thread to restrict replication to the
-          specified table. To specify more than one table, use this
-          option multiple times, once for each table. This works for
+          Tell the slave thread to restrict replication to the specified
+          table. To specify more than one table, use this option
+          multiple times, once for each table. This works for
           cross-database updates, in contrast to
           <option>--replicate-do-db</option>. See
           <xref linkend="replication-rules"/>.
@@ -3275,33 +3274,39 @@
               <emphasis>Yes</emphasis>: In this case, the behaviour
               depends on whether statement-based replication or
               row-based replication are enabled:
+
               <itemizedlist>
+
                 <listitem>
                   <para>
                     <emphasis>Statement-based replication</emphasis>:
-                    Proceed to the next step and
-                    begin evaluating the table rules in the order shown (first
-                    the non-wild rules, and then the wild rules). Only tables
-                    that are to be updated are compared to the rules
+                    Proceed to the next step and begin evaluating the
+                    table rules in the order shown (first the non-wild
+                    rules, and then the wild rules). Only tables that
+                    are to be updated are compared to the rules
                     (<literal>INSERT INTO sales SELECT * FROM
-                      prices</literal>: only <literal>sales</literal> is
+                    prices</literal>: only <literal>sales</literal> is
                     compared to the rules). If several tables are to be
-                    updated (multiple-table statement), the first matching
-                    table (matching <quote>do</quote> or
-                    <quote>ignore</quote>) wins. That is, the first table is
-                    compared to the rules. Then, if no decision could be made,
-                    the second table is compared to the rules, and so on.
+                    updated (multiple-table statement), the first
+                    matching table (matching <quote>do</quote> or
+                    <quote>ignore</quote>) wins. That is, the first
+                    table is compared to the rules. Then, if no decision
+                    could be made, the second table is compared to the
+                    rules, and so on.
                   </para>
                 </listitem>
+
                 <listitem>
                   <para>
-                    <emphasis>Row-based replication</emphasis>:
-                    All table row changes are filtered individually. For
-                    multi-table updates, each table is filtered separately
-                    according to the rules. Some may be changed and some not,
-                    depending on the rules (and the actual changes, of course).
+                    <emphasis>Row-based replication</emphasis>: All
+                    table row changes are filtered individually. For
+                    multi-table updates, each table is filtered
+                    separately according to the rules. Some may be
+                    changed and some not, depending on the rules (and
+                    the actual changes, of course).
                   </para>
                 </listitem>
+
               </itemizedlist>
             </para>
           </listitem>
@@ -4025,8 +4030,9 @@
       perform a computation similar to the one just shown that
       accurately predicts what will happen on your system if you add
       <replaceable>N</replaceable> replication slaves. However,
-      answering the following questions should help you decide if and by
-      how much replication will improve the performance of your system:
+      answering the following questions should help you decide whether
+      and by how much replication will improve the performance of your
+      system:
     </para>
 
     <itemizedlist>

Thread
svn commit - mysqldoc@docsrva: r1105 - in trunk: . refman-4.1 refman-5.0 refman-5.1paul29 Jan