List:Commits« Previous MessageNext Message »
From:john.russell Date:September 14 2010 11:37pm
Subject:svn commit - mysqldoc@docsrva: r22722 - trunk/mysql-enterprise-backup-3.5
View as plain text  
Author: jrussell
Date: 2010-09-15 01:37:14 +0200 (Wed, 15 Sep 2010)
New Revision: 22722

Log:
Incorporated a number of review comments from Pekka Lampio.


Modified:
   trunk/mysql-enterprise-backup-3.5/manual.xml


Modified: trunk/mysql-enterprise-backup-3.5/manual.xml
===================================================================
--- trunk/mysql-enterprise-backup-3.5/manual.xml	2010-09-14 22:14:33 UTC (rev 22721)
+++ trunk/mysql-enterprise-backup-3.5/manual.xml	2010-09-14 23:37:14 UTC (rev 22722)
Changed blocks: 11, Lines Added: 35, Lines Deleted: 37; 8066 bytes

@@ -1226,7 +1226,7 @@
         The contents of the backup directory after successfully applying
         the log to the backup is shown below. The
         <literal>&llbackup;</literal> output above shows that data files
-        were rolled forward to log sequence number (lsn) 423500074. Note
+        were rolled forward to log sequence number (lsn) 928223244. Note
         that <literal>&llbackup;</literal> does not modify any of the
         original files in the backup (compressed data files and ibbackup
         log file). This means that nothing is lost if the apply-log

@@ -1728,7 +1728,7 @@
 
       <listitem>
         <para>
-          All same the InnoDB tables, indexes, and so on as
+          All the same InnoDB tables, indexes, and so on as
           <literal>&llbackup;</literal>. (<literal>&hlbackup;</literal>
           runs <literal>&llbackup;</literal> to perform this part of the
           backup.)

@@ -1913,10 +1913,10 @@
         <listitem>
           <para>
             The <literal>&hlbackup;</literal> command is not a true
-            online backup tool, because it issues the command
-            <literal>FLUSH TABLES WITH READ LOCK</literal> at the end of
-            the backup run. For best backup performance and minimal
-            impact on database processing:
+            online backup tool, because it locks all tables while it
+            copies non-InnoDB files at the end of the backup run. For
+            best backup performance and minimal impact on database
+            processing:
           </para>
 
           <orderedlist>

@@ -1941,10 +1941,10 @@
           <para>
             For a large database, a backup run may take a long time.
             Always check that <literal>&hlbackup;</literal> has
-            completed successfully, either by verifying that
-            <literal>&hlbackup;</literal> process has returned with exit
-            code 0, or by observing that <literal>&hlbackup;</literal>
-            has printed the text &quot;innobackup completed OK!&quot;.
+            completed successfully, either by verifying that the
+            <literal>&hlbackup;</literal> command returned exit code 0,
+            or by observing that <literal>&hlbackup;</literal> has
+            printed the text &quot;innobackup completed OK!&quot;.
           </para>
         </listitem>
 

@@ -2419,7 +2419,7 @@
         Here is the backup directory after successfully applying the log
         to the backup. The <literal>&llbackup;</literal> output above
         shows that data files were rolled forward to log sequence number
-        (lsn) <literal>683781754</literal>.
+        (lsn) <literal>928223244</literal>.
       </para>
 
       <screen>

@@ -2652,10 +2652,10 @@
       <para>
         In this example, we use the <literal>&hlbackup;</literal>
         command to make an incremental backup of a database that
-        includes both InnoDB tables and MyISAM tables. The fact that we
-        specify <literal>--lsn 2261747124</literal> on the command line
-        means that the previous backup display this line near the end of
-        the output:
+        includes both InnoDB tables and MyISAM tables. We specify
+        <literal>--lsn 2261747124</literal> on the command line because
+        the previous backup displayed this line near the end of the
+        output:
       </para>
 
       <screen>

@@ -2953,13 +2953,13 @@
     <para>
       <emphasis role="bold">IMPORTANT:</emphasis> Although the
       <literal>&hlbackup;</literal> command supports taking partial
-      backups, you should be careful when restoring a database from a
-      partial backup. <literal>&hlbackup;</literal> copies also the
+      backups, be careful when restoring a database from a partial
+      backup. <literal>&hlbackup;</literal> copies also the
       <literal>.frm</literal> files of those tables that are not
       included in the backup. If you use <literal>&hlbackup;</literal>
-      with <literal>--include</literal> option, you should delete the
-      <literal>.frm</literal> files of those tables that were not
-      included in the backup before trying to restore the database.
+      with <literal>--include</literal> option, before restoring the
+      database, delete from the backup data the <literal>.frm</literal>
+      files for any tables that are not included in the backup.
     </para>
 
     <para>

@@ -2968,8 +2968,8 @@
       expression pattern specified with the <literal>--include</literal>
       option, the backup currently includes
       <emphasis role="italic">all</emphasis> the file-per-table tables.
-      This behavior might change and you should not rely on it as part
-      of your backup procedure.
+      This behavior might change; do not rely on it as part of your
+      backup procedure.
     </para>
 
     <section remap="h2" id="partial.uncompressed">

@@ -3396,7 +3396,7 @@
         <literal>.myi</literal>, <literal>.mrg</literal>, and so on.
         (See the <link linkend="known-file-extensions">full list of
         extensions</link>.) By default, the
-        <literal>&hlbackup;</literal> command backs up all all file
+        <literal>&hlbackup;</literal> command backs up all file
         extensions within the data directory, which could include files
         produced by many different storage engines. Use this option if
         the additional data files from other storage engines should not

@@ -3413,14 +3413,13 @@
         The <literal>--exec-when-locked</literal> option of the
         <literal>&hlbackup;</literal> command lets you specify a command
         and arguments to run near the end of the backup, while the
-        database is still locked. This command can pull files into the
-        data directory that are then included in the backup. For
-        example, you can use this option to back up
-        <literal>MEMORY</literal> tables with the
-        <literal>mysqldump</literal> command, storing the output in the
-        backup directory. If you want any redirection or variable
-        substitution to be delayed until the command is executed,
-        enclose the entire parameter value within single quotes.
+        database is still locked. This command can copy or create
+        additional files in the backup directory. For example, you can
+        use this option to back up <literal>MEMORY</literal> tables with
+        the <literal>mysqldump</literal> command, storing the output in
+        the backup directory. To delay any redirection or variable
+        substitution until the command is executed, enclose the entire
+        parameter value within single quotes.
       </para>
 
     </section>

@@ -4148,16 +4147,15 @@
       <para>
         If you take a backup when there are <literal>TEMPORARY</literal>
         tables in the database, and you use those temporary tables to
-        update or insert into normal tables, then the MySQL binlog
-        application to a backup can fail. That is, you may not be able
-        to roll forward the backup using the MySQL binlog. The reason is
+        update or insert into normal tables, then applying the MySQL
+        binlog to a backup can fail. That is, you may not be able to
+        roll forward the backup using the MySQL binlog. The reason is
         that <literal>TEMPORARY</literal> tables are not copied to the
         backup. And, actually we cannot copy them to the backup, because
         the names of temporary table files <literal>#sql*.frm</literal>
         do not correspond to the logical table names that MySQL writes
-        to the binlog. This problem will be removed in the future, when
-        MySQL will implement so-called <quote>row-level
-        binlogging</quote>.
+        to the binlog. This problem might be removed in the future, if
+        MySQL implements <quote>row-level binlogging</quote>.
       </para>
 
       <para>


Thread
svn commit - mysqldoc@docsrva: r22722 - trunk/mysql-enterprise-backup-3.5john.russell15 Sep