List:Commits« Previous MessageNext Message »
From:paul Date:January 29 2006 5:00am
Subject:svn commit - mysqldoc@docsrva: r1096 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common
View as plain text  
Author: paul
Date: 2006-01-29 06:00:13 +0100 (Sun, 29 Jan 2006)
New Revision: 1096

Log:
 r6844@frost:  paul | 2006-01-28 20:07:18 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/apis.xml
   trunk/refman-4.1/charset.xml
   trunk/refman-4.1/database-administration.xml
   trunk/refman-4.1/functions.xml
   trunk/refman-4.1/innodb.xml
   trunk/refman-4.1/introduction.xml
   trunk/refman-4.1/ndbcluster.xml
   trunk/refman-4.1/renamed-nodes.txt
   trunk/refman-5.0/apis.xml
   trunk/refman-5.0/charset.xml
   trunk/refman-5.0/database-administration.xml
   trunk/refman-5.0/functions.xml
   trunk/refman-5.0/innodb.xml
   trunk/refman-5.0/introduction.xml
   trunk/refman-5.0/ndbcluster.xml
   trunk/refman-5.0/precision-math.xml
   trunk/refman-5.0/renamed-nodes.txt
   trunk/refman-5.1/apis.xml
   trunk/refman-5.1/charset.xml
   trunk/refman-5.1/database-administration.xml
   trunk/refman-5.1/functions.xml
   trunk/refman-5.1/innodb.xml
   trunk/refman-5.1/ndbcluster.xml
   trunk/refman-5.1/partitioning.xml
   trunk/refman-5.1/precision-math.xml
   trunk/refman-5.1/renamed-nodes.txt
   trunk/refman-common/titles.en.ent


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

Modified: trunk/refman-4.1/apis.xml
===================================================================
--- trunk/refman-4.1/apis.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/apis.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -8022,8 +8022,8 @@
           <para>
             This structure represents a prepared statement. A statement
             is created by calling <literal>mysql_stmt_init()</literal>,
-            which returns a statement handle, that is, a pointer to a
-            <literal>MYSQL_STMT</literal>. The handle is used for all
+            which returns a statement handle (that is, a pointer to a
+            <literal>MYSQL_STMT</literal>). The handle is used for all
             subsequent statement-related functions until you close it
             with <literal>mysql_stmt_close()</literal>.
           </para>
@@ -10076,7 +10076,7 @@
         <para>
           <literal>mysql_stmt_fetch()</literal> returns the next row in
           the result set. It can be called only while the result set
-          exists, that is, after a call to
+          exists; that is, after a call to
           <literal>mysql_stmt_execute()</literal> that creates a result
           set or after <literal>mysql_stmt_store_result()</literal>,
           which is called after <literal>mysql_stmt_execute()</literal>

Modified: trunk/refman-4.1/charset.xml
===================================================================
--- trunk/refman-4.1/charset.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/charset.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -3253,7 +3253,7 @@
       <para>
         The most significant feature in
         <literal>utf8_unicode_ci</literal> is that it supports
-        expansions, that is, when one character compares as equal to
+        expansions; that is, when one character compares as equal to
         combinations of other characters. For example, in German and
         some other languages &lsquo;<literal>ß</literal>&rsquo; is
         equal to &lsquo;<literal>ss</literal>&rsquo;.

Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/database-administration.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -16218,10 +16218,10 @@
       This section discusses how to make database backups (full and
       incremental) and how to perform table maintenance. The syntax of
       the SQL statements described here is given in
-      <xref linkend="database-administration"/>. Much of the information
-      here pertains primarily to <literal>MyISAM</literal> tables.
-      <literal>InnoDB</literal> backup procedures are given in
-      <xref linkend="backing-up"/>.
+      <xref linkend="sql-syntax"/>. Much of the information here
+      pertains primarily to <literal>MyISAM</literal> tables. Additional
+      information about <literal>InnoDB</literal> backup procedures is
+      given in <xref linkend="innodb-backup"/>.
     </para>
 
     <section id="backup">
@@ -16251,13 +16251,11 @@
       </para>
 
       <para>
-        If you want to make an SQL-level backup of a table, you can use
-        <literal>SELECT INTO ... OUTFILE</literal> or <literal>BACKUP
-        TABLE</literal>. For <literal>SELECT INTO ... OUTFILE</literal>,
-        the output file cannot previously exist. For <literal>BACKUP
-        TABLE</literal>, the same is true as of MySQL 3.23.56 and
-        4.0.12, because this would be a security risk. See
-        <xref linkend="select"/>, and <xref linkend="backup-table"/>.
+        To make an SQL-level backup of a table, you can use
+        <literal>SELECT INTO ... OUTFILE</literal>. For this statement,
+        the output file cannot previously exist because allowing extant
+        files to be overwritten would constitute a security risk. See
+        <xref linkend="select"/>.
       </para>
 
       <para>
@@ -16287,17 +16285,17 @@
 </programlisting>
 
           <para>
-            You can also simply copy all table files
-            (<filename>*.frm</filename>, <filename>*.MYD</filename>, and
-            <filename>*.MYI</filename> files) as long as the server is
-            not updating anything. The <command>mysqlhotcopy</command>
-            script uses this method. (But note that these methods do not
-            work if your database contains <literal>InnoDB</literal>
-            tables. <literal>InnoDB</literal> does not store table
-            contents in database directories, and
-            <command>mysqlhotcopy</command> works only for
-            <literal>MyISAM</literal> and <literal>ISAM</literal>
-            tables.)
+            You can also create a binary backup simply by copying all
+            table files (<filename>*.frm</filename>,
+            <filename>*.MYD</filename>, and <filename>*.MYI</filename>
+            files), as long as the server isn't updating anything. The
+            <command>mysqlhotcopy</command> script uses this method.
+            (But note that these methods do not work if your database
+            contains <literal>InnoDB</literal> tables.
+            <literal>InnoDB</literal> does not store table contents in
+            database directories, and <command>mysqlhotcopy</command>
+            works only for <literal>MyISAM</literal> and
+            <literal>ISAM</literal> tables.)
           </para>
         </listitem>
 
@@ -16309,9 +16307,10 @@
             </indexterm>
 
             Stop <command>mysqld</command> if it is running, then start
-            it with the <option>--log-bin[=file_name]</option> option.
-            See <xref linkend="binary-log"/>. The binary log files
-            provide you with the information you need to replicate
+            it with the
+            <option>--log-bin[=<replaceable>file_name</replaceable>]</option>
+            option. See <xref linkend="binary-log"/>. The binary log
+            files provide you with the information you need to replicate
             changes to the database that are made subsequent to the
             point at which you executed <command>mysqldump</command>.
           </para>
@@ -16339,7 +16338,7 @@
         explained further below. The next time you do a full backup, you
         should also rotate the binary log using <literal>FLUSH
         LOGS</literal>, <literal>mysqldump --flush-logs</literal>, or
-        <literal>mysqlhotcopy --flushlogs</literal>. See
+        <literal>mysqlhotcopy --flushlog</literal>. See
         <xref linkend="mysqldump"/>, and <xref linkend="mysqlhotcopy"/>.
       </para>
 
@@ -16367,8 +16366,7 @@
         of all cases. If <command>myisamchk</command> fails, try the
         following procedure. Note that it works only if you have enabled
         binary logging by starting MySQL with the
-        <option>--log-bin</option> option; see
-        <xref linkend="binary-log"/>.
+        <option>--log-bin</option> option.
       </para>
 
       <orderedlist>
@@ -16432,8 +16430,8 @@
 
         <listitem>
           <para>
-            To reload the table, use and restore with <literal>LOAD DATA
-            INFILE '<replaceable>file_name</replaceable>' REPLACE
+            To reload the table, use <literal>LOAD DATA INFILE
+            '<replaceable>file_name</replaceable>' REPLACE
             ...</literal>. To avoid duplicate rows, the table must have
             a <literal>PRIMARY KEY</literal> or a
             <literal>UNIQUE</literal> index. The
@@ -16610,13 +16608,14 @@
         <title>&title-backup-policy;</title>
 
         <para>
-          We all know that backups must be scheduled periodically. Full
-          backups (a snapshot of the data at a point in time) can be
-          done in MySQL with several tools. For example, <literal>InnoDB
-          Hot Backup</literal> provides online non-blocking physical
-          backup of the <literal>InnoDB</literal> data files, and
-          <command>mysqldump</command> provides online logical backup.
-          This discussion uses <command>mysqldump</command>.
+          We all know that backups must be scheduled periodically. A
+          full backups (a snapshot of the data at a point in time) can
+          be done in MySQL with several tools. For example,
+          <literal>InnoDB Hot Backup</literal> provides online
+          non-blocking physical backup of the <literal>InnoDB</literal>
+          data files, and <command>mysqldump</command> provides online
+          logical backup. This discussion uses
+          <command>mysqldump</command>.
         </para>
 
         <para>
@@ -16704,25 +16703,26 @@
         </para>
 
         <para>
-          The MySQL binary logs are important for recovery, because they
-          are incremental backups. If you make sure to flush the logs
-          when you make your full backup, then any binary log files
-          created afterward contain all the data changes made since the
-          backup. Let's modify the previous <command>mysqldump</command>
-          command a bit so that it flushes the MySQL binary logs at the
-          moment of the full backup, and so that the dump file contains
-          the name of the new current binary log:
+          The MySQL binary logs are important for recovery because they
+          form the set of incremental backups. If you make sure to flush
+          the logs when you make your full backup, then any binary log
+          files created afterward contain all the data changes made
+          since the backup. Let's modify the previous
+          <command>mysqldump</command> command a bit so that it flushes
+          the MySQL binary logs at the moment of the full backup, and so
+          that the dump file contains the name of the new current binary
+          log:
         </para>
 
 <programlisting>
-shell&gt; <userinput>mysqldump --single-transaction --flush-logs --master-data=2</userinput>
-           <userinput>--all-databases &gt; backup_sunday_1_PM.sql</userinput>
+shell&gt; <userinput>mysqldump --single-transaction --flush-logs --master-data=2 \</userinput>
+         <userinput>--all-databases &gt; backup_sunday_1_PM.sql</userinput>
 </programlisting>
 
         <para>
           After executing this command, the data directory contains a
           new binary log file, <filename>gbichot2-bin.000007</filename>.
-          The resulting <filename>.sql</filename> file contains these
+          The resulting <filename>.sql</filename> file includes these
           lines:
         </para>
 
@@ -16733,7 +16733,7 @@
 
         <para>
           Because the <command>mysqldump</command> command made a full
-          backup, these lines mean two things:
+          backup, those lines mean two things:
         </para>
 
         <itemizedlist>
@@ -16763,15 +16763,15 @@
           flushing the logs to begin a new binary log file. For example,
           executing a <command>mysqladmin flush-logs</command> command
           creates <filename>gbichot2-bin.000008</filename>. All changes
-          between the Sunday 1 PM full backup and Monday 1 PM are the
-          file <filename>gbichot2-bin.000007</filename>. This
-          incremental backup is important, so it is a good idea to copy
+          between the Sunday 1 PM full backup and Monday 1 PM will be in
+          the <filename>gbichot2-bin.000007</filename> file. This
+          incremental backup is important, so it's a good idea to copy
           it to a safe place. (For example, back it up on tape or DVD,
-          or copy it to another machine.) On Tuesday 1 PM, execute
+          or copy it to another machine.) On Tuesday at 1 PM, execute
           another <command>mysqladmin flush-logs</command> command. All
-          changes between Monday 1 PM and Tuesday 1 PM are the file
-          <filename>gbichot2-bin.000008</filename> (which also should be
-          copied somewhere safe).
+          changes between Monday 1 PM and Tuesday 1 PM will be in the
+          <filename>gbichot2-bin.000008</filename> file (which also
+          should be copied somewhere safe).
         </para>
 
         <para>
@@ -16782,8 +16782,8 @@
         </para>
 
 <programlisting>
-shell&gt; <userinput>mysqldump --single-transaction --flush-logs --master-data=2</userinput>
-           <userinput>--all-databases --delete-master-logs &gt; backup_sunday_1_PM.sql</userinput>
+shell&gt; <userinput>mysqldump --single-transaction --flush-logs --master-data=2 \</userinput>
+         <userinput>--all-databases --delete-master-logs &gt; backup_sunday_1_PM.sql</userinput>
 </programlisting>
 
         <para>
@@ -16792,9 +16792,6 @@
           --delete-master-logs</command> can be dangerous if your server
           is a replication master server, because slave servers might
           not yet fully have processed the contents of the binary log.
-        </para>
-
-        <para>
           The description for the <literal>PURGE MASTER LOGS</literal>
           statement explains what should be verified before deleting the
           MySQL binary logs. See <xref linkend="purge-master-logs"/>.
@@ -16807,7 +16804,7 @@
         <title>&title-backup-recovery;</title>
 
         <para>
-          Now suppose that we have a catastrophic crash on Wednesday at
+          Now, suppose that we have a catastrophic crash on Wednesday at
           8 AM that requires recovery from backups. To recover, first we
           restore the last full backup we have (the one from Sunday 1
           PM). The full backup file is just a set of SQL statements, so
@@ -16821,7 +16818,7 @@
         <para>
           At this point, the data is restored to its state as of Sunday
           1 PM. To restore the changes made since then, we must use the
-          incremental backups, that is, the
+          incremental backups; that is, the
           <filename>gbichot2-bin.000007</filename> and
           <filename>gbichot2-bin.000008</filename> binary log files.
           Fetch them if necessary from where they were backed up, and

Modified: trunk/refman-4.1/functions.xml
===================================================================
--- trunk/refman-4.1/functions.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/functions.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -5037,7 +5037,7 @@
 
           <para>
             Returns the natural logarithm of
-            <replaceable>X</replaceable>, that is, the
+            <replaceable>X</replaceable>; that is, the
             base-<emphasis>e</emphasis> logarithm of
             <replaceable>X</replaceable>.
           </para>
@@ -9119,7 +9119,7 @@
       columns included in a <literal>FULLTEXT</literal> index. The
       search string is given as the argument to
       <literal>AGAINST()</literal>. For each row in the table,
-      <literal>MATCH()</literal> returns a relevance value, that is, a
+      <literal>MATCH()</literal> returns a relevance value; that is, a
       similarity measure between the search string and the text in that
       row in the columns named in the <literal>MATCH()</literal> list.
     </para>
@@ -10686,7 +10686,7 @@
           </para>
 
           <para>
-            The stopword list is free-form, that is, you may use any
+            The stopword list is free-form. That is, you may use any
             non-alphanumeric character such as newline, space, or comma
             to separate stopwords. Exceptions are the underscore
             character (<literal>_</literal>) and a single apostrophe

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/innodb.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -2469,7 +2469,7 @@
         deletes, or updates many rows, <literal>InnoDB</literal> checks
         <literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
         constraints row-by-row. According to the SQL standard, the
-        default behavior should be deferred checking, that is,
+        default behavior should be deferred checking. That is,
         constraints are only checked after the
         <emphasis role="bold">whole SQL statement</emphasis> has been
         processed. Until <literal>InnoDB</literal> implements deferred
@@ -2752,7 +2752,7 @@
         slave. If the <literal>innodb_file_per_table</literal> variable
         is enabled, you must also copy the <filename>.ibd</filename>
         files as well. For the proper procedure to do this, see
-        <xref linkend="backing-up"/>.
+        <xref linkend="innodb-backup"/>.
       </para>
 
       <para>
@@ -2982,9 +2982,9 @@
 
   </section>
 
-  <section id="backing-up">
+  <section id="innodb-backup">
 
-    <title>&title-backing-up;</title>
+    <title>&title-innodb-backup;</title>
 
     <para>
       The key to safe database management is making regular backups.
@@ -3370,8 +3370,8 @@
       <literal>InnoDB</literal> data and log files are binary-compatible
       on all platforms having the same floating-point number format. You
       can move an <literal>InnoDB</literal> database simply by copying
-      all the relevant files listed in <xref linkend="backing-up"/>. If
-      the floating-point formats differ but you have not used
+      all the relevant files listed in <xref linkend="innodb-backup"/>.
+      If the floating-point formats differ but you have not used
       <literal>FLOAT</literal> or <literal>DOUBLE</literal> data types
       in your tables, then the procedure is the same: simply copy the
       relevant files. If the formats differ and your tables contain
@@ -4148,8 +4148,8 @@
 
       <para>
         Suppose that you are running in the default <literal>REPEATABLE
-        READ</literal> isolation level. When you issue a consistent
-        read, that is, an ordinary <literal>SELECT</literal> statement,
+        READ</literal> isolation level. When you issue a consistent read
+        (that is, an ordinary <literal>SELECT</literal> statement),
         <literal>InnoDB</literal> gives your transaction a timepoint
         according to which your query sees the database. If another
         transaction deletes a row and commits after your timepoint was

Modified: trunk/refman-4.1/introduction.xml
===================================================================
--- trunk/refman-4.1/introduction.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/introduction.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -1011,7 +1011,7 @@
             Schema)</emphasis>: The introduction of the
             <literal>INFORMATION_SCHEMA</literal> database in MySQL 5.0
             provided a standards-compliant means for accessing the MySQL
-            Server's metadata, that is, data about the databases
+            Server's metadata; that is, data about the databases
             (schemas) on the server and the objects which they contain.
           </para>
         </listitem>

Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/ndbcluster.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -8116,7 +8116,7 @@
           command-line utility <command>ndb_restore</command>, which
           reads the files created by the backup and inserts the stored
           information into the database. The restore program must be
-          executed once for each set of backup files, that is, as many
+          executed once for each set of backup files; that is, as many
           times as there were database nodes running when the backup was
           created.
         </para>

Modified: trunk/refman-4.1/renamed-nodes.txt
===================================================================
--- trunk/refman-4.1/renamed-nodes.txt	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/renamed-nodes.txt	2006-01-29 05:00:13 UTC (rev 1096)
@@ -111,3 +111,4 @@
 upgrading-grant-tables mysql-fix-privilege-tables
 secure-grant grant
 secure-requirements secure-using-openssl
+backing-up innodb-backup

Modified: trunk/refman-5.0/apis.xml
===================================================================
--- trunk/refman-5.0/apis.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/apis.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -8056,8 +8056,8 @@
           <para>
             This structure represents a prepared statement. A statement
             is created by calling <literal>mysql_stmt_init()</literal>,
-            which returns a statement handle, that is, a pointer to a
-            <literal>MYSQL_STMT</literal>. The handle is used for all
+            which returns a statement handle (that is, a pointer to a
+            <literal>MYSQL_STMT</literal>). The handle is used for all
             subsequent statement-related functions until you close it
             with <literal>mysql_stmt_close()</literal>.
           </para>
@@ -10120,7 +10120,7 @@
         <para>
           <literal>mysql_stmt_fetch()</literal> returns the next row in
           the result set. It can be called only while the result set
-          exists, that is, after a call to
+          exists; that is, after a call to
           <literal>mysql_stmt_execute()</literal> that creates a result
           set or after <literal>mysql_stmt_store_result()</literal>,
           which is called after <literal>mysql_stmt_execute()</literal>

Modified: trunk/refman-5.0/charset.xml
===================================================================
--- trunk/refman-5.0/charset.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/charset.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -2773,7 +2773,7 @@
       <para>
         The most significant feature in
         <literal>utf8_unicode_ci</literal> is that it supports
-        expansions, that is, when one character compares as equal to
+        expansions; that is, when one character compares as equal to
         combinations of other characters. For example, in German and
         some other languages &lsquo;<literal>ß</literal>&rsquo; is
         equal to &lsquo;<literal>ss</literal>&rsquo;.

Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/database-administration.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -18487,10 +18487,10 @@
       This section discusses how to make database backups (full and
       incremental) and how to perform table maintenance. The syntax of
       the SQL statements described here is given in
-      <xref linkend="database-administration"/>. Much of the information
-      here pertains primarily to <literal>MyISAM</literal> tables.
-      <literal>InnoDB</literal> backup procedures are given in
-      <xref linkend="backing-up"/>.
+      <xref linkend="sql-syntax"/>. Much of the information here
+      pertains primarily to <literal>MyISAM</literal> tables. Additional
+      information about <literal>InnoDB</literal> backup procedures is
+      given in <xref linkend="innodb-backup"/>.
     </para>
 
     <section id="backup">
@@ -18520,13 +18520,11 @@
       </para>
 
       <para>
-        If you want to make an SQL-level backup of a table, you can use
-        <literal>SELECT INTO ... OUTFILE</literal> or <literal>BACKUP
-        TABLE</literal>. For <literal>SELECT INTO ... OUTFILE</literal>,
-        the output file cannot previously exist. This is also true of
-        <literal>BACKUP TABLE</literal> because allowing extant files to
-        be overwritten would constitute a security risk. See
-        <xref linkend="select"/>, and <xref linkend="backup-table"/>.
+        To make an SQL-level backup of a table, you can use
+        <literal>SELECT INTO ... OUTFILE</literal>. For this statement,
+        the output file cannot previously exist because allowing extant
+        files to be overwritten would constitute a security risk. See
+        <xref linkend="select"/>.
       </para>
 
       <para>
@@ -18556,16 +18554,16 @@
 </programlisting>
 
           <para>
-            You can also simply copy all table files
-            (<filename>*.frm</filename>, <filename>*.MYD</filename>, and
-            <filename>*.MYI</filename> files) as long as the server
-            isn't updating anything. The <command>mysqlhotcopy</command>
-            script uses this method. (But note that these methods do not
-            work if your database contains <literal>InnoDB</literal>
-            tables. <literal>InnoDB</literal> does not store table
-            contents in database directories, and
-            <command>mysqlhotcopy</command> works only for
-            <literal>MyISAM</literal> tables.)
+            You can also create a binary backup simply by copying all
+            table files (<filename>*.frm</filename>,
+            <filename>*.MYD</filename>, and <filename>*.MYI</filename>
+            files), as long as the server isn't updating anything. The
+            <command>mysqlhotcopy</command> script uses this method.
+            (But note that these methods do not work if your database
+            contains <literal>InnoDB</literal> tables.
+            <literal>InnoDB</literal> does not store table contents in
+            database directories, and <command>mysqlhotcopy</command>
+            works only for <literal>MyISAM</literal> tables.)
           </para>
         </listitem>
 
@@ -18577,9 +18575,10 @@
             </indexterm>
 
             Stop <command>mysqld</command> if it's running, then start
-            it with the <option>--log-bin[=file_name]</option> option.
-            See <xref linkend="binary-log"/>. The binary log files
-            provide you with the information you need to replicate
+            it with the
+            <option>--log-bin[=<replaceable>file_name</replaceable>]</option>
+            option. See <xref linkend="binary-log"/>. The binary log
+            files provide you with the information you need to replicate
             changes to the database that are made subsequent to the
             point at which you executed <command>mysqldump</command>.
           </para>
@@ -18607,7 +18606,7 @@
         explained further below. The next time you do a full backup, you
         should also rotate the binary log using <literal>FLUSH
         LOGS</literal>, <literal>mysqldump --flush-logs</literal>, or
-        <literal>mysqlhotcopy --flushlogs</literal>. See
+        <literal>mysqlhotcopy --flushlog</literal>. See
         <xref linkend="mysqldump"/>, and <xref linkend="mysqlhotcopy"/>.
       </para>
 
@@ -18635,8 +18634,7 @@
         of all cases. If <command>myisamchk</command> fails, try the
         following procedure. Note that it works only if you have enabled
         binary logging by starting MySQL with the
-        <option>--log-bin</option> option; see
-        <xref linkend="binary-log"/>.
+        <option>--log-bin</option> option.
       </para>
 
       <orderedlist>
@@ -18686,10 +18684,11 @@
 
         <listitem>
           <para>
-            To reload the table, use and restore with <literal>LOAD DATA
-            INFILE 'file_name' REPLACE ...</literal> To avoid duplicate
-            rows, the table must have a <literal>PRIMARY KEY</literal>
-            or a <literal>UNIQUE</literal> index. The
+            To reload the table, use <literal>LOAD DATA INFILE
+            '<replaceable>file_name</replaceable>' REPLACE ...</literal>
+            To avoid duplicate rows, the table must have a
+            <literal>PRIMARY KEY</literal> or a
+            <literal>UNIQUE</literal> index. The
             <literal>REPLACE</literal> keyword causes old rows to be
             replaced with new ones when a new row duplicates an old row
             on a unique key value.
@@ -18858,13 +18857,14 @@
         <title>&title-backup-policy;</title>
 
         <para>
-          We all know that backups must be scheduled periodically. Full
-          backups (a snapshot of the data at a point in time) can be
-          done in MySQL with several tools. For example, <literal>InnoDB
-          Hot Backup</literal> provides online non-blocking physical
-          backup of the <literal>InnoDB</literal> data files, and
-          <command>mysqldump</command> provides online logical backup.
-          This discussion uses <command>mysqldump</command>.
+          We all know that backups must be scheduled periodically. A
+          full backups (a snapshot of the data at a point in time) can
+          be done in MySQL with several tools. For example,
+          <literal>InnoDB Hot Backup</literal> provides online
+          non-blocking physical backup of the <literal>InnoDB</literal>
+          data files, and <command>mysqldump</command> provides online
+          logical backup. This discussion uses
+          <command>mysqldump</command>.
         </para>
 
         <para>
@@ -18951,25 +18951,26 @@
         </para>
 
         <para>
-          The MySQL binary logs are important for recovery, because they
-          are incremental backups. If you make sure to flush the logs
-          when you make your full backup, then any binary log files
-          created afterward contain all the data changes made since the
-          backup. Let's modify the previous <command>mysqldump</command>
-          command a bit so that it flushes the MySQL binary logs at the
-          moment of the full backup, and so that the dump file contains
-          the name of the new current binary log:
+          The MySQL binary logs are important for recovery because they
+          form the set of incremental backups. If you make sure to flush
+          the logs when you make your full backup, then any binary log
+          files created afterward contain all the data changes made
+          since the backup. Let's modify the previous
+          <command>mysqldump</command> command a bit so that it flushes
+          the MySQL binary logs at the moment of the full backup, and so
+          that the dump file contains the name of the new current binary
+          log:
         </para>
 
 <programlisting>
-shell&gt; <userinput>mysqldump --single-transaction --flush-logs --master-data=2</userinput>
-           <userinput>--all-databases &gt; backup_sunday_1_PM.sql</userinput>
+shell&gt; <userinput>mysqldump --single-transaction --flush-logs --master-data=2 \</userinput>
+         <userinput>--all-databases &gt; backup_sunday_1_PM.sql</userinput>
 </programlisting>
 
         <para>
           After executing this command, the data directory contains a
           new binary log file, <filename>gbichot2-bin.000007</filename>.
-          The resulting <filename>.sql</filename> file contains these
+          The resulting <filename>.sql</filename> file includes these
           lines:
         </para>
 
@@ -18980,7 +18981,7 @@
 
         <para>
           Because the <command>mysqldump</command> command made a full
-          backup, these lines mean two things:
+          backup, those lines mean two things:
         </para>
 
         <itemizedlist>
@@ -19010,15 +19011,15 @@
           flushing the logs to begin a new binary log file. For example,
           executing a <command>mysqladmin flush-logs</command> command
           creates <filename>gbichot2-bin.000008</filename>. All changes
-          between the Sunday 1 PM full backup and Monday 1 PM are the
-          file <filename>gbichot2-bin.000007</filename>. This
+          between the Sunday 1 PM full backup and Monday 1 PM will be in
+          the <filename>gbichot2-bin.000007</filename> file. This
           incremental backup is important, so it's a good idea to copy
           it to a safe place. (For example, back it up on tape or DVD,
-          or copy it to another machine.) On Tuesday 1 PM, execute
+          or copy it to another machine.) On Tuesday at 1 PM, execute
           another <command>mysqladmin flush-logs</command> command. All
-          changes between Monday 1 PM and Tuesday 1 PM are the file
-          <filename>gbichot2-bin.000008</filename> (which also should be
-          copied somewhere safe).
+          changes between Monday 1 PM and Tuesday 1 PM will be in the
+          <filename>gbichot2-bin.000008</filename> file (which also
+          should be copied somewhere safe).
         </para>
 
         <para>
@@ -19029,8 +19030,8 @@
         </para>
 
 <programlisting>
-shell&gt; <userinput>mysqldump --single-transaction --flush-logs --master-data=2</userinput>
-           <userinput>--all-databases --delete-master-logs &gt; backup_sunday_1_PM.sql</userinput>
+shell&gt; <userinput>mysqldump --single-transaction --flush-logs --master-data=2 \</userinput>
+         <userinput>--all-databases --delete-master-logs &gt; backup_sunday_1_PM.sql</userinput>
 </programlisting>
 
         <para>
@@ -19039,9 +19040,6 @@
           --delete-master-logs</command> can be dangerous if your server
           is a replication master server, because slave servers might
           not yet fully have processed the contents of the binary log.
-        </para>
-
-        <para>
           The description for the <literal>PURGE MASTER LOGS</literal>
           statement explains what should be verified before deleting the
           MySQL binary logs. See <xref linkend="purge-master-logs"/>.
@@ -19054,7 +19052,7 @@
         <title>&title-backup-recovery;</title>
 
         <para>
-          Now suppose that we have a catastrophic crash on Wednesday at
+          Now, suppose that we have a catastrophic crash on Wednesday at
           8 AM that requires recovery from backups. To recover, first we
           restore the last full backup we have (the one from Sunday 1
           PM). The full backup file is just a set of SQL statements, so
@@ -19068,7 +19066,7 @@
         <para>
           At this point, the data is restored to its state as of Sunday
           1 PM. To restore the changes made since then, we must use the
-          incremental backups, that is, the
+          incremental backups; that is, the
           <filename>gbichot2-bin.000007</filename> and
           <filename>gbichot2-bin.000008</filename> binary log files.
           Fetch them if necessary from where they were backed up, and

Modified: trunk/refman-5.0/functions.xml
===================================================================
--- trunk/refman-5.0/functions.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/functions.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -5124,7 +5124,7 @@
 
           <para>
             Returns the natural logarithm of
-            <replaceable>X</replaceable>, that is, the
+            <replaceable>X</replaceable>; that is, the
             base-<emphasis>e</emphasis> logarithm of
             <replaceable>X</replaceable>.
           </para>
@@ -9218,7 +9218,7 @@
       columns included in a <literal>FULLTEXT</literal> index. The
       search string is given as the argument to
       <literal>AGAINST()</literal>. For each row in the table,
-      <literal>MATCH()</literal> returns a relevance value, that is, a
+      <literal>MATCH()</literal> returns a relevance value; that is, a
       similarity measure between the search string and the text in that
       row in the columns named in the <literal>MATCH()</literal> list.
     </para>
@@ -10786,7 +10786,7 @@
           </para>
 
           <para>
-            The stopword list is free-form, that is, you may use any
+            The stopword list is free-form. That is, you may use any
             non-alphanumeric character such as newline, space, or comma
             to separate stopwords. Exceptions are the underscore
             character (<literal>_</literal>) and a single apostrophe

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/innodb.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -2509,7 +2509,7 @@
         deletes, or updates many rows, <literal>InnoDB</literal> checks
         <literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
         constraints row-by-row. According to the SQL standard, the
-        default behavior should be deferred checking, that is,
+        default behavior should be deferred checking. That is,
         constraints are only checked after the <emphasis>entire SQL
         statement</emphasis> has been processed. Until
         <literal>InnoDB</literal> implements deferred constraint
@@ -2767,7 +2767,7 @@
         slave. If the <literal>innodb_file_per_table</literal> variable
         is enabled, you must also copy the <filename>.ibd</filename>
         files as well. For the proper procedure to do this, see
-        <xref linkend="backing-up"/>.
+        <xref linkend="innodb-backup"/>.
       </para>
 
       <para>
@@ -2959,9 +2959,9 @@
 
   </section>
 
-  <section id="backing-up">
+  <section id="innodb-backup">
 
-    <title>&title-backing-up;</title>
+    <title>&title-innodb-backup;</title>
 
     <para>
       The key to safe database management is making regular backups.
@@ -3336,8 +3336,8 @@
       <literal>InnoDB</literal> data and log files are binary-compatible
       on all platforms having the same floating-point number format. You
       can move an <literal>InnoDB</literal> database simply by copying
-      all the relevant files listed in <xref linkend="backing-up"/>. If
-      the floating-point formats differ but you have not used
+      all the relevant files listed in <xref linkend="innodb-backup"/>.
+      If the floating-point formats differ but you have not used
       <literal>FLOAT</literal> or <literal>DOUBLE</literal> data types
       in your tables, then the procedure is the same: simply copy the
       relevant files. If the formats differ and your tables contain
@@ -4106,8 +4106,8 @@
 
       <para>
         Suppose that you are running in the default <literal>REPEATABLE
-        READ</literal> isolation level. When you issue a consistent
-        read, that is, an ordinary <literal>SELECT</literal> statement,
+        READ</literal> isolation level. When you issue a consistent read
+        (that is, an ordinary <literal>SELECT</literal> statement),
         <literal>InnoDB</literal> gives your transaction a timepoint
         according to which your query sees the database. If another
         transaction deletes a row and commits after your timepoint was

Modified: trunk/refman-5.0/introduction.xml
===================================================================
--- trunk/refman-5.0/introduction.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/introduction.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -404,7 +404,7 @@
             <emphasis role="bold">Information Schema</emphasis>: The
             introduction of the <literal>INFORMATION_SCHEMA</literal>
             database in MySQL 5.0 provided a standards-compliant means
-            for accessing the MySQL Server's metadata, that is, data
+            for accessing the MySQL Server's metadata; that is, data
             about the databases (schemas) on the server and the objects
             which they contain. See
             <xref linkend="information-schema"/>.

Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/ndbcluster.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -8090,7 +8090,7 @@
           command-line utility <command>ndb_restore</command>, which
           reads the files created by the backup and inserts the stored
           information into the database. The restore program must be
-          executed once for each set of backup files, that is, as many
+          executed once for each set of backup files; that is, as many
           times as there were database nodes running when the backup was
           created.
         </para>

Modified: trunk/refman-5.0/precision-math.xml
===================================================================
--- trunk/refman-5.0/precision-math.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/precision-math.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -69,8 +69,8 @@
   </indexterm>
 
   <para>
-    MySQL 5.0 introduces precision math, that is, numeric value handling
-    that results in more accurate results and more control over invalid
+    MySQL 5.0 introduces precision math: numeric value handling that
+    results in more accurate results and more control over invalid
     values than in earlier versions of MySQL. Precision math is based on
     two implementation changes:
   </para>

Modified: trunk/refman-5.0/renamed-nodes.txt
===================================================================
--- trunk/refman-5.0/renamed-nodes.txt	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/renamed-nodes.txt	2006-01-29 05:00:13 UTC (rev 1096)
@@ -411,3 +411,4 @@
 secure-grant grant
 secure-requirements secure-using-openssl
 information-schema-tables information-schema
+backing-up innodb-backup

Modified: trunk/refman-5.1/apis.xml
===================================================================
--- trunk/refman-5.1/apis.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/apis.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -8062,8 +8062,8 @@
           <para>
             This structure represents a prepared statement. A statement
             is created by calling <literal>mysql_stmt_init()</literal>,
-            which returns a statement handle, that is, a pointer to a
-            <literal>MYSQL_STMT</literal>. The handle is used for all
+            which returns a statement handle (that is, a pointer to a
+            <literal>MYSQL_STMT</literal>). The handle is used for all
             subsequent statement-related functions until you close it
             with <literal>mysql_stmt_close()</literal>.
           </para>
@@ -10125,7 +10125,7 @@
         <para>
           <literal>mysql_stmt_fetch()</literal> returns the next row in
           the result set. It can be called only while the result set
-          exists, that is, after a call to
+          exists; that is, after a call to
           <literal>mysql_stmt_execute()</literal> that creates a result
           set or after <literal>mysql_stmt_store_result()</literal>,
           which is called after <literal>mysql_stmt_execute()</literal>

Modified: trunk/refman-5.1/charset.xml
===================================================================
--- trunk/refman-5.1/charset.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/charset.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -2763,7 +2763,7 @@
       <para>
         The most significant feature in
         <literal>utf8_unicode_ci</literal> is that it supports
-        expansions, that is, when one character compares as equal to
+        expansions; that is, when one character compares as equal to
         combinations of other characters. For example, in German and
         some other languages &lsquo;<literal>ß</literal>&rsquo; is
         equal to &lsquo;<literal>ss</literal>&rsquo;.

Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/database-administration.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -18496,10 +18496,10 @@
       This section discusses how to make database backups (full and
       incremental) and how to perform table maintenance. The syntax of
       the SQL statements described here is given in
-      <xref linkend="database-administration"/>. Much of the information
-      here pertains primarily to <literal>MyISAM</literal> tables.
-      <literal>InnoDB</literal> backup procedures are given in
-      <xref linkend="backing-up"/>.
+      <xref linkend="sql-syntax"/>. Much of the information here
+      pertains primarily to <literal>MyISAM</literal> tables. Additional
+      information about <literal>InnoDB</literal> backup procedures is
+      given in <xref linkend="innodb-backup"/>.
     </para>
 
     <section id="backup">
@@ -18529,13 +18529,11 @@
       </para>
 
       <para>
-        If you want to make an SQL-level backup of a table, you can use
-        <literal>SELECT INTO ... OUTFILE</literal> or <literal>BACKUP
-        TABLE</literal>. For <literal>SELECT INTO ... OUTFILE</literal>,
-        the output file cannot previously exist. This is also true of
-        <literal>BACKUP TABLE</literal> because allowing extant files to
-        be overwritten would constitute a security risk. See
-        <xref linkend="select"/>, and <xref linkend="backup-table"/>.
+        To make an SQL-level backup of a table, you can use
+        <literal>SELECT INTO ... OUTFILE</literal>. For this statement,
+        the output file cannot previously exist because allowing extant
+        files to be overwritten would constitute a security risk. See
+        <xref linkend="select"/>.
       </para>
 
       <para>
@@ -18565,16 +18563,16 @@
 </programlisting>
 
           <para>
-            You can also simply copy all table files
-            (<filename>*.frm</filename>, <filename>*.MYD</filename>, and
-            <filename>*.MYI</filename> files) as long as the server
-            isn't updating anything. The <command>mysqlhotcopy</command>
-            script uses this method. (But note that these methods do not
-            work if your database contains <literal>InnoDB</literal>
-            tables. <literal>InnoDB</literal> does not store table
-            contents in database directories, and
-            <command>mysqlhotcopy</command> works only for
-            <literal>MyISAM</literal> tables.)
+            You can also create a binary backup simply by copying all
+            table files (<filename>*.frm</filename>,
+            <filename>*.MYD</filename>, and <filename>*.MYI</filename>
+            files), as long as the server isn't updating anything. The
+            <command>mysqlhotcopy</command> script uses this method.
+            (But note that these methods do not work if your database
+            contains <literal>InnoDB</literal> tables.
+            <literal>InnoDB</literal> does not store table contents in
+            database directories, and <command>mysqlhotcopy</command>
+            works only for <literal>MyISAM</literal> tables.)
           </para>
         </listitem>
 
@@ -18586,9 +18584,10 @@
             </indexterm>
 
             Stop <command>mysqld</command> if it's running, then start
-            it with the <option>--log-bin[=file_name]</option> option.
-            See <xref linkend="binary-log"/>. The binary log files
-            provide you with the information you need to replicate
+            it with the
+            <option>--log-bin[=<replaceable>file_name</replaceable>]</option>
+            option. See <xref linkend="binary-log"/>. The binary log
+            files provide you with the information you need to replicate
             changes to the database that are made subsequent to the
             point at which you executed <command>mysqldump</command>.
           </para>
@@ -18616,7 +18615,7 @@
         explained further below. The next time you do a full backup, you
         should also rotate the binary log using <literal>FLUSH
         LOGS</literal>, <literal>mysqldump --flush-logs</literal>, or
-        <literal>mysqlhotcopy --flushlogs</literal>. See
+        <literal>mysqlhotcopy --flushlog</literal>. See
         <xref linkend="mysqldump"/>, and <xref linkend="mysqlhotcopy"/>.
       </para>
 
@@ -18644,8 +18643,7 @@
         of all cases. If <command>myisamchk</command> fails, try the
         following procedure. Note that it works only if you have enabled
         binary logging by starting MySQL with the
-        <option>--log-bin</option> option; see
-        <xref linkend="binary-log"/>.
+        <option>--log-bin</option> option.
       </para>
 
       <orderedlist>
@@ -18695,10 +18693,11 @@
 
         <listitem>
           <para>
-            To reload the table, use and restore with <literal>LOAD DATA
-            INFILE 'file_name' REPLACE ...</literal> To avoid duplicate
-            rows, the table must have a <literal>PRIMARY KEY</literal>
-            or a <literal>UNIQUE</literal> index. The
+            To reload the table, use <literal>LOAD DATA INFILE
+            '<replaceable>file_name</replaceable>' REPLACE ...</literal>
+            To avoid duplicate rows, the table must have a
+            <literal>PRIMARY KEY</literal> or a
+            <literal>UNIQUE</literal> index. The
             <literal>REPLACE</literal> keyword causes old rows to be
             replaced with new ones when a new row duplicates an old row
             on a unique key value.
@@ -18867,13 +18866,14 @@
         <title>&title-backup-policy;</title>
 
         <para>
-          We all know that backups must be scheduled periodically. Full
-          backups (a snapshot of the data at a point in time) can be
-          done in MySQL with several tools. For example, <literal>InnoDB
-          Hot Backup</literal> provides online non-blocking physical
-          backup of the <literal>InnoDB</literal> data files, and
-          <command>mysqldump</command> provides online logical backup.
-          This discussion uses <command>mysqldump</command>.
+          We all know that backups must be scheduled periodically. A
+          full backups (a snapshot of the data at a point in time) can
+          be done in MySQL with several tools. For example,
+          <literal>InnoDB Hot Backup</literal> provides online
+          non-blocking physical backup of the <literal>InnoDB</literal>
+          data files, and <command>mysqldump</command> provides online
+          logical backup. This discussion uses
+          <command>mysqldump</command>.
         </para>
 
         <para>
@@ -18960,25 +18960,26 @@
         </para>
 
         <para>
-          The MySQL binary logs are important for recovery, because they
-          are incremental backups. If you make sure to flush the logs
-          when you make your full backup, then any binary log files
-          created afterward contain all the data changes made since the
-          backup. Let's modify the previous <command>mysqldump</command>
-          command a bit so that it flushes the MySQL binary logs at the
-          moment of the full backup, and so that the dump file contains
-          the name of the new current binary log:
+          The MySQL binary logs are important for recovery because they
+          form the set of incremental backups. If you make sure to flush
+          the logs when you make your full backup, then any binary log
+          files created afterward contain all the data changes made
+          since the backup. Let's modify the previous
+          <command>mysqldump</command> command a bit so that it flushes
+          the MySQL binary logs at the moment of the full backup, and so
+          that the dump file contains the name of the new current binary
+          log:
         </para>
 
 <programlisting>
-shell&gt; <userinput>mysqldump --single-transaction --flush-logs --master-data=2</userinput>
-           <userinput>--all-databases &gt; backup_sunday_1_PM.sql</userinput>
+shell&gt; <userinput>mysqldump --single-transaction --flush-logs --master-data=2 \</userinput>
+         <userinput>--all-databases &gt; backup_sunday_1_PM.sql</userinput>
 </programlisting>
 
         <para>
           After executing this command, the data directory contains a
           new binary log file, <filename>gbichot2-bin.000007</filename>.
-          The resulting <filename>.sql</filename> file contains these
+          The resulting <filename>.sql</filename> file includes these
           lines:
         </para>
 
@@ -18989,7 +18990,7 @@
 
         <para>
           Because the <command>mysqldump</command> command made a full
-          backup, these lines mean two things:
+          backup, those lines mean two things:
         </para>
 
         <itemizedlist>
@@ -19019,15 +19020,15 @@
           flushing the logs to begin a new binary log file. For example,
           executing a <command>mysqladmin flush-logs</command> command
           creates <filename>gbichot2-bin.000008</filename>. All changes
-          between the Sunday 1 PM full backup and Monday 1 PM are the
-          file <filename>gbichot2-bin.000007</filename>. This
+          between the Sunday 1 PM full backup and Monday 1 PM will be in
+          the <filename>gbichot2-bin.000007</filename> file. This
           incremental backup is important, so it's a good idea to copy
           it to a safe place. (For example, back it up on tape or DVD,
-          or copy it to another machine.) On Tuesday 1 PM, execute
+          or copy it to another machine.) On Tuesday at 1 PM, execute
           another <command>mysqladmin flush-logs</command> command. All
-          changes between Monday 1 PM and Tuesday 1 PM are the file
-          <filename>gbichot2-bin.000008</filename> (which also should be
-          copied somewhere safe).
+          changes between Monday 1 PM and Tuesday 1 PM will be in the
+          <filename>gbichot2-bin.000008</filename> file (which also
+          should be copied somewhere safe).
         </para>
 
         <para>
@@ -19038,8 +19039,8 @@
         </para>
 
 <programlisting>
-shell&gt; <userinput>mysqldump --single-transaction --flush-logs --master-data=2</userinput>
-           <userinput>--all-databases --delete-master-logs &gt; backup_sunday_1_PM.sql</userinput>
+shell&gt; <userinput>mysqldump --single-transaction --flush-logs --master-data=2 \</userinput>
+         <userinput>--all-databases --delete-master-logs &gt; backup_sunday_1_PM.sql</userinput>
 </programlisting>
 
         <para>
@@ -19048,9 +19049,6 @@
           --delete-master-logs</command> can be dangerous if your server
           is a replication master server, because slave servers might
           not yet fully have processed the contents of the binary log.
-        </para>
-
-        <para>
           The description for the <literal>PURGE MASTER LOGS</literal>
           statement explains what should be verified before deleting the
           MySQL binary logs. See <xref linkend="purge-master-logs"/>.
@@ -19063,7 +19061,7 @@
         <title>&title-backup-recovery;</title>
 
         <para>
-          Now suppose that we have a catastrophic crash on Wednesday at
+          Now, suppose that we have a catastrophic crash on Wednesday at
           8 AM that requires recovery from backups. To recover, first we
           restore the last full backup we have (the one from Sunday 1
           PM). The full backup file is just a set of SQL statements, so
@@ -19077,7 +19075,7 @@
         <para>
           At this point, the data is restored to its state as of Sunday
           1 PM. To restore the changes made since then, we must use the
-          incremental backups, that is, the
+          incremental backups; that is, the
           <filename>gbichot2-bin.000007</filename> and
           <filename>gbichot2-bin.000008</filename> binary log files.
           Fetch them if necessary from where they were backed up, and

Modified: trunk/refman-5.1/functions.xml
===================================================================
--- trunk/refman-5.1/functions.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/functions.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -5096,7 +5096,7 @@
 
           <para>
             Returns the natural logarithm of
-            <replaceable>X</replaceable>, that is, the
+            <replaceable>X</replaceable>; that is, the
             base-<emphasis>e</emphasis> logarithm of
             <replaceable>X</replaceable>.
           </para>
@@ -9162,7 +9162,7 @@
       columns included in a <literal>FULLTEXT</literal> index. The
       search string is given as the argument to
       <literal>AGAINST()</literal>. For each row in the table,
-      <literal>MATCH()</literal> returns a relevance value, that is, a
+      <literal>MATCH()</literal> returns a relevance value; that is, a
       similarity measure between the search string and the text in that
       row in the columns named in the <literal>MATCH()</literal> list.
     </para>
@@ -10734,7 +10734,7 @@
           </para>
 
           <para>
-            The stopword list is free-form, that is, you may use any
+            The stopword list is free-form. That is, you may use any
             non-alphanumeric character such as newline, space, or comma
             to separate stopwords. Exceptions are the underscore
             character (<literal>_</literal>) and a single apostrophe

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/innodb.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -2484,7 +2484,7 @@
         deletes, or updates many rows, <literal>InnoDB</literal> checks
         <literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
         constraints row-by-row. According to the SQL standard, the
-        default behavior should be deferred checking, that is,
+        default behavior should be deferred checking. That is,
         constraints are only checked after the <emphasis>entire SQL
         statement</emphasis> has been processed. Until
         <literal>InnoDB</literal> implements deferred constraint
@@ -2742,7 +2742,7 @@
         slave. If the <literal>innodb_file_per_table</literal> variable
         is enabled, you must also copy the <filename>.ibd</filename>
         files as well. For the proper procedure to do this, see
-        <xref linkend="backing-up"/>.
+        <xref linkend="innodb-backup"/>.
       </para>
 
       <para>
@@ -2934,9 +2934,9 @@
 
   </section>
 
-  <section id="backing-up">
+  <section id="innodb-backup">
 
-    <title>&title-backing-up;</title>
+    <title>&title-innodb-backup;</title>
 
     <para>
       The key to safe database management is making regular backups.
@@ -3311,8 +3311,8 @@
       <literal>InnoDB</literal> data and log files are binary-compatible
       on all platforms having the same floating-point number format. You
       can move an <literal>InnoDB</literal> database simply by copying
-      all the relevant files listed in <xref linkend="backing-up"/>. If
-      the floating-point formats differ but you have not used
+      all the relevant files listed in <xref linkend="innodb-backup"/>.
+      If the floating-point formats differ but you have not used
       <literal>FLOAT</literal> or <literal>DOUBLE</literal> data types
       in your tables, then the procedure is the same: simply copy the
       relevant files. If the formats differ and your tables contain
@@ -4081,8 +4081,8 @@
 
       <para>
         Suppose that you are running in the default <literal>REPEATABLE
-        READ</literal> isolation level. When you issue a consistent
-        read, that is, an ordinary <literal>SELECT</literal> statement,
+        READ</literal> isolation level. When you issue a consistent read
+        (that is, an ordinary <literal>SELECT</literal> statement),
         <literal>InnoDB</literal> gives your transaction a timepoint
         according to which your query sees the database. If another
         transaction deletes a row and commits after your timepoint was

Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/ndbcluster.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -8088,7 +8088,7 @@
           command-line utility <command>ndb_restore</command>, which
           reads the files created by the backup and inserts the stored
           information into the database. The restore program must be
-          executed once for each set of backup files, that is, as many
+          executed once for each set of backup files; that is, as many
           times as there were database nodes running when the backup was
           created.
         </para>

Modified: trunk/refman-5.1/partitioning.xml
===================================================================
--- trunk/refman-5.1/partitioning.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/partitioning.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -695,7 +695,7 @@
         number, you can use an expression based on one of the two
         <literal>DATE</literal> columns instead. For example, let us
         suppose that you wish to partition based on the year that each
-        employee left the company, that is, the value of
+        employee left the company; that is, the value of
         <literal>YEAR(separated)</literal>. An example of a
         <literal>CREATE TABLE</literal> statement that implements such a
         partitioning scheme is shown here:

Modified: trunk/refman-5.1/precision-math.xml
===================================================================
--- trunk/refman-5.1/precision-math.xml	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/precision-math.xml	2006-01-29 05:00:13 UTC (rev 1096)
@@ -69,10 +69,10 @@
   </indexterm>
 
   <para>
-    MySQL &current-series; provides support for precision math, that is,
-    numeric value handling that results in extremely accurate results
-    and a high degree control over invalid values. Precision math is
-    based on these two features:
+    MySQL &current-series; provides support for precision math: numeric
+    value handling that results in extremely accurate results and a high
+    degree control over invalid values. Precision math is based on these
+    two features:
   </para>
 
   <itemizedlist>

Modified: trunk/refman-5.1/renamed-nodes.txt
===================================================================
--- trunk/refman-5.1/renamed-nodes.txt	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/renamed-nodes.txt	2006-01-29 05:00:13 UTC (rev 1096)
@@ -115,3 +115,4 @@
 secure-grant grant
 secure-requirements secure-using-openssl
 information-schema-tables information-schema
+backing-up innodb-backup

Modified: trunk/refman-common/titles.en.ent
===================================================================
--- trunk/refman-common/titles.en.ent	2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-common/titles.en.ent	2006-01-29 05:00:13 UTC (rev 1096)
@@ -52,7 +52,6 @@
 <!ENTITY title-arithmetic-functions "Arithmetic Operators">
 <!ENTITY title-asp "ASP and MySQL with MyODBC">
 <!ENTITY title-automatic-start "Starting and Stopping MySQL Automatically">
-<!ENTITY title-backing-up "Backing Up and Recovering an <literal>InnoDB</literal> Database">
 <!ENTITY title-backup "Database Backups">
 <!ENTITY title-backup-policy "Backup Policy">
 <!ENTITY title-backup-recovery "Using Backups for Recovery">
@@ -466,6 +465,7 @@
 <!ENTITY title-innodb-and-autocommit "<literal>InnoDB</literal> and <literal>AUTOCOMMIT</literal>">
 <!ENTITY title-innodb-and-mysql-replication "<literal>InnoDB</literal> and MySQL Replication">
 <!ENTITY title-innodb-auto-increment-column "How <literal>AUTO_INCREMENT</literal> Columns Work in <literal>InnoDB</literal>">
+<!ENTITY title-innodb-backup "Backing Up and Recovering an <literal>InnoDB</literal> Database">
 <!ENTITY title-innodb-change-history "Changes in <literal>InnoDB</literal>">
 <!ENTITY title-innodb-checkpoints "Checkpoints">
 <!ENTITY title-innodb-configuration "<literal>InnoDB</literal> Configuration">

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