Author: paul
Date: 2008-10-16 17:56:03 +0200 (Thu, 16 Oct 2008)
New Revision: 12084
Log:
r34797@dhcp-100: paul | 2008-10-16 10:56:53 -0500
Fix docs bug:
Bug#37141: Doc page does not account for consequences of FLUSH TABLES WITH
READ LOCK
Modified:
trunk/refman-4.1/backup.xml
trunk/refman-4.1/programs-client.xml
trunk/refman-5.0/backup.xml
trunk/refman-5.0/programs-client-core.xml
trunk/refman-5.1/backup.xml
trunk/refman-5.1/programs-client-core.xml
trunk/refman-6.0/backup.xml
trunk/refman-6.0/programs-client-core.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:34789
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:33695
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:34797
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:33695
Modified: trunk/refman-4.1/backup.xml
===================================================================
--- trunk/refman-4.1/backup.xml 2008-10-16 15:50:41 UTC (rev 12083)
+++ trunk/refman-4.1/backup.xml 2008-10-16 15:56:03 UTC (rev 12084)
Changed blocks: 1, Lines Added: 23, Lines Deleted: 13; 2672 bytes
@@ -908,22 +908,32 @@
</programlisting>
<para>
- This is an online, non-blocking backup that does not disturb the
- reads and writes on the tables. We assumed earlier that our
- tables are <literal>InnoDB</literal> tables, so
- <option>--single-transaction</option> uses a consistent read and
- guarantees that data seen by <command>mysqldump</command> does
- not change. (Changes made by other clients to
- <literal>InnoDB</literal> tables are not seen by the
- <command>mysqldump</command> process.) If we do also have other
- types of tables, we must assume that they are not changed during
- the backup. For example, for the <literal>MyISAM</literal>
- tables in the <literal>mysql</literal> database, we must assume
- that no administrative changes are being made to MySQL accounts
- during the backup.
+ This backup acquires a global read lock on all tables (using
+ <literal>FLUSH TABLES WITH READ LOCK</literal>) at the beginning
+ of the dump. As soon as this lock has been acquired, the binary
+ log coordinates are read and the lock is released. If long
+ updating statements are running when the
+ <literal>FLUSH</literal> statement is issued, the MySQL server
+ may get stalled until those statements finish. After that, the
+ dump becomes lock-free and does not disturb reads and writes on
+ the tables.
</para>
<para>
+ We assumed earlier that our tables are <literal>InnoDB</literal>
+ tables, so <option>--single-transaction</option> uses a
+ consistent read and guarantees that data seen by
+ <command>mysqldump</command> does not change. (Changes made by
+ other clients to <literal>InnoDB</literal> tables are not seen
+ by the <command>mysqldump</command> process.) If we do also have
+ other types of tables, we must assume that they are not changed
+ during the backup. For example, for the
+ <literal>MyISAM</literal> tables in the <literal>mysql</literal>
+ database, we must assume that no administrative changes are
+ being made to MySQL accounts during the backup.
+ </para>
+
+ <para>
The resulting <filename>.sql</filename> file produced by
<command>mysqldump</command> contains a set of SQL
<literal>INSERT</literal> statements that can be used to reload
Modified: trunk/refman-4.1/programs-client.xml
===================================================================
--- trunk/refman-4.1/programs-client.xml 2008-10-16 15:50:41 UTC (rev 12083)
+++ trunk/refman-4.1/programs-client.xml 2008-10-16 15:56:03 UTC (rev 12084)
Changed blocks: 1, Lines Added: 11, Lines Deleted: 11; 1825 bytes
@@ -6970,17 +6970,17 @@
</programlisting>
<para>
- This backup just needs to acquire a global read lock on all
- tables (using <literal>FLUSH TABLES WITH READ LOCK</literal>) at
- the beginning of the dump. As soon as this lock has been
- acquired, the binary log coordinates are read and the lock is
- released. If and only if one long updating statement is running
- when the <literal>FLUSH</literal> statement is issued, the MySQL
- server may get stalled until that long statement finishes, and
- then the dump becomes lock-free. If the update statements that
- the MySQL server receives are short (in terms of execution
- time), the initial lock period should not be noticeable, even
- with many updates.
+ This backup acquires a global read lock on all tables (using
+ <literal>FLUSH TABLES WITH READ LOCK</literal>) at the beginning
+ of the dump. As soon as this lock has been acquired, the binary
+ log coordinates are read and the lock is released. If long
+ updating statements are running when the
+ <literal>FLUSH</literal> statement is issued, the MySQL server
+ may get stalled until those statements finish. After that, the
+ dump becomes lock-free and does not disturb reads and writes on
+ the tables. If the update statements that the MySQL server
+ receives are short (in terms of execution time), the initial
+ lock period should not be noticeable, even with many updates.
</para>
<para>
Modified: trunk/refman-5.0/backup.xml
===================================================================
--- trunk/refman-5.0/backup.xml 2008-10-16 15:50:41 UTC (rev 12083)
+++ trunk/refman-5.0/backup.xml 2008-10-16 15:56:03 UTC (rev 12084)
Changed blocks: 1, Lines Added: 23, Lines Deleted: 13; 2672 bytes
@@ -901,22 +901,32 @@
</programlisting>
<para>
- This is an online, non-blocking backup that does not disturb the
- reads and writes on the tables. We assumed earlier that our
- tables are <literal>InnoDB</literal> tables, so
- <option>--single-transaction</option> uses a consistent read and
- guarantees that data seen by <command>mysqldump</command> does
- not change. (Changes made by other clients to
- <literal>InnoDB</literal> tables are not seen by the
- <command>mysqldump</command> process.) If we do also have other
- types of tables, we must assume that they are not changed during
- the backup. For example, for the <literal>MyISAM</literal>
- tables in the <literal>mysql</literal> database, we must assume
- that no administrative changes are being made to MySQL accounts
- during the backup.
+ This backup acquires a global read lock on all tables (using
+ <literal>FLUSH TABLES WITH READ LOCK</literal>) at the beginning
+ of the dump. As soon as this lock has been acquired, the binary
+ log coordinates are read and the lock is released. If long
+ updating statements are running when the
+ <literal>FLUSH</literal> statement is issued, the MySQL server
+ may get stalled until those statements finish. After that, the
+ dump becomes lock-free and does not disturb reads and writes on
+ the tables.
</para>
<para>
+ We assumed earlier that our tables are <literal>InnoDB</literal>
+ tables, so <option>--single-transaction</option> uses a
+ consistent read and guarantees that data seen by
+ <command>mysqldump</command> does not change. (Changes made by
+ other clients to <literal>InnoDB</literal> tables are not seen
+ by the <command>mysqldump</command> process.) If we do also have
+ other types of tables, we must assume that they are not changed
+ during the backup. For example, for the
+ <literal>MyISAM</literal> tables in the <literal>mysql</literal>
+ database, we must assume that no administrative changes are
+ being made to MySQL accounts during the backup.
+ </para>
+
+ <para>
The resulting <filename>.sql</filename> file produced by
<command>mysqldump</command> contains a set of SQL
<literal>INSERT</literal> statements that can be used to reload
Modified: trunk/refman-5.0/programs-client-core.xml
===================================================================
--- trunk/refman-5.0/programs-client-core.xml 2008-10-16 15:50:41 UTC (rev 12083)
+++ trunk/refman-5.0/programs-client-core.xml 2008-10-16 15:56:03 UTC (rev 12084)
Changed blocks: 1, Lines Added: 11, Lines Deleted: 11; 1840 bytes
@@ -7495,17 +7495,17 @@
</programlisting>
<para>
- This backup just needs to acquire a global read lock on all
- tables (using <literal>FLUSH TABLES WITH READ LOCK</literal>) at
- the beginning of the dump. As soon as this lock has been
- acquired, the binary log coordinates are read and the lock is
- released. If and only if one long updating statement is running
- when the <literal>FLUSH</literal> statement is issued, the MySQL
- server may get stalled until that long statement finishes, and
- then the dump becomes lock-free. If the update statements that
- the MySQL server receives are short (in terms of execution
- time), the initial lock period should not be noticeable, even
- with many updates.
+ This backup acquires a global read lock on all tables (using
+ <literal>FLUSH TABLES WITH READ LOCK</literal>) at the beginning
+ of the dump. As soon as this lock has been acquired, the binary
+ log coordinates are read and the lock is released. If long
+ updating statements are running when the
+ <literal>FLUSH</literal> statement is issued, the MySQL server
+ may get stalled until those statements finish. After that, the
+ dump becomes lock-free and does not disturb reads and writes on
+ the tables. If the update statements that the MySQL server
+ receives are short (in terms of execution time), the initial
+ lock period should not be noticeable, even with many updates.
</para>
<para>
Modified: trunk/refman-5.1/backup.xml
===================================================================
--- trunk/refman-5.1/backup.xml 2008-10-16 15:50:41 UTC (rev 12083)
+++ trunk/refman-5.1/backup.xml 2008-10-16 15:56:03 UTC (rev 12084)
Changed blocks: 1, Lines Added: 23, Lines Deleted: 13; 2672 bytes
@@ -910,22 +910,32 @@
</programlisting>
<para>
- This is an online, non-blocking backup that does not disturb the
- reads and writes on the tables. We assumed earlier that our
- tables are <literal>InnoDB</literal> tables, so
- <option>--single-transaction</option> uses a consistent read and
- guarantees that data seen by <command>mysqldump</command> does
- not change. (Changes made by other clients to
- <literal>InnoDB</literal> tables are not seen by the
- <command>mysqldump</command> process.) If we do also have other
- types of tables, we must assume that they are not changed during
- the backup. For example, for the <literal>MyISAM</literal>
- tables in the <literal>mysql</literal> database, we must assume
- that no administrative changes are being made to MySQL accounts
- during the backup.
+ This backup acquires a global read lock on all tables (using
+ <literal>FLUSH TABLES WITH READ LOCK</literal>) at the beginning
+ of the dump. As soon as this lock has been acquired, the binary
+ log coordinates are read and the lock is released. If long
+ updating statements are running when the
+ <literal>FLUSH</literal> statement is issued, the MySQL server
+ may get stalled until those statements finish. After that, the
+ dump becomes lock-free and does not disturb reads and writes on
+ the tables.
</para>
<para>
+ We assumed earlier that our tables are <literal>InnoDB</literal>
+ tables, so <option>--single-transaction</option> uses a
+ consistent read and guarantees that data seen by
+ <command>mysqldump</command> does not change. (Changes made by
+ other clients to <literal>InnoDB</literal> tables are not seen
+ by the <command>mysqldump</command> process.) If we do also have
+ other types of tables, we must assume that they are not changed
+ during the backup. For example, for the
+ <literal>MyISAM</literal> tables in the <literal>mysql</literal>
+ database, we must assume that no administrative changes are
+ being made to MySQL accounts during the backup.
+ </para>
+
+ <para>
The resulting <filename>.sql</filename> file produced by
<command>mysqldump</command> contains a set of SQL
<literal>INSERT</literal> statements that can be used to reload
Modified: trunk/refman-5.1/programs-client-core.xml
===================================================================
--- trunk/refman-5.1/programs-client-core.xml 2008-10-16 15:50:41 UTC (rev 12083)
+++ trunk/refman-5.1/programs-client-core.xml 2008-10-16 15:56:03 UTC (rev 12084)
Changed blocks: 1, Lines Added: 11, Lines Deleted: 11; 1840 bytes
@@ -7754,17 +7754,17 @@
</programlisting>
<para>
- This backup just needs to acquire a global read lock on all
- tables (using <literal>FLUSH TABLES WITH READ LOCK</literal>) at
- the beginning of the dump. As soon as this lock has been
- acquired, the binary log coordinates are read and the lock is
- released. If and only if one long updating statement is running
- when the <literal>FLUSH</literal> statement is issued, the MySQL
- server may get stalled until that long statement finishes, and
- then the dump becomes lock-free. If the update statements that
- the MySQL server receives are short (in terms of execution
- time), the initial lock period should not be noticeable, even
- with many updates.
+ This backup acquires a global read lock on all tables (using
+ <literal>FLUSH TABLES WITH READ LOCK</literal>) at the beginning
+ of the dump. As soon as this lock has been acquired, the binary
+ log coordinates are read and the lock is released. If long
+ updating statements are running when the
+ <literal>FLUSH</literal> statement is issued, the MySQL server
+ may get stalled until those statements finish. After that, the
+ dump becomes lock-free and does not disturb reads and writes on
+ the tables. If the update statements that the MySQL server
+ receives are short (in terms of execution time), the initial
+ lock period should not be noticeable, even with many updates.
</para>
<para>
Modified: trunk/refman-6.0/backup.xml
===================================================================
--- trunk/refman-6.0/backup.xml 2008-10-16 15:50:41 UTC (rev 12083)
+++ trunk/refman-6.0/backup.xml 2008-10-16 15:56:03 UTC (rev 12084)
Changed blocks: 1, Lines Added: 23, Lines Deleted: 13; 2672 bytes
@@ -918,22 +918,32 @@
</programlisting>
<para>
- This is an online, non-blocking backup that does not disturb the
- reads and writes on the tables. We assumed earlier that our
- tables are <literal>InnoDB</literal> tables, so
- <option>--single-transaction</option> uses a consistent read and
- guarantees that data seen by <command>mysqldump</command> does
- not change. (Changes made by other clients to
- <literal>InnoDB</literal> tables are not seen by the
- <command>mysqldump</command> process.) If we do also have other
- types of tables, we must assume that they are not changed during
- the backup. For example, for the <literal>MyISAM</literal>
- tables in the <literal>mysql</literal> database, we must assume
- that no administrative changes are being made to MySQL accounts
- during the backup.
+ This backup acquires a global read lock on all tables (using
+ <literal>FLUSH TABLES WITH READ LOCK</literal>) at the beginning
+ of the dump. As soon as this lock has been acquired, the binary
+ log coordinates are read and the lock is released. If long
+ updating statements are running when the
+ <literal>FLUSH</literal> statement is issued, the MySQL server
+ may get stalled until those statements finish. After that, the
+ dump becomes lock-free and does not disturb reads and writes on
+ the tables.
</para>
<para>
+ We assumed earlier that our tables are <literal>InnoDB</literal>
+ tables, so <option>--single-transaction</option> uses a
+ consistent read and guarantees that data seen by
+ <command>mysqldump</command> does not change. (Changes made by
+ other clients to <literal>InnoDB</literal> tables are not seen
+ by the <command>mysqldump</command> process.) If we do also have
+ other types of tables, we must assume that they are not changed
+ during the backup. For example, for the
+ <literal>MyISAM</literal> tables in the <literal>mysql</literal>
+ database, we must assume that no administrative changes are
+ being made to MySQL accounts during the backup.
+ </para>
+
+ <para>
The resulting <filename>.sql</filename> file produced by
<command>mysqldump</command> contains a set of SQL
<literal>INSERT</literal> statements that can be used to reload
Modified: trunk/refman-6.0/programs-client-core.xml
===================================================================
Changed blocks: 0, Lines Added: 0, Lines Deleted: 0; 118 bytes
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r12084 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul.dubois | 16 Oct |
