MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:jon Date:October 29 2007 6:08pm
Subject:svn commit - mysqldoc@docsrva: r8389 - in trunk: refman-4.1 refman-5.0 refman-5.1 refman-5.2
View as plain text  
Author: jstephens
Date: 2007-10-29 19:08:20 +0100 (Mon, 29 Oct 2007)
New Revision: 8389

Log:

For hot backups of InnoDB tables, use InnoDB Hot Backup

Fixes Docs Bug #31867




Modified:
   trunk/refman-4.1/replication.xml
   trunk/refman-5.0/replication-configuration.xml
   trunk/refman-5.1/replication-configuration.xml
   trunk/refman-5.2/replication-configuration.xml


Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml	2007-10-29 18:04:45 UTC (rev 8388)
+++ trunk/refman-4.1/replication.xml	2007-10-29 18:08:20 UTC (rev 8389)
Changed blocks: 2, Lines Added: 26, Lines Deleted: 68; 5480 bytes

@@ -779,25 +779,35 @@
 </programlisting>
 
         <para>
-          For <literal>InnoDB</literal> tables, note that <literal>FLUSH
-          TABLES WITH READ LOCK</literal> blocks
-          <literal>COMMIT</literal> operations, too. (This is true as of
-          MySQL version 4.0.20.) When you have acquired your global read
-          lock, you can start a filesystem snapshot of your
-          <literal>InnoDB</literal> tables. Internally (inside the
-          <literal>InnoDB</literal> storage engine) the snapshot won't
-          be consistent (because the <literal>InnoDB</literal> caches
-          are not flushed), but there's no need to worry at all, because
-          <literal>InnoDB</literal> will resolve this at startup, and
-          consequently deliver a consistent result. This means that
-          <literal>InnoDB</literal> will perform a crash recovery when
-          started on this snapshot, but it will not be corrupted. If you
-          want to have a consistent snapshot of your
-          <literal>InnoDB</literal> tables, there's no way around taking
-          down the MySQL server, though.
+          For example, if you are using <literal>InnoDB</literal>
+          tables, you should use the <command><literal>InnoDB</literal>
+          Hot Backup</command> tool to obtain a consistent snapshot.
+          This tool records the log name and offset corresponding to the
+          snapshot to be later used on the slave. <command>Hot
+          Backup</command> is a non-free (commercial) tool that is not
+          included in the standard MySQL distribution. See the
+          <command><literal>InnoDB</literal> Hot Backup</command> home
+          page at <ulink url="http://www.innodb.com/hot-backup"/> for
+          detailed information.
         </para>
 
         <para>
+          Otherwise, you can obtain a reliable binary snapshot of
+          <literal>InnoDB</literal> tables only after shutting down the
+          MySQL Server.
+        </para>
+
+        <para>
+          An alternative that works for both <literal>MyISAM</literal>
+          and <literal>InnoDB</literal> tables is to take an SQL dump of
+          the master instead of a binary copy as described in the
+          preceding discussion. For this, you can use <command>mysqldump
+          --master-data</command> on your master and later load the SQL
+          dump file into your slave. However, this is slower than doing
+          a binary copy.
+        </para>
+
+        <para>
           Leave running the client from which you issue the
           <literal>FLUSH TABLES</literal> statement so that the read
           lock remains in effect. (If you exit the client, the lock is

@@ -894,58 +904,6 @@
 <programlisting>
 mysql&gt; <userinput>UNLOCK TABLES;</userinput>
 </programlisting>
-
-        <para>
-          If you are using <literal>InnoDB</literal> tables, ideally you
-          should use the <command><literal>InnoDB</literal> Hot
-          Backup</command> tool, which takes a consistent snapshot
-          without acquiring any locks on the master server, and records
-          the log name and offset corresponding to the snapshot to be
-          later used on the slave. <command>Hot Backup</command> is an
-          additional non-free (commercial) tool that is not included in
-          the standard MySQL distribution. See the
-          <command><literal>InnoDB</literal> Hot Backup</command> home
-          page at <ulink url="http://www.innodb.com/hot-backup"/> for
-          detailed information.
-        </para>
-
-        <para>
-          Without the <command>Hot Backup</command> tool, the quickest
-          way to take a binary snapshot of <literal>InnoDB</literal>
-          tables is to shut down the master server and copy the
-          <literal>InnoDB</literal> data files, log files, and table
-          format files (<filename>.frm</filename> files). To record the
-          current log file name and offset, you should issue the
-          following statements before you shut down the server:
-        </para>
-
-<programlisting>
-mysql&gt; <userinput>FLUSH TABLES WITH READ LOCK;</userinput>
-mysql&gt; <userinput>SHOW MASTER STATUS;</userinput>
-</programlisting>
-
-        <para>
-          Then record the log name and the offset from the output of
-          <literal>SHOW MASTER STATUS</literal> as was shown earlier.
-          After recording the log name and the offset, shut down the
-          server <emphasis>without</emphasis> unlocking the tables to
-          make sure that the server goes down with the snapshot
-          corresponding to the current log file and offset:
-        </para>
-
-<programlisting>
-shell&gt; <userinput>mysqladmin -u root shutdown</userinput>
-</programlisting>
-
-        <para>
-          An alternative that works for both <literal>MyISAM</literal>
-          and <literal>InnoDB</literal> tables is to take an SQL dump of
-          the master instead of a binary copy as described in the
-          preceding discussion. For this, you can use <command>mysqldump
-          --master-data</command> on your master and later load the SQL
-          dump file into your slave. However, this is slower than doing
-          a binary copy.
-        </para>
       </listitem>
 
       <listitem>


Modified: trunk/refman-5.0/replication-configuration.xml
===================================================================
--- trunk/refman-5.0/replication-configuration.xml	2007-10-29 18:04:45 UTC (rev 8388)
+++ trunk/refman-5.0/replication-configuration.xml	2007-10-29 18:08:20 UTC (rev 8389)
Changed blocks: 6, Lines Added: 54, Lines Deleted: 56; 8290 bytes

@@ -606,39 +606,45 @@
 
       <para>
         However, using this method with tables in storage engines with
-        complex cache and/or logging algorithms may not give you a
-        perfect 'in time' snapshot as cache information and logging
+        complex caching or logging algorithms may not give you a perfect
+        <quote>in time</quote> snapshot as cache information and logging
         updates may not have been applied, even if you have acquired a
-        global read lock. How the storage engine responds to this will
-        depend on the crash recovery abilities.
+        global read lock. How the storage engine responds to this
+        depends on its crash recovery abilities.
       </para>
 
       <para>
-        For example, when you have acquired a global read lock, you can
-        start a filesystem snapshot of your <literal>InnoDB</literal>
-        tables. Internally (inside the <literal>InnoDB</literal> storage
-        engine) the snapshot won't be consistent (because the
-        <literal>InnoDB</literal> caches are not flushed), but this is
-        not a cause for concern, because <literal>InnoDB</literal>
-        resolves this at startup and delivers a consistent result. This
-        means that <literal>InnoDB</literal> can perform crash recovery
-        when started on this snapshot, without corruption. However,
-        there is no way to stop the MySQL server while insuring a
-        consistent snapshot of your <literal>InnoDB</literal> tables.
+        For example, if you are using <literal>InnoDB</literal> tables,
+        you should use the <command><literal>InnoDB</literal> Hot
+        Backup</command> tool to obtain a consistent snapshot. This tool
+        records the log name and offset corresponding to the snapshot to
+        be later used on the slave. <command>Hot Backup</command> is a
+        non-free (commercial) tool that is not included in the standard
+        MySQL distribution. See the <command><literal>InnoDB</literal>
+        Hot Backup</command> home page at
+        <ulink url="http://www.innodb.com/hot-backup"/> for detailed
+        information.
       </para>
 
       <para>
-        To create your raw data snapshot you can use standard copy tools
-        such as <command>cp</command> or <command>copy</command>, a
-        remote copy tool such as <command>scp</command> or
-        <command>rsync</command> an archiving tool such as
-        <command>zip</command> or <command>tar</command>, or a file
-        system snapshot tool such as <command>dump</command>, providing
-        that your MySQL data files exist on a single filesystem. If you
-        are only replicating certain databases then make sure you only
-        copy those files that related to those tables. For InnoDB, all
+        Otherwise, you can obtain a reliable binary snapshot of
+        <literal>InnoDB</literal> tables only after shutting down the
+        MySQL Server.
+      </para>
+
+      <para>
+        To create a raw data snapshot of <literal>MyISAM</literal>
+        tables you can use standard copy tools such as
+        <command>cp</command> or <command>copy</command>, a remote copy
+        tool such as <command>scp</command> or <command>rsync</command>
+        an archiving tool such as <command>zip</command> or
+        <command>tar</command>, or a file system snapshot tool such as
+        <command>dump</command>, providing that your MySQL data files
+        exist on a single filesystem. If you are only replicating
+        certain databases then make sure you only copy those files that
+        related to those tables. (For <literal>InnoDB</literal>, all
         tables in all databases are stored in a single file unless you
-        have the <option>innodb_file_per_table</option> option enabled.
+        have the <option>innodb_file_per_table</option> option enabled.)
       </para>
 
       <para>

@@ -656,13 +662,13 @@
 
         <listitem>
           <para>
-            The <literal>master.info</literal> file.
+            The <filename>master.info</filename> file.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            The master's binary log files.
+            The master&apos;s binary log files.
           </para>
         </listitem>
 

@@ -683,18 +689,19 @@
 
         <listitem>
           <para>
-            Acquire a read lock and get the master status. See
-            <xref
-  linkend="replication-howto-masterstatus"/>.
+            Acquire a read lock and get the master&apos;s status. See
+            <xref linkend="replication-howto-masterstatus"/>.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            In a separate session, shutdown the MySQL server:
+            In a separate session, shut down the MySQL server:
           </para>
 
-<programlisting>shell&gt; mysqladmin shutdown</programlisting>
+<programlisting>
+shell&gt; mysqladmin shutdown
+</programlisting>
         </listitem>
 
         <listitem>

@@ -704,7 +711,8 @@
             these solutions:
           </para>
 
-<programlisting>shell&gt; tar cf <replaceable>/tmp/db.tar</replaceable> <replaceable>./data</replaceable>
+<programlisting>
+shell&gt; tar cf <replaceable>/tmp/db.tar</replaceable> <replaceable>./data</replaceable>
 shell&gt; zip -r <replaceable>/tmp/db.zip</replaceable> <replaceable>./data</replaceable>
 shell&gt; rsync --recursive <replaceable>./data</replaceable> <replaceable>/tmp/dbdata</replaceable>
 </programlisting>

@@ -712,24 +720,24 @@
 
         <listitem>
           <para>
-            Startup the MySQL instance on the master.
+            Start up the MySQL instance on the master.
           </para>
         </listitem>
 
       </orderedlist>
 
       <para>
-        To get a snapshot of the system from a master without shutting
-        down the database:
+        If you are not using <literal>InnoDB</literal> tables, you can
+        get a snapshot of the system from a master without shutting down
+        the server as described in the following steps:
       </para>
 
       <orderedlist>
 
         <listitem>
           <para>
-            Acquire a read lock and get the master status. See
-            <xref
-              linkend="replication-howto-masterstatus"/>.
+            Acquire a read lock and get the master&apos;s status. See
+            <xref linkend="replication-howto-masterstatus"/>.
           </para>
         </listitem>
 

@@ -740,32 +748,22 @@
             these solutions:
           </para>
 
-<programlisting>shell&gt; tar cf <replaceable>/tmp/db.tar</replaceable> <replaceable>./data</replaceable>
+<programlisting>
+shell&gt; tar cf <replaceable>/tmp/db.tar</replaceable> <replaceable>./data</replaceable>
 shell&gt; zip -r <replaceable>/tmp/db.zip</replaceable> <replaceable>./data</replaceable>
 shell&gt; rsync --recursive <replaceable>./data</replaceable> <replaceable>/tmp/dbdata</replaceable>
 </programlisting>
-
-          <para>
-            If you are using <literal>InnoDB</literal> tables, ideally
-            you should use the <command><literal>InnoDB</literal> Hot
-            Backup</command> tool, which takes a consistent snapshot
-            without acquiring any locks on the master server, and
-            records the log name and offset corresponding to the
-            snapshot to be later used on the slave. <command>Hot
-            Backup</command> is an additional non-free (commercial) tool
-            that is not included in the standard MySQL distribution. See
-            the <command><literal>InnoDB</literal> Hot Backup</command>
-            home page at <ulink url="http://www.innodb.com/hot-backup"/>
-            for detailed information.
-          </para>
         </listitem>
 
         <listitem>
           <para>
-            In the client where you acquired read lock, free the lock:
+            In the client where you acquired the read lock, free the
+            lock:
           </para>
 
-<programlisting>mysql&gt; UNLOCK TABLES;</programlisting>
+<programlisting>
+mysql&gt; UNLOCK TABLES;
+</programlisting>
         </listitem>
 
       </orderedlist>


Modified: trunk/refman-5.1/replication-configuration.xml
===================================================================
--- trunk/refman-5.1/replication-configuration.xml	2007-10-29 18:04:45 UTC (rev 8388)
+++ trunk/refman-5.1/replication-configuration.xml	2007-10-29 18:08:20 UTC (rev 8389)
Changed blocks: 6, Lines Added: 54, Lines Deleted: 56; 8290 bytes

@@ -619,39 +619,45 @@
 
       <para>
         However, using this method with tables in storage engines with
-        complex cache and/or logging algorithms may not give you a
-        perfect 'in time' snapshot as cache information and logging
+        complex caching or logging algorithms may not give you a perfect
+        <quote>in time</quote> snapshot as cache information and logging
         updates may not have been applied, even if you have acquired a
-        global read lock. How the storage engine responds to this will
-        depend on the crash recovery abilities.
+        global read lock. How the storage engine responds to this
+        depends on its crash recovery abilities.
       </para>
 
       <para>
-        For example, when you have acquired a global read lock, you can
-        start a filesystem snapshot of your <literal>InnoDB</literal>
-        tables. Internally (inside the <literal>InnoDB</literal> storage
-        engine) the snapshot won't be consistent (because the
-        <literal>InnoDB</literal> caches are not flushed), but this is
-        not a cause for concern, because <literal>InnoDB</literal>
-        resolves this at startup and delivers a consistent result. This
-        means that <literal>InnoDB</literal> can perform crash recovery
-        when started on this snapshot, without corruption. However,
-        there is no way to stop the MySQL server while insuring a
-        consistent snapshot of your <literal>InnoDB</literal> tables.
+        For example, if you are using <literal>InnoDB</literal> tables,
+        you should use the <command><literal>InnoDB</literal> Hot
+        Backup</command> tool to obtain a consistent snapshot. This tool
+        records the log name and offset corresponding to the snapshot to
+        be later used on the slave. <command>Hot Backup</command> is a
+        non-free (commercial) tool that is not included in the standard
+        MySQL distribution. See the <command><literal>InnoDB</literal>
+        Hot Backup</command> home page at
+        <ulink url="http://www.innodb.com/hot-backup"/> for detailed
+        information.
       </para>
 
       <para>
-        To create your raw data snapshot you can use standard copy tools
-        such as <command>cp</command> or <command>copy</command>, a
-        remote copy tool such as <command>scp</command> or
-        <command>rsync</command> an archiving tool such as
-        <command>zip</command> or <command>tar</command>, or a file
-        system snapshot tool such as <command>dump</command>, providing
-        that your MySQL data files exist on a single filesystem. If you
-        are only replicating certain databases then make sure you only
-        copy those files that related to those tables. For InnoDB, all
+        Otherwise, you can obtain a reliable binary snapshot of
+        <literal>InnoDB</literal> tables only after shutting down the
+        MySQL Server.
+      </para>
+
+      <para>
+        To create a raw data snapshot of <literal>MyISAM</literal>
+        tables you can use standard copy tools such as
+        <command>cp</command> or <command>copy</command>, a remote copy
+        tool such as <command>scp</command> or <command>rsync</command>
+        an archiving tool such as <command>zip</command> or
+        <command>tar</command>, or a file system snapshot tool such as
+        <command>dump</command>, providing that your MySQL data files
+        exist on a single filesystem. If you are only replicating
+        certain databases then make sure you only copy those files that
+        related to those tables. (For <literal>InnoDB</literal>, all
         tables in all databases are stored in a single file unless you
-        have the <option>innodb_file_per_table</option> option enabled.
+        have the <option>innodb_file_per_table</option> option enabled.)
       </para>
 
       <para>

@@ -669,13 +675,13 @@
 
         <listitem>
           <para>
-            The <literal>master.info</literal> file.
+            The <filename>master.info</filename> file.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            The master's binary log files.
+            The master&apos;s binary log files.
           </para>
         </listitem>
 

@@ -696,18 +702,19 @@
 
         <listitem>
           <para>
-            Acquire a read lock and get the master status. See
-            <xref
-  linkend="replication-howto-masterstatus"/>.
+            Acquire a read lock and get the master&apos;s status. See
+            <xref linkend="replication-howto-masterstatus"/>.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            In a separate session, shutdown the MySQL server:
+            In a separate session, shut down the MySQL server:
           </para>
 
-<programlisting>shell&gt; mysqladmin shutdown</programlisting>
+<programlisting>
+shell&gt; mysqladmin shutdown
+</programlisting>
         </listitem>
 
         <listitem>

@@ -717,7 +724,8 @@
             these solutions:
           </para>
 
-<programlisting>shell&gt; tar cf <replaceable>/tmp/db.tar</replaceable> <replaceable>./data</replaceable>
+<programlisting>
+shell&gt; tar cf <replaceable>/tmp/db.tar</replaceable> <replaceable>./data</replaceable>
 shell&gt; zip -r <replaceable>/tmp/db.zip</replaceable> <replaceable>./data</replaceable>
 shell&gt; rsync --recursive <replaceable>./data</replaceable> <replaceable>/tmp/dbdata</replaceable>
 </programlisting>

@@ -725,24 +733,24 @@
 
         <listitem>
           <para>
-            Startup the MySQL instance on the master.
+            Start up the MySQL instance on the master.
           </para>
         </listitem>
 
       </orderedlist>
 
       <para>
-        To get a snapshot of the system from a master without shutting
-        down the database:
+        If you are not using <literal>InnoDB</literal> tables, you can
+        get a snapshot of the system from a master without shutting down
+        the server as described in the following steps:
       </para>
 
       <orderedlist>
 
         <listitem>
           <para>
-            Acquire a read lock and get the master status. See
-            <xref
-              linkend="replication-howto-masterstatus"/>.
+            Acquire a read lock and get the master&apos;s status. See
+            <xref linkend="replication-howto-masterstatus"/>.
           </para>
         </listitem>
 

@@ -753,32 +761,22 @@
             these solutions:
           </para>
 
-<programlisting>shell&gt; tar cf <replaceable>/tmp/db.tar</replaceable> <replaceable>./data</replaceable>
+<programlisting>
+shell&gt; tar cf <replaceable>/tmp/db.tar</replaceable> <replaceable>./data</replaceable>
 shell&gt; zip -r <replaceable>/tmp/db.zip</replaceable> <replaceable>./data</replaceable>
 shell&gt; rsync --recursive <replaceable>./data</replaceable> <replaceable>/tmp/dbdata</replaceable>
 </programlisting>
-
-          <para>
-            If you are using <literal>InnoDB</literal> tables, ideally
-            you should use the <command><literal>InnoDB</literal> Hot
-            Backup</command> tool, which takes a consistent snapshot
-            without acquiring any locks on the master server, and
-            records the log name and offset corresponding to the
-            snapshot to be later used on the slave. <command>Hot
-            Backup</command> is an additional non-free (commercial) tool
-            that is not included in the standard MySQL distribution. See
-            the <command><literal>InnoDB</literal> Hot Backup</command>
-            home page at <ulink url="http://www.innodb.com/hot-backup"/>
-            for detailed information.
-          </para>
         </listitem>
 
         <listitem>
           <para>
-            In the client where you acquired read lock, free the lock:
+            In the client where you acquired the read lock, free the
+            lock:
           </para>
 
-<programlisting>mysql&gt; UNLOCK TABLES;</programlisting>
+<programlisting>
+mysql&gt; UNLOCK TABLES;
+</programlisting>
         </listitem>
 
       </orderedlist>


Modified: trunk/refman-5.2/replication-configuration.xml
===================================================================
--- trunk/refman-5.2/replication-configuration.xml	2007-10-29 18:04:45 UTC (rev 8388)
+++ trunk/refman-5.2/replication-configuration.xml	2007-10-29 18:08:20 UTC (rev 8389)
Changed blocks: 5, Lines Added: 49, Lines Deleted: 54; 7696 bytes

@@ -619,39 +619,45 @@
 
       <para>
         However, using this method with tables in storage engines with
-        complex cache and/or logging algorithms may not give you a
-        perfect 'in time' snapshot as cache information and logging
+        complex caching or logging algorithms may not give you a perfect
+        <quote>in time</quote> snapshot as cache information and logging
         updates may not have been applied, even if you have acquired a
-        global read lock. How the storage engine responds to this will
-        depend on the crash recovery abilities.
+        global read lock. How the storage engine responds to this
+        depends on its crash recovery abilities.
       </para>
 
       <para>
-        For example, when you have acquired a global read lock, you can
-        start a filesystem snapshot of your <literal>InnoDB</literal>
-        tables. Internally (inside the <literal>InnoDB</literal> storage
-        engine) the snapshot won't be consistent (because the
-        <literal>InnoDB</literal> caches are not flushed), but this is
-        not a cause for concern, because <literal>InnoDB</literal>
-        resolves this at startup and delivers a consistent result. This
-        means that <literal>InnoDB</literal> can perform crash recovery
-        when started on this snapshot, without corruption. However,
-        there is no way to stop the MySQL server while insuring a
-        consistent snapshot of your <literal>InnoDB</literal> tables.
+        For example, if you are using <literal>InnoDB</literal> tables,
+        you should use the <command><literal>InnoDB</literal> Hot
+        Backup</command> tool to obtain a consistent snapshot. This tool
+        records the log name and offset corresponding to the snapshot to
+        be later used on the slave. <command>Hot Backup</command> is a
+        non-free (commercial) tool that is not included in the standard
+        MySQL distribution. See the <command><literal>InnoDB</literal>
+        Hot Backup</command> home page at
+        <ulink url="http://www.innodb.com/hot-backup"/> for detailed
+        information.
       </para>
 
       <para>
-        To create your raw data snapshot you can use standard copy tools
-        such as <command>cp</command> or <command>copy</command>, a
-        remote copy tool such as <command>scp</command> or
-        <command>rsync</command> an archiving tool such as
-        <command>zip</command> or <command>tar</command>, or a file
-        system snapshot tool such as <command>dump</command>, providing
-        that your MySQL data files exist on a single filesystem. If you
-        are only replicating certain databases then make sure you only
-        copy those files that related to those tables. For InnoDB, all
+        Otherwise, you can obtain a reliable binary snapshot of
+        <literal>InnoDB</literal> tables only after shutting down the
+        MySQL Server.
+      </para>
+
+      <para>
+        To create a raw data snapshot of <literal>MyISAM</literal>
+        tables you can use standard copy tools such as
+        <command>cp</command> or <command>copy</command>, a remote copy
+        tool such as <command>scp</command> or <command>rsync</command>
+        an archiving tool such as <command>zip</command> or
+        <command>tar</command>, or a file system snapshot tool such as
+        <command>dump</command>, providing that your MySQL data files
+        exist on a single filesystem. If you are only replicating
+        certain databases then make sure you only copy those files that
+        related to those tables. (For <literal>InnoDB</literal>, all
         tables in all databases are stored in a single file unless you
-        have the <option>innodb_file_per_table</option> option enabled.
+        have the <option>innodb_file_per_table</option> option enabled.)
       </para>
 
       <para>

@@ -669,13 +675,13 @@
 
         <listitem>
           <para>
-            The <literal>master.info</literal> file.
+            The <filename>master.info</filename> file.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            The master's binary log files.
+            The master&apos;s binary log files.
           </para>
         </listitem>
 

@@ -696,15 +702,14 @@
 
         <listitem>
           <para>
-            Acquire a read lock and get the master status. See
-            <xref
-  linkend="replication-howto-masterstatus"/>.
+            Acquire a read lock and get the master&apos;s status. See
+            <xref linkend="replication-howto-masterstatus"/>.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            In a separate session, shutdown the MySQL server:
+            In a separate session, shut down the MySQL server:
           </para>
 
 <programlisting>shell&gt; mysqladmin shutdown</programlisting>

@@ -725,24 +730,24 @@
 
         <listitem>
           <para>
-            Startup the MySQL instance on the master.
+            Start up the MySQL instance on the master.
           </para>
         </listitem>
 
       </orderedlist>
 
       <para>
-        To get a snapshot of the system from a master without shutting
-        down the database:
+        If you are not using <literal>InnoDB</literal> tables, you can
+        get a snapshot of the system from a master without shutting down
+        the server as described in the following steps:
       </para>
 
       <orderedlist>
 
         <listitem>
           <para>
-            Acquire a read lock and get the master status. See
-            <xref
-              linkend="replication-howto-masterstatus"/>.
+            Acquire a read lock and get the master&apos;s status. See
+            <xref linkend="replication-howto-masterstatus"/>.
           </para>
         </listitem>
 

@@ -753,32 +758,22 @@
             these solutions:
           </para>
 
-<programlisting>shell&gt; tar cf <replaceable>/tmp/db.tar</replaceable> <replaceable>./data</replaceable>
+<programlisting>
+shell&gt; tar cf <replaceable>/tmp/db.tar</replaceable> <replaceable>./data</replaceable>
 shell&gt; zip -r <replaceable>/tmp/db.zip</replaceable> <replaceable>./data</replaceable>
 shell&gt; rsync --recursive <replaceable>./data</replaceable> <replaceable>/tmp/dbdata</replaceable>
 </programlisting>
-
-          <para>
-            If you are using <literal>InnoDB</literal> tables, ideally
-            you should use the <command><literal>InnoDB</literal> Hot
-            Backup</command> tool, which takes a consistent snapshot
-            without acquiring any locks on the master server, and
-            records the log name and offset corresponding to the
-            snapshot to be later used on the slave. <command>Hot
-            Backup</command> is an additional non-free (commercial) tool
-            that is not included in the standard MySQL distribution. See
-            the <command><literal>InnoDB</literal> Hot Backup</command>
-            home page at <ulink url="http://www.innodb.com/hot-backup"/>
-            for detailed information.
-          </para>
         </listitem>
 
         <listitem>
           <para>
-            In the client where you acquired read lock, free the lock:
+            In the client where you acquired the read lock, free the
+            lock:
           </para>
 
-<programlisting>mysql&gt; UNLOCK TABLES;</programlisting>
+<programlisting>
+mysql&gt; UNLOCK TABLES;
+</programlisting>
         </listitem>
 
       </orderedlist>


Thread
svn commit - mysqldoc@docsrva: r8389 - in trunk: refman-4.1 refman-5.0 refman-5.1 refman-5.2jon29 Oct