Author: paul
Date: 2006-01-10 19:02:56 +0100 (Tue, 10 Jan 2006)
New Revision: 756
Log:
r6057@frost: paul | 2006-01-10 11:31:01 -0600
General revisions.
Modified:
trunk/
trunk/refman-4.1/database-administration.xml
trunk/refman-4.1/innodb.xml
trunk/refman-5.0/database-administration.xml
trunk/refman-5.0/innodb.xml
trunk/refman-5.1/database-administration.xml
trunk/refman-5.1/innodb.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6056
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6057
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml 2006-01-10 18:02:38 UTC (rev 755)
+++ trunk/refman-4.1/database-administration.xml 2006-01-10 18:02:56 UTC (rev 756)
@@ -7070,8 +7070,9 @@
</para>
<para>
- If positive, the MySQL server synchronizes its binary log
- to disk (<literal>fdatasync()</literal>) after every
+ If the value of this variable is positive, the MySQL
+ server synchronizes its binary log to disk
+ (<literal>fdatasync()</literal>) after every
<literal>sync_binlog</literal>'th write to this binary
log. Note that there is one write to the binary log per
statement if in autocommit mode, and otherwise one write
Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml 2006-01-10 18:02:38 UTC (rev 755)
+++ trunk/refman-4.1/innodb.xml 2006-01-10 18:02:56 UTC (rev 756)
@@ -1092,7 +1092,7 @@
<para>
The increment size (in MB) for extending the size of an
auto-extending tablespace when it becomes full. The default
- value is 8. This option is available starting from MySQL
+ value is 8. This variable is available starting from MySQL
4.0.24 and 4.1.5. As of MySQL 4.0.24 and 4.1.6, it can be
changed at runtime as a global system variable.
</para>
@@ -1107,14 +1107,15 @@
The size of the buffer pool (in MB), if it is placed in the
AWE memory. This is relevant only in 32-bit Windows. If your
32-bit Windows operating system supports more than 4GB memory,
- so-called <quote>Address Windowing Extensions,</quote> you can
- allocate the <literal>InnoDB</literal> buffer pool into the
- AWE physical memory using this parameter. The maximum possible
- value for this is 63000. If this parameter is specified,
- <literal>innodb_buffer_pool_size</literal> is the window in
- the 32-bit address space of <command>mysqld</command> where
- <literal>InnoDB</literal> maps that AWE memory. A good value
- for <literal>innodb_buffer_pool_size</literal> is 500MB. This
+ using so-called <quote>Address Windowing Extensions</quote>,
+ you can allocate the <literal>InnoDB</literal> buffer pool
+ into the AWE physical memory using this variable. The maximum
+ possible value for this variable is 63000. If it is greater
+ than 0, <literal>innodb_buffer_pool_size</literal> is the
+ window in the 32-bit address space of
+ <command>mysqld</command> where <literal>InnoDB</literal> maps
+ that AWE memory. A good value for
+ <literal>innodb_buffer_pool_size</literal> is 500MB. This
variable is available as of MySQL 4.1.0.
</para>
@@ -1188,12 +1189,12 @@
</para>
<para>
- If you set this to 0, <literal>InnoDB</literal> does a full
- purge and an insert buffer merge before a shutdown. These
- operations can take minutes, or even hours in extreme cases.
- If you set this parameter to 1, <literal>InnoDB</literal>
- skips these operations at shutdown. The default value is 1
- starting from 3.23.50.
+ If you set this variable to 0, <literal>InnoDB</literal> does
+ a full purge and an insert buffer merge before a shutdown.
+ These operations can take minutes, or even hours in extreme
+ cases. If you set this variable to 1,
+ <literal>InnoDB</literal> skips these operations at shutdown.
+ The default value is 1 starting from 3.23.50.
</para>
</listitem>
@@ -1207,8 +1208,8 @@
Normally this should be left at the default value of 4, but
disk I/O on Windows may benefit from a larger number. On Unix,
increasing the number has no effect; <literal>InnoDB</literal>
- always uses the default value. This option is available as of
- MySQL 3.23.37.
+ always uses the default value. This variable is available as
+ of MySQL 3.23.37.
</para>
</listitem>
@@ -1232,11 +1233,12 @@
</para>
<para>
- This option causes <literal>InnoDB</literal> to create each
- new table using its own <filename>.ibd</filename> file for
- storing data and indexes, rather than in the shared
+ If this variable is enabled, <literal>InnoDB</literal> creates
+ each new table using its own <filename>.ibd</filename> file
+ for storing data and indexes, rather than in the shared
+ tablespace. The default is to create tables in the shared
tablespace. See <xref linkend="multiple-tablespaces"/>. This
- option is available as of MySQL 4.1.1.
+ variable is available as of MySQL 4.1.1.
</para>
</listitem>
@@ -1247,42 +1249,48 @@
<para>
When <literal>innodb_flush_log_at_trx_commit</literal> is set
- to 0, once per second the log buffer is written out to the log
- file, and the flush to disk operation is performed on the log
+ to 0, the log buffer is written out to the log file once per
+ second and the flush to disk operation is performed on the log
file, but nothing is done at a transaction commit. When this
- value is 1 (the default), at each transaction commit the log
- buffer is written out to the log file, and the flush to disk
- operation is performed on the log file. When set to 2, at each
- commit the log buffer is written out to the file, but the
+ value is 1 (the default), the log buffer is written out to the
+ log file at each transaction commit and the flush to disk
+ operation is performed on the log file. When set to 2, the log
+ buffer is written out to the file at each commit, but the
flush to disk operation is not performed on it. However, the
- flushing on the log file takes place once per second also in
- the case of 2. We must note that the once-per-second flushing
- is not 100% guaranteed to happen every second, due to process
- scheduling issues. You can achieve better performance by
- setting the value different from 1, but then you can lose at
- most one second worth of transactions in a crash. If you set
- the value to 0, then any <command>mysqld</command> process
- crash can erase the last second of transactions. If you set
- the value to 2, then only an operating system crash or a power
- outage can erase the last second of transactions. However,
- <literal>InnoDB</literal>'s crash recovery is not affected and
- thus crash recovery does work regardless of the value. Note
- that many operating systems and some disk hardware fool the
- flush-to-disk operation. They may tell
- <command>mysqld</command> that the flush has taken place,
- though it has not. Then the durability of transactions is not
- guaranteed even with the setting 1, and in the worst case a
- power outage can even corrupt the <literal>InnoDB</literal>
- database. Using a battery-backed disk cache in the SCSI disk
- controller or in the disk itself speeds up file flushes, and
- makes the operation safer. You can also try using the Unix
- command <command>hdparm</command> to disable the caching of
- disk writes in hardware caches, or use some other command
- specific to the hardware vendor. The default value of this
- option is 1 (prior to MySQL 4.0.13, the default is 0).
+ flushing on the log file takes place once per second also when
+ the value is 2. Note that the once-per-second flushing is not
+ 100% guaranteed to happen every second, due to process
+ scheduling issues.
</para>
<para>
+ The default value of this variable is 1, which is the value
+ that is required for ACID compliance. You can achieve better
+ performance by setting the value different from 1, but then
+ you can lose at most one second worth of transactions in a
+ crash. If you set the value to 0, then any
+ <command>mysqld</command> process crash can erase the last
+ second of transactions. If you set the value to 2, then only
+ an operating system crash or a power outage can erase the last
+ second of transactions. However, <literal>InnoDB</literal>'s
+ crash recovery is not affected and thus crash recovery does
+ work regardless of the value. Note that many operating systems
+ and some disk hardware fool the flush-to-disk operation. They
+ may tell <command>mysqld</command> that the flush has taken
+ place, though it has not. Then the durability of transactions
+ is not guaranteed even with the setting 1, and in the worst
+ case a power outage can even corrupt the
+ <literal>InnoDB</literal> database. Using a battery-backed
+ disk cache in the SCSI disk controller or in the disk itself
+ speeds up file flushes, and makes the operation safer. You can
+ also try using the Unix command <command>hdparm</command> to
+ disable the caching of disk writes in hardware caches, or use
+ some other command specific to the hardware vendor. The
+ default value of this variable is 1 (prior to MySQL 4.0.13,
+ the default is 0).
+ </para>
+
+ <para>
For the greatest possible durability and consistency in a
replication setup you should use
<literal>innodb_flush_log_at_trx_commit=1</literal>,
@@ -1313,8 +1321,10 @@
<literal>fsync()</literal> instead of
<literal>fdatasync()</literal>, and it does not use
<literal>O_DSYNC</literal> by default because there have been
- problems with them on many Unix flavors. This option is
- available as of MySQL 3.23.40.
+ problems with it on many varieties of Unix. This variable is
+ relevant only for Unix. On Windows, the flush method is always
+ <literal>async_unbuffered</literal> and cannot be changed.
+ This variable is available as of MySQL 3.23.40.
</para>
</listitem>
@@ -1324,14 +1334,14 @@
</para>
<para>
- Warning: This option should be defined only in an emergency
- situation when you want to dump your tables from a corrupt
- database! Possible values are from 1 to 6. The meanings of
- these values are described in
+ The crash recovery mode. Warning: This variable should be set
+ greater than 0 only in an emergency situation when you want to
+ dump your tables from a corrupt database! Possible values are
+ from 1 to 6. The meanings of these values are described in
<xref linkend="forcing-recovery"/>. As a safety measure,
- <literal>InnoDB</literal> prevents a user from modifying data
- when this option is greater than 0. This option is available
- starting from MySQL 3.23.44.
+ <literal>InnoDB</literal> prevents any changes to its data
+ when this variable is greater than 0. This variable is
+ available starting from MySQL 3.23.44.
</para>
</listitem>
@@ -1420,10 +1430,10 @@
<para>
The directory where fully written log files would be archived
- if we used log archiving. The value of this parameter should
+ if we used log archiving. The value of this variable should
currently be set the same as
<literal>innodb_log_group_home_dir</literal>. Starting from
- MySQL 4.0.6, you may omit this option.
+ MySQL 4.0.6, there is no need to set this variable.
</para>
</listitem>
@@ -1436,7 +1446,7 @@
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 option is 0.
+ default for this variable is 0.
</para>
</listitem>
@@ -1494,8 +1504,8 @@
The directory path to the <literal>InnoDB</literal> log files.
It must have the same value as
<literal>innodb_log_arch_dir</literal>. If you do not specify
- any <literal>InnoDB</literal> log parameters, the default is
- to create two 5MB files names <filename>ib_logfile0</filename>
+ any <literal>InnoDB</literal> log variables, the default is to
+ create two 5MB files names <filename>ib_logfile0</filename>
and <filename>ib_logfile1</filename> in the MySQL data
directory.
</para>
@@ -1527,15 +1537,13 @@
</para>
<para>
- This option controls how to delay <literal>INSERT</literal>,
+ 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 parameter is zero, meaning that there
- are no delays. This option can be changed at runtime as a
- global system variable.
- <literal>innodb_max_purge_lag</literal> is available as of
- MySQL 4.0.22 and 4.1.6.
+ 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>
@@ -1580,11 +1588,11 @@
</para>
<para>
- This option is relevant only if you use multiple tablespaces
+ This variable is relevant only if you use multiple tablespaces
in <literal>InnoDB</literal>. It specifies the maximum number
of <filename>.ibd</filename> files that
<literal>InnoDB</literal> can keep open at one time. The
- minimum value is 10. The default is 300. This option is
+ minimum value is 10. The default is 300. This variable is
available as of MySQL 4.1.1.
</para>
@@ -1647,16 +1655,16 @@
<literal>InnoDB</literal> tries to keep the number of
operating system threads concurrently inside
<literal>InnoDB</literal> less than or equal to the limit
- given by this parameter. The default value is 8. If you have
+ given by this variable. The default value is 8. If you have
low performance and <literal>SHOW INNODB STATUS</literal>
reveals many threads waiting for semaphores, you may have
- thread thrashing and should try setting this parameter lower
- or higher. If you have a computer with many processors and
- disks, you can try setting the value higher to better utilize
- the resources of your computer. A recommended value is the sum
- of the number of processors and disks your system has. A value
- of 500 or greater disables the concurrency checking. This
- option is available starting from MySQL 3.23.44 and 4.0.1.
+ thread thrashing and should try setting this variable lower or
+ higher. If you have a computer with many processors and disks,
+ you can try setting the value higher to better utilize the
+ resources of your computer. A recommended value is the sum of
+ the number of processors and disks your system has. A value of
+ 500 or greater disables the concurrency checking. This
+ variable is available starting from MySQL 3.23.44 and 4.0.1.
</para>
</listitem>
@@ -1666,8 +1674,9 @@
</para>
<para>
- If positive, the MySQL server synchronizes its binary log to
- disk (<literal>fdatasync()</literal>) after every
+ If the value of this variable is positive, the MySQL server
+ synchronizes its binary log to disk
+ (<literal>fdatasync()</literal>) after every
<literal>sync_binlog</literal>'th write to this binary log.
Note that there is one write to the binary log per statement
if in autocommit mode, and otherwise one write per
Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml 2006-01-10 18:02:38 UTC (rev 755)
+++ trunk/refman-5.0/database-administration.xml 2006-01-10 18:02:56 UTC (rev 756)
@@ -8500,8 +8500,9 @@
</para>
<para>
- If positive, the MySQL server synchronizes its binary log
- to disk (<literal>fdatasync()</literal>) after every
+ If the value of this variable is positive, the MySQL
+ server synchronizes its binary log to disk
+ (<literal>fdatasync()</literal>) after every
<literal>sync_binlog</literal>'th write to this binary
log. Note that there is one write to the binary log per
statement if in autocommit mode, and otherwise one write
Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml 2006-01-10 18:02:38 UTC (rev 755)
+++ trunk/refman-5.0/innodb.xml 2006-01-10 18:02:56 UTC (rev 756)
@@ -997,9 +997,9 @@
32-bit Windows operating system supports more than 4GB memory,
using so-called <quote>Address Windowing Extensions</quote>,
you can allocate the <literal>InnoDB</literal> buffer pool
- into the AWE physical memory using this parameter. The maximum
- possible value for this is 63000. If this parameter is
- specified, <literal>innodb_buffer_pool_size</literal> is the
+ into the AWE physical memory using this variable. The maximum
+ possible value for this variable is 63000. If it is greater
+ than 0, <literal>innodb_buffer_pool_size</literal> is the
window in the 32-bit address space of
<command>mysqld</command> where <literal>InnoDB</literal> maps
that AWE memory. A good value for
@@ -1055,8 +1055,8 @@
<para>
The number of threads that can commit at the same time. A
- value of 0 disables concurrency control. This option was added
- in MySQL 5.0.12.
+ value of 0 disables concurrency control. This variable was
+ added in MySQL 5.0.12.
</para>
</listitem>
@@ -1079,7 +1079,7 @@
has used up its tickets. After that point, the thread again
becomes subject to the concurrency check (and possible
queuing) the next time it tries to enter
- <literal>InnoDB</literal>. This option was added in MySQL
+ <literal>InnoDB</literal>. This variable was added in MySQL
5.0.3.
</para>
</listitem>
@@ -1178,9 +1178,10 @@
</para>
<para>
- This option causes <literal>InnoDB</literal> to create each
- new table using its own <filename>.ibd</filename> file for
- storing data and indexes, rather than in the shared
+ If this variable is enabled, <literal>InnoDB</literal> creates
+ each new table using its own <filename>.ibd</filename> file
+ for storing data and indexes, rather than in the shared
+ tablespace. The default is to create tables in the shared
tablespace. See <xref linkend="multiple-tablespaces"/>.
</para>
</listitem>
@@ -1192,40 +1193,44 @@
<para>
When <literal>innodb_flush_log_at_trx_commit</literal> is set
- to 0, once per second the log buffer is written out to the log
- file, and the flush to disk operation is performed on the log
+ to 0, the log buffer is written out to the log file once per
+ second and the flush to disk operation is performed on the log
file, but nothing is done at a transaction commit. When this
- value is 1 (the default), at each transaction commit the log
- buffer is written out to the log file, and the flush to disk
- operation is performed on the log file. When set to 2, at each
- commit the log buffer is written out to the file, but the
+ value is 1 (the default), the log buffer is written out to the
+ log file at each transaction commit and the flush to disk
+ operation is performed on the log file. When set to 2, the log
+ buffer is written out to the file at each commit, but the
flush to disk operation is not performed on it. However, the
- flushing on the log file takes place once per second also in
- the case of 2. We must note that the once-per-second flushing
- is not 100% guaranteed to happen every second, due to process
- scheduling issues. You can achieve better performance by
- setting the value different from 1, but then you can lose at
- most one second worth of transactions in a crash. If you set
- the value to 0, then any <command>mysqld</command> process
- crash can erase the last second of transactions. If you set
- the value to 2, then only an operating system crash or a power
- outage can erase the last second of transactions. However,
- <literal>InnoDB</literal>'s crash recovery is not affected and
- thus crash recovery does work regardless of the value. Note
- that many operating systems and some disk hardware fool the
- flush-to-disk operation. They may tell
- <command>mysqld</command> that the flush has taken place,
- though it has not. Then the durability of transactions is not
- guaranteed even with the setting 1, and in the worst case a
- power outage can even corrupt the <literal>InnoDB</literal>
- database. Using a battery-backed disk cache in the SCSI disk
- controller or in the disk itself speeds up file flushes, and
- makes the operation safer. You can also try using the Unix
- command <command>hdparm</command> to disable the caching of
- disk writes in hardware caches, or use some other command
- specific to the hardware vendor. The default value of this
- option is 1.
+ flushing on the log file takes place once per second also when
+ the value is 2. Note that the once-per-second flushing is not
+ 100% guaranteed to happen every second, due to process
+ scheduling issues.
</para>
+
+ <para>
+ The default value of this variable is 1, which is the value
+ that is required for ACID compliance. You can achieve better
+ performance by setting the value different from 1, but then
+ you can lose at most one second worth of transactions in a
+ crash. If you set the value to 0, then any
+ <command>mysqld</command> process crash can erase the last
+ second of transactions. If you set the value to 2, then only
+ an operating system crash or a power outage can erase the last
+ second of transactions. However, <literal>InnoDB</literal>'s
+ crash recovery is not affected and thus crash recovery does
+ work regardless of the value. Note that many operating systems
+ and some disk hardware fool the flush-to-disk operation. They
+ may tell <command>mysqld</command> that the flush has taken
+ place, though it has not. Then the durability of transactions
+ is not guaranteed even with the setting 1, and in the worst
+ case a power outage can even corrupt the
+ <literal>InnoDB</literal> database. Using a battery-backed
+ disk cache in the SCSI disk controller or in the disk itself
+ speeds up file flushes, and makes the operation safer. You can
+ also try using the Unix command <command>hdparm</command> to
+ disable the caching of disk writes in hardware caches, or use
+ some other command specific to the hardware vendor.
+ </para>
</listitem>
<listitem>
@@ -1248,7 +1253,9 @@
<literal>fsync()</literal> instead of
<literal>fdatasync()</literal>, and it does not use
<literal>O_DSYNC</literal> by default because there have been
- problems with this on many varieties of Unix.
+ problems with it on many varieties of Unix. This variable is
+ relevant only for Unix. On Windows, the flush method is always
+ <literal>async_unbuffered</literal> and cannot be changed.
</para>
</listitem>
@@ -1258,13 +1265,13 @@
</para>
<para>
- Warning: This option should be defined only in an emergency
- situation when you want to dump your tables from a corrupt
- database! Possible values are from 1 to 6. The meanings of
- these values are described in
+ The crash recovery mode. Warning: This variable should be set
+ greater than 0 only in an emergency situation when you want to
+ dump your tables from a corrupt database! Possible values are
+ from 1 to 6. The meanings of these values are described in
<xref linkend="forcing-recovery"/>. As a safety measure,
- <literal>InnoDB</literal> prevents a user from modifying data
- when this option is greater than 0.
+ <literal>InnoDB</literal> prevents any changes to its data
+ when this variable is greater than 0.
</para>
</listitem>
@@ -1393,8 +1400,9 @@
lock to the same row (2,3), which it cannot have. This is
because query two first takes an exclusive lock on a row and
then determines whether this row belongs to the result set,
- and if not then releases the unnecessary lock, when the option
- <literal>innodb_locks_unsafe_for_binlog</literal> is used.
+ and if not then releases the unnecessary lock, when the
+ <literal>innodb_locks_unsafe_for_binlog</literal> variable is
+ enabled.
</para>
<para>
@@ -1432,7 +1440,7 @@
<para>
The directory where fully written log files would be archived
- if we used log archiving. If used, the value of this parameter
+ if we used log archiving. If used, the value of this variable
should be set the same as
<literal>innodb_log_group_home_dir</literal>. However, it is
not required.
@@ -1448,7 +1456,7 @@
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 option is 0.
+ files. The default for this variable is 0.
</para>
</listitem>
@@ -1506,8 +1514,8 @@
The directory path to the <literal>InnoDB</literal> log files.
It must have the same value as
<literal>innodb_log_arch_dir</literal>. If you do not specify
- any <literal>InnoDB</literal> log parameters, the default is
- to create two 5MB files names <filename>ib_logfile0</filename>
+ any <literal>InnoDB</literal> log variables, the default is to
+ create two 5MB files names <filename>ib_logfile0</filename>
and <filename>ib_logfile1</filename> in the MySQL data
directory.
</para>
@@ -1538,13 +1546,12 @@
</para>
<para>
- This option controls how to delay <literal>INSERT</literal>,
+ 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 parameter is zero, meaning that there
- are no delays. This option can be changed at runtime as a
- global system variable.
+ default value of this variable is 0, meaning that there are no
+ delays.
</para>
<para>
@@ -1589,7 +1596,7 @@
</para>
<para>
- This option is relevant only if you use multiple tablespaces
+ This variable is relevant only if you use multiple tablespaces
in <literal>InnoDB</literal>. It specifies the maximum number
of <filename>.ibd</filename> files that
<literal>InnoDB</literal> can keep open at one time. The
@@ -1645,7 +1652,7 @@
<para>
The number of times a thread waits for an
<literal>InnoDB</literal> mutex to be freed before the thread
- is suspended. This option was added in MySQL 5.0.3.
+ is suspended. This variable was added in MySQL 5.0.3.
</para>
</listitem>
@@ -1678,11 +1685,11 @@
<literal>InnoDB</literal> tries to keep the number of
operating system threads concurrently inside
<literal>InnoDB</literal> less than or equal to the limit
- given by this parameter. Before MySQL 5.0.8, the default value
+ given by this variable. Before MySQL 5.0.8, the default value
is 8. If you have performance issues, and <literal>SHOW ENGINE
INNODB STATUS</literal> reveals many threads waiting for
semaphores, you may have thread <quote>thrashing</quote> and
- should try setting this parameter lower or higher. If you have
+ should try setting this variable lower or higher. If you have
a computer with many processors and disks, you can try setting
the value higher to make better use of your computer's
resources. A recommended value is the sum of the number of
@@ -1714,8 +1721,9 @@
</para>
<para>
- If positive, the MySQL server synchronizes its binary log to
- disk (<literal>fdatasync()</literal>) after every
+ If the value of this variable is positive, the MySQL server
+ synchronizes its binary log to disk
+ (<literal>fdatasync()</literal>) after every
<literal>sync_binlog</literal>'th write to this binary log.
Note that there is one write to the binary log per statement
if in autocommit mode, and otherwise one write per
Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml 2006-01-10 18:02:38 UTC (rev 755)
+++ trunk/refman-5.1/database-administration.xml 2006-01-10 18:02:56 UTC (rev 756)
@@ -8467,8 +8467,9 @@
</para>
<para>
- If positive, the MySQL server synchronizes its binary log
- to disk (<literal>fdatasync()</literal>) after every
+ If the value of this variable is positive, the MySQL
+ server synchronizes its binary log to disk
+ (<literal>fdatasync()</literal>) after every
<literal>sync_binlog</literal>'th write to this binary
log. Note that there is one write to the binary log per
statement if in autocommit mode, and otherwise one write
Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml 2006-01-10 18:02:38 UTC (rev 755)
+++ trunk/refman-5.1/innodb.xml 2006-01-10 18:02:56 UTC (rev 756)
@@ -997,9 +997,9 @@
32-bit Windows operating system supports more than 4GB memory,
using so-called <quote>Address Windowing Extensions</quote>,
you can allocate the <literal>InnoDB</literal> buffer pool
- into the AWE physical memory using this parameter. The maximum
- possible value for this is 63000. If this parameter is
- specified, <literal>innodb_buffer_pool_size</literal> is the
+ into the AWE physical memory using this variable. The maximum
+ possible value for this variable is 63000. If it is greater
+ than 0, <literal>innodb_buffer_pool_size</literal> is the
window in the 32-bit address space of
<command>mysqld</command> where <literal>InnoDB</literal> maps
that AWE memory. A good value for
@@ -1174,9 +1174,10 @@
</para>
<para>
- This option causes <literal>InnoDB</literal> to create each
- new table using its own <filename>.ibd</filename> file for
- storing data and indexes, rather than in the shared
+ If this variable is enabled, <literal>InnoDB</literal> creates
+ each new table using its own <filename>.ibd</filename> file
+ for storing data and indexes, rather than in the shared
+ tablespace. The default is to create tables in the shared
tablespace. See <xref linkend="multiple-tablespaces"/>.
</para>
</listitem>
@@ -1188,40 +1189,44 @@
<para>
When <literal>innodb_flush_log_at_trx_commit</literal> is set
- to 0, once per second the log buffer is written out to the log
- file, and the flush to disk operation is performed on the log
+ to 0, the log buffer is written out to the log file once per
+ second and the flush to disk operation is performed on the log
file, but nothing is done at a transaction commit. When this
- value is 1 (the default), at each transaction commit the log
- buffer is written out to the log file, and the flush to disk
- operation is performed on the log file. When set to 2, at each
- commit the log buffer is written out to the file, but the
+ value is 1 (the default), the log buffer is written out to the
+ log file at each transaction commit and the flush to disk
+ operation is performed on the log file. When set to 2, the log
+ buffer is written out to the file at each commit, but the
flush to disk operation is not performed on it. However, the
- flushing on the log file takes place once per second also in
- the case of 2. We must note that the once-per-second flushing
- is not 100% guaranteed to happen every second, due to process
- scheduling issues. You can achieve better performance by
- setting the value different from 1, but then you can lose at
- most one second worth of transactions in a crash. If you set
- the value to 0, then any <command>mysqld</command> process
- crash can erase the last second of transactions. If you set
- the value to 2, then only an operating system crash or a power
- outage can erase the last second of transactions. However,
- <literal>InnoDB</literal>'s crash recovery is not affected and
- thus crash recovery does work regardless of the value. Note
- that many operating systems and some disk hardware fool the
- flush-to-disk operation. They may tell
- <command>mysqld</command> that the flush has taken place,
- though it has not. Then the durability of transactions is not
- guaranteed even with the setting 1, and in the worst case a
- power outage can even corrupt the <literal>InnoDB</literal>
- database. Using a battery-backed disk cache in the SCSI disk
- controller or in the disk itself speeds up file flushes, and
- makes the operation safer. You can also try using the Unix
- command <command>hdparm</command> to disable the caching of
- disk writes in hardware caches, or use some other command
- specific to the hardware vendor. The default value of this
- option is 1.
+ flushing on the log file takes place once per second also when
+ the value is 2. Note that the once-per-second flushing is not
+ 100% guaranteed to happen every second, due to process
+ scheduling issues.
</para>
+
+ <para>
+ The default value of this variable is 1, which is the value
+ that is required for ACID compliance. You can achieve better
+ performance by setting the value different from 1, but then
+ you can lose at most one second worth of transactions in a
+ crash. If you set the value to 0, then any
+ <command>mysqld</command> process crash can erase the last
+ second of transactions. If you set the value to 2, then only
+ an operating system crash or a power outage can erase the last
+ second of transactions. However, <literal>InnoDB</literal>'s
+ crash recovery is not affected and thus crash recovery does
+ work regardless of the value. Note that many operating systems
+ and some disk hardware fool the flush-to-disk operation. They
+ may tell <command>mysqld</command> that the flush has taken
+ place, though it has not. Then the durability of transactions
+ is not guaranteed even with the setting 1, and in the worst
+ case a power outage can even corrupt the
+ <literal>InnoDB</literal> database. Using a battery-backed
+ disk cache in the SCSI disk controller or in the disk itself
+ speeds up file flushes, and makes the operation safer. You can
+ also try using the Unix command <command>hdparm</command> to
+ disable the caching of disk writes in hardware caches, or use
+ some other command specific to the hardware vendor.
+ </para>
</listitem>
<listitem>
@@ -1244,7 +1249,9 @@
<literal>fsync()</literal> instead of
<literal>fdatasync()</literal>, and it does not use
<literal>O_DSYNC</literal> by default because there have been
- problems with this on many varieties of Unix.
+ problems with it on many varieties of Unix. This variable is
+ relevant only for Unix. On Windows, the flush method is always
+ <literal>async_unbuffered</literal> and cannot be changed.
</para>
</listitem>
@@ -1254,13 +1261,13 @@
</para>
<para>
- Warning: This option should be defined only in an emergency
- situation when you want to dump your tables from a corrupt
- database! Possible values are from 1 to 6. The meanings of
- these values are described in
+ The crash recovery mode. Warning: This variable should be set
+ greater than 0 only in an emergency situation when you want to
+ dump your tables from a corrupt database! Possible values are
+ from 1 to 6. The meanings of these values are described in
<xref linkend="forcing-recovery"/>. As a safety measure,
- <literal>InnoDB</literal> prevents a user from modifying data
- when this option is greater than 0.
+ <literal>InnoDB</literal> prevents any changes to its data
+ when this variable is greater than 0.
</para>
</listitem>
@@ -1385,8 +1392,9 @@
lock to the same row (2,3), which it cannot have. This is
because query two first takes an exclusive lock on a row and
then determines whether this row belongs to the result set,
- and if not then releases the unnecessary lock, when the option
- <literal>innodb_locks_unsafe_for_binlog</literal> is used.
+ and if not then releases the unnecessary lock, when the
+ <literal>innodb_locks_unsafe_for_binlog</literal> variable is
+ enabled.
</para>
<para>
@@ -1424,7 +1432,7 @@
<para>
The directory where fully written log files would be archived
- if we used log archiving. If used, the value of this parameter
+ if we used log archiving. If used, the value of this variable
should be set the same as
<literal>innodb_log_group_home_dir</literal>. However, it is
not required.
@@ -1440,7 +1448,7 @@
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 option is 0.
+ files. The default for this variable is 0.
</para>
</listitem>
@@ -1498,8 +1506,8 @@
The directory path to the <literal>InnoDB</literal> log files.
It must have the same value as
<literal>innodb_log_arch_dir</literal>. If you do not specify
- any <literal>InnoDB</literal> log parameters, the default is
- to create two 5MB files names <filename>ib_logfile0</filename>
+ any <literal>InnoDB</literal> log variables, the default is to
+ create two 5MB files names <filename>ib_logfile0</filename>
and <filename>ib_logfile1</filename> in the MySQL data
directory.
</para>
@@ -1530,13 +1538,12 @@
</para>
<para>
- This option controls how to delay <literal>INSERT</literal>,
+ 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 parameter is zero, meaning that there
- are no delays. This option can be changed at runtime as a
- global system variable.
+ default value of this variable is 0, meaning that there are no
+ delays.
</para>
<para>
@@ -1581,7 +1588,7 @@
</para>
<para>
- This option is relevant only if you use multiple tablespaces
+ This variable is relevant only if you use multiple tablespaces
in <literal>InnoDB</literal>. It specifies the maximum number
of <filename>.ibd</filename> files that
<literal>InnoDB</literal> can keep open at one time. The
@@ -1655,10 +1662,10 @@
<literal>InnoDB</literal> tries to keep the number of
operating system threads concurrently inside
<literal>InnoDB</literal> less than or equal to the limit
- given by this parameter. If you have performance issues, and
+ given by this variable. If you have performance issues, and
<literal>SHOW ENGINE INNODB STATUS</literal> reveals many
threads waiting for semaphores, you may have thread
- <quote>thrashing</quote> and should try setting this parameter
+ <quote>thrashing</quote> and should try setting this variable
lower or higher. If you have a computer with many processors
and disks, you can try setting the value higher to make better
use of your computer's resources. A recommended value is the
@@ -1690,8 +1697,9 @@
</para>
<para>
- If positive, the MySQL server synchronizes its binary log to
- disk (<literal>fdatasync()</literal>) after every
+ If the value of this variable is positive, the MySQL server
+ synchronizes its binary log to disk
+ (<literal>fdatasync()</literal>) after every
<literal>sync_binlog</literal>'th write to this binary log.
Note that there is one write to the binary log per statement
if in autocommit mode, and otherwise one write per
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r756 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 10 Jan |
