Author: paul
Date: 2006-01-10 19:03:14 +0100 (Tue, 10 Jan 2006)
New Revision: 757
Log:
r6058@frost: paul | 2006-01-10 11:55:28 -0600
General revisions.
Modified:
trunk/
trunk/refman-4.1/innodb.xml
trunk/refman-5.0/innodb.xml
trunk/refman-5.1/innodb.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6057
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6058
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml 2006-01-10 18:02:56 UTC (rev 756)
+++ trunk/refman-4.1/innodb.xml 2006-01-10 18:03:14 UTC (rev 757)
@@ -1443,10 +1443,11 @@
</para>
<para>
- This value should currently be set to 0. Because recovery from
- a backup is done by MySQL using its own log files, there is no
- need to archive <literal>InnoDB</literal> log files. The
- default for this variable is 0.
+ Whether to log <literal>InnoDB</literal> archive files. This
+ variable is unused. Recovery from a backup is done by MySQL
+ using its own log files, so there is no need to archive
+ <literal>InnoDB</literal> log files. The default for this
+ variable is 0.
</para>
</listitem>
@@ -1491,7 +1492,7 @@
<para>
The number of log files in the log group.
<literal>InnoDB</literal> writes to the files in a circular
- fashion. The default is 2 (recommended).
+ fashion. The default (and recommended) is 2.
</para>
</listitem>
@@ -1521,14 +1522,8 @@
90. The main thread in <literal>InnoDB</literal> tries to
write pages from the buffer pool so that the percentage of
dirty (not yet written) pages will not exceed this value.
- Available starting from 4.0.13 and 4.1.1. If you have the
- <literal>SUPER</literal> privilege, this percentage can be
- changed while the server is running:
+ Available starting from 4.0.13 and 4.1.1.
</para>
-
-<programlisting>
-SET GLOBAL innodb_max_dirty_pages_pct = <replaceable>value</replaceable>;
-</programlisting>
</listitem>
<listitem>
@@ -1539,11 +1534,11 @@
<para>
This variable controls how to delay <literal>INSERT</literal>,
<literal>UPDATE</literal> and <literal>DELETE</literal>
- operations when the purge operations (see
- <xref linkend="innodb-multi-versioning"/>) are lagging. The
- default value of this variable is 0, meaning that there are no
- delays. <literal>innodb_max_purge_lag</literal> is available
- as of MySQL 4.0.22 and 4.1.6.
+ operations when the purge operations are lagging (see
+ <xref linkend="innodb-multi-versioning"/>). The default value
+ of this variable is 0, meaning that there are no delays.
+ <literal>innodb_max_purge_lag</literal> is available as of
+ MySQL 4.0.22 and 4.1.6.
</para>
<para>
@@ -1556,7 +1551,7 @@
<literal>innodb_max_purge_lag</literal>, each
<literal>INSERT</literal>, <literal>UPDATE</literal> and
<literal>DELETE</literal> operation is delayed by
- ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)*10)-5
+ ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)×10)−5
milliseconds. The delay is computed in the beginning of a
purge batch, every ten seconds. The operations are not delayed
if purge cannot run because of an old consistent read view
@@ -1640,9 +1635,8 @@
internally to take a table lock. In applications using
<literal>AUTOCOMMIT=1</literal>, <literal>InnoDB</literal>'s
internal table locks can cause deadlocks. You can set
- <literal>innodb_table_locks=0</literal> in
- <filename>my.cnf</filename> (or <filename>my.ini</filename> on
- Windows) to remove that problem.
+ <literal>innodb_table_locks=0</literal> in the server option
+ file to remove that problem.
</para>
</listitem>
Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml 2006-01-10 18:02:56 UTC (rev 756)
+++ trunk/refman-5.0/innodb.xml 2006-01-10 18:03:14 UTC (rev 757)
@@ -1453,10 +1453,12 @@
</para>
<para>
- This value should currently be set to 0. Because recovery from
- a backup is done by MySQL using its own log files, there is
- currently no need to archive <literal>InnoDB</literal> log
- files. The default for this variable is 0.
+ Whether to log <literal>InnoDB</literal> archive files. This
+ variable is present for historical reasons, but is unused.
+ Recovery from a backup is done by MySQL using its own log
+ files, so there is no need to archive
+ <literal>InnoDB</literal> log files. The default for this
+ variable is 0.
</para>
</listitem>
@@ -1501,7 +1503,7 @@
<para>
The number of log files in the log group.
<literal>InnoDB</literal> writes to the files in a circular
- fashion. The default is 2 (recommended).
+ fashion. The default (and recommended) is 2.
</para>
</listitem>
@@ -1530,14 +1532,8 @@
This is an integer in the range from 0 to 100. The default is
90. The main thread in <literal>InnoDB</literal> tries to
write pages from the buffer pool so that the percentage of
- dirty (not yet written) pages will not exceed this value. If
- you have the <literal>SUPER</literal> privilege, this
- percentage can be changed while the server is running:
+ dirty (not yet written) pages will not exceed this value.
</para>
-
-<programlisting>
-SET GLOBAL innodb_max_dirty_pages_pct = <replaceable>value</replaceable>;
-</programlisting>
</listitem>
<listitem>
@@ -1548,10 +1544,9 @@
<para>
This variable controls how to delay <literal>INSERT</literal>,
<literal>UPDATE</literal> and <literal>DELETE</literal>
- operations when the purge operations (see
- <xref linkend="innodb-multi-versioning"/>) are lagging. The
- default value of this variable is 0, meaning that there are no
- delays.
+ operations when the purge operations are lagging (see
+ <xref linkend="innodb-multi-versioning"/>). The default value
+ of this variable is 0, meaning that there are no delays.
</para>
<para>
@@ -1564,7 +1559,7 @@
<literal>innodb_max_purge_lag</literal>, each
<literal>INSERT</literal>, <literal>UPDATE</literal> and
<literal>DELETE</literal> operation is delayed by
- ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)*10)-5
+ ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)×10)−5
milliseconds. The delay is computed in the beginning of a
purge batch, every ten seconds. The operations are not delayed
if purge cannot run because of an old consistent read view
@@ -1671,8 +1666,7 @@
applications using <literal>AUTOCOMMIT=1</literal>,
<literal>InnoDB</literal>'s internal table locks can cause
deadlocks. You can set <literal>innodb_table_locks=0</literal>
- in <filename>my.cnf</filename> (or <filename>my.ini</filename>
- on Windows) to remove that problem.
+ in the server option file to remove that problem.
</para>
</listitem>
@@ -1700,20 +1694,18 @@
</para>
</listitem>
-<!--
<listitem>
- <remark role="todo">
- document innodb_thread_sleep_delay
- </remark>
-
<para>
<literal>innodb_thread_sleep_delay</literal>
</para>
<para>
+ How long <literal>InnoDB</literal> threads sleep before
+ joining the <literal>InnoDB</literal> queue, in microseconds.
+ The default value is 10,000. A value of 0 disables sleep. This
+ variable was added in MySQL 5.0.3.
</para>
</listitem>
--->
<listitem>
<para>
Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml 2006-01-10 18:02:56 UTC (rev 756)
+++ trunk/refman-5.1/innodb.xml 2006-01-10 18:03:14 UTC (rev 757)
@@ -1445,10 +1445,12 @@
</para>
<para>
- This value should currently be set to 0. Because recovery from
- a backup is done by MySQL using its own log files, there is
- currently no need to archive <literal>InnoDB</literal> log
- files. The default for this variable is 0.
+ Whether to log <literal>InnoDB</literal> archive files. This
+ variable is present for historical reasons, but is unused.
+ Recovery from a backup is done by MySQL using its own log
+ files, so there is no need to archive
+ <literal>InnoDB</literal> log files. The default for this
+ variable is 0.
</para>
</listitem>
@@ -1493,7 +1495,7 @@
<para>
The number of log files in the log group.
<literal>InnoDB</literal> writes to the files in a circular
- fashion. The default is 2 (recommended).
+ fashion. The default (and recommended) is 2.
</para>
</listitem>
@@ -1522,14 +1524,8 @@
This is an integer in the range from 0 to 100. The default is
90. The main thread in <literal>InnoDB</literal> tries to
write pages from the buffer pool so that the percentage of
- dirty (not yet written) pages will not exceed this value. If
- you have the <literal>SUPER</literal> privilege, this
- percentage can be changed while the server is running:
+ dirty (not yet written) pages will not exceed this value.
</para>
-
-<programlisting>
-SET GLOBAL innodb_max_dirty_pages_pct = <replaceable>value</replaceable>;
-</programlisting>
</listitem>
<listitem>
@@ -1540,10 +1536,9 @@
<para>
This variable controls how to delay <literal>INSERT</literal>,
<literal>UPDATE</literal> and <literal>DELETE</literal>
- operations when the purge operations (see
- <xref linkend="innodb-multi-versioning"/>) are lagging. The
- default value of this variable is 0, meaning that there are no
- delays.
+ operations when the purge operations are lagging (see
+ <xref linkend="innodb-multi-versioning"/>). The default value
+ of this variable is 0, meaning that there are no delays.
</para>
<para>
@@ -1556,7 +1551,7 @@
<literal>innodb_max_purge_lag</literal>, each
<literal>INSERT</literal>, <literal>UPDATE</literal> and
<literal>DELETE</literal> operation is delayed by
- ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)*10)-5
+ ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)×10)−5
milliseconds. The delay is computed in the beginning of a
purge batch, every ten seconds. The operations are not delayed
if purge cannot run because of an old consistent read view
@@ -1648,8 +1643,7 @@
applications using <literal>AUTOCOMMIT=1</literal>,
<literal>InnoDB</literal>'s internal table locks can cause
deadlocks. You can set <literal>innodb_table_locks=0</literal>
- in <filename>my.cnf</filename> (or <filename>my.ini</filename>
- on Windows) to remove that problem.
+ in the server option file to remove that problem.
</para>
</listitem>
@@ -1676,20 +1670,17 @@
</para>
</listitem>
-<!--
- <listitem>
- <remark role="todo">
- document innodb_thread_sleep_delay
- </remark>
-
+ <listitem>
<para>
- <literal>innodb_thread_sleep_delay</literal>
+ <literal>innodb_thread_sleep_delay</literal>
</para>
-
+
<para>
+ How long <literal>InnoDB</literal> threads sleep before
+ joining the <literal>InnoDB</literal> queue, in microseconds.
+ The default value is 10,000. A value of 0 disables sleep.
</para>
- </listitem>
- -->
+ </listitem>
<listitem>
<para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r757 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 10 Jan |
