| List: | Commits | « Previous MessageNext Message » | |
| From: | paul.dubois | Date: | November 5 2008 11:01pm |
| Subject: | svn commit - mysqldoc@docsrva: r12297 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 | ||
| View as plain text | |||
Author: paul Date: 2008-11-05 23:01:15 +0100 (Wed, 05 Nov 2008) New Revision: 12297 Log: r35327@frost: paul | 2008-11-05 15:21:56 -0500 General InnoDB revisions Modified: trunk/refman-4.1/dba-core.xml trunk/refman-4.1/se-innodb-core.xml trunk/refman-5.0/dba-core.xml trunk/refman-5.0/se-innodb-core.xml trunk/refman-5.1/dba-core.xml trunk/refman-5.1/se-innodb-core.xml trunk/refman-6.0/dba-core.xml trunk/refman-6.0/se-innodb-core.xml Property changes on: trunk ___________________________________________________________________ Name: svk:merge - 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:39854 7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:35323 b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34100 + 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:39854 7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:35327 b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34100 Modified: trunk/refman-4.1/dba-core.xml =================================================================== --- trunk/refman-4.1/dba-core.xml 2008-11-05 21:04:30 UTC (rev 12296) +++ trunk/refman-4.1/dba-core.xml 2008-11-05 22:01:15 UTC (rev 12297) Changed blocks: 1, Lines Added: 6, Lines Deleted: 5; 1336 bytes @@ -6045,13 +6045,14 @@ </para> <para> - If the value of this variable is positive, the MySQL server - synchronizes its binary log to disk (using + If the value of this variable is greater than 0, the MySQL + server synchronizes its binary log to disk (using <literal>fdatasync()</literal>) after every <literal>sync_binlog</literal> writes to the binary log. - Note that there is one write to the binary log per statement - if autocommit is enabled, and one write per transaction - otherwise. The default value is 0, which does no + There is one write to the binary log per statement if + autocommit is enabled, and one write per transaction + otherwise. The default value of + <literal>sync_binlog</literal> is 0, which does no synchronizing to disk. A value of 1 is the safest choice, because in the event of a crash you lose at most one statement or transaction from the binary log. However, it is Modified: trunk/refman-4.1/se-innodb-core.xml =================================================================== --- trunk/refman-4.1/se-innodb-core.xml 2008-11-05 21:04:30 UTC (rev 12296) +++ trunk/refman-4.1/se-innodb-core.xml 2008-11-05 22:01:15 UTC (rev 12297) Changed blocks: 11, Lines Added: 34, Lines Deleted: 33; 7218 bytes @@ -1805,11 +1805,11 @@ <para> The size in bytes of the buffer that <literal>InnoDB</literal> - uses to write to the log files on disk. Sensible values range - from 1MB to 8MB. The default is 1MB. A large log buffer allows - large transactions to run without a need to write the log to - disk before the transactions commit. Thus, if you have big - transactions, making the log buffer larger saves disk I/O. + uses to write to the log files on disk. The default value is + 1MB. Sensible values range from 1MB to 8MB. A large log buffer + allows large transactions to run without a need to write the + log to disk before the transactions commit. Thus, if you have + big transactions, making the log buffer larger saves disk I/O. </para> </listitem> @@ -1821,7 +1821,7 @@ <para> The size in bytes of each log file in a log group. The combined size of log files must be less than 4GB. The default - is 5MB. Sensible values range from 1MB to + value is 5MB. Sensible values range from 1MB to 1/<replaceable>N</replaceable>-th of the size of the buffer pool, where <replaceable>N</replaceable> is the number of log files in the group. The larger the value, the less checkpoint @@ -1839,7 +1839,7 @@ <para> The number of log files in the log group. <literal>InnoDB</literal> writes to the files in a circular - fashion. The default (and recommended) is 2. + fashion. The default (and recommended) value is 2. </para> </listitem> @@ -1865,11 +1865,11 @@ </para> <para> - 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. - Available starting from 4.0.13 and 4.1.1. + This is an integer in the range from 0 to 100. The default + value 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. Available starting from 4.0.13 and 4.1.1. </para> </listitem> @@ -1881,7 +1881,7 @@ <para> This variable controls how to delay <literal role="stmt">INSERT</literal>, - <literal role="stmt">UPDATE</literal> and + <literal role="stmt">UPDATE</literal>, and <literal role="stmt">DELETE</literal> operations when the purge operations are lagging (see <xref linkend="innodb-multi-versioning"/>). The default value @@ -1899,7 +1899,7 @@ When <replaceable>purge_lag</replaceable> exceeds <literal>innodb_max_purge_lag</literal>, each <literal role="stmt">INSERT</literal>, - <literal role="stmt">UPDATE</literal> and + <literal role="stmt">UPDATE</literal>, and <literal role="stmt">DELETE</literal> operation is delayed by ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)×10)−5 milliseconds. The delay is computed in the beginning of a @@ -1910,9 +1910,9 @@ <para> A typical setting for a problematic workload might be 1 - million, assuming that our transactions are small, only 100 - bytes in size, and we can allow 100MB of unpurged rows in our - tables. + million, assuming that transactions are small, only 100 bytes + in size, and it is allowable to have 100MB of unpurged + <literal>InnoDB</literal> table rows. </para> </listitem> @@ -1923,7 +1923,7 @@ <para> The number of identical copies of log groups to keep for the - database. Currently, this should be set to 1. + database. This should be set to 1. </para> </listitem> @@ -1937,8 +1937,8 @@ 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 variable is - available as of MySQL 4.1.1. + minimum value is 10. The default value is 300. This variable + is available as of MySQL 4.1.1. </para> <para> @@ -1973,8 +1973,8 @@ TABLES</literal>. If <literal>AUTOCOMMIT=0</literal>, <literal>InnoDB</literal> honors <literal role="stmt">LOCK TABLES</literal>; MySQL does not return from <literal>LOCK - TABLE .. WRITE</literal> until all other threads have released - all their locks to the table. The default value of + TABLES ... WRITE</literal> until all other threads have + released all their locks to the table. The default value of <literal>innodb_table_locks</literal> is 1, which means that <literal role="stmt">LOCK TABLES</literal> causes InnoDB to lock a table internally if <literal>AUTOCOMMIT=0</literal>. @@ -2010,17 +2010,18 @@ </para> <para> - 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> writes 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 transaction. The - default value is 0 which does no sync'ing to disk. A value of - 1 is the safest choice, because in case of crash you lose at - most one statement/transaction from the binary log; but it is - also the slowest choice (unless the disk has a battery-backed - cache, which makes sync'ing very fast). This variable was + If the value of this variable is greater than 0, the MySQL + server synchronizes its binary log to disk (using + <literal>fdatasync()</literal>) after every + <literal>sync_binlog</literal> writes to the binary log. There + is one write to the binary log per statement if autocommit is + enabled, and one write per transaction otherwise. The default + value of <literal>sync_binlog</literal> is 0, which does no + synchronizing to disk. A value of 1 is the safest choice, + because in the event of a crash you lose at most one statement + or transaction from the binary log. However, it is also the + slowest choice (unless the disk has a battery-backed cache, + which makes synchronization very fast). This variable was added in MySQL 4.1.3. </para> </listitem> Modified: trunk/refman-5.0/dba-core.xml =================================================================== --- trunk/refman-5.0/dba-core.xml 2008-11-05 21:04:30 UTC (rev 12296) +++ trunk/refman-5.0/dba-core.xml 2008-11-05 22:01:15 UTC (rev 12297) Changed blocks: 1, Lines Added: 6, Lines Deleted: 5; 1398 bytes @@ -7202,13 +7202,14 @@ <para condition="dynamic:optvar:item" role="5.0:mysqld:sync-binlog"/> <para> - If the value of this variable is positive, the MySQL server - synchronizes its binary log to disk (using + If the value of this variable is greater than 0, the MySQL + server synchronizes its binary log to disk (using <literal>fdatasync()</literal>) after every <literal>sync_binlog</literal> writes to the binary log. - Note that there is one write to the binary log per statement - if autocommit is enabled, and one write per transaction - otherwise. The default value is 0, which does no + There is one write to the binary log per statement if + autocommit is enabled, and one write per transaction + otherwise. The default value of + <literal>sync_binlog</literal> is 0, which does no synchronizing to disk. A value of 1 is the safest choice, because in the event of a crash you lose at most one statement or transaction from the binary log. However, it is Modified: trunk/refman-5.0/se-innodb-core.xml =================================================================== --- trunk/refman-5.0/se-innodb-core.xml 2008-11-05 21:04:30 UTC (rev 12296) +++ trunk/refman-5.0/se-innodb-core.xml 2008-11-05 22:01:15 UTC (rev 12297) Changed blocks: 15, Lines Added: 58, Lines Deleted: 57; 10725 bytes @@ -1846,11 +1846,11 @@ <para> The size in bytes of the buffer that <literal>InnoDB</literal> - uses to write to the log files on disk. Sensible values range - from 1MB to 8MB. The default is 1MB. A large log buffer allows - large transactions to run without a need to write the log to - disk before the transactions commit. Thus, if you have big - transactions, making the log buffer larger saves disk I/O. + uses to write to the log files on disk. The default value is + 1MB. Sensible values range from 1MB to 8MB. A large log buffer + allows large transactions to run without a need to write the + log to disk before the transactions commit. Thus, if you have + big transactions, making the log buffer larger saves disk I/O. </para> </listitem> @@ -1862,7 +1862,7 @@ <para> The size in bytes of each log file in a log group. The combined size of log files must be less than 4GB. The default - is 5MB. Sensible values range from 1MB to + value is 5MB. Sensible values range from 1MB to 1/<replaceable>N</replaceable>-th of the size of the buffer pool, where <replaceable>N</replaceable> is the number of log files in the group. The larger the value, the less checkpoint @@ -1880,7 +1880,7 @@ <para> The number of log files in the log group. <literal>InnoDB</literal> writes to the files in a circular - fashion. The default (and recommended) is 2. + fashion. The default (and recommended) value is 2. </para> </listitem> @@ -1904,10 +1904,11 @@ </para> <para> - 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. + This is an integer in the range from 0 to 100. The default + value 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. </para> </listitem> @@ -1919,11 +1920,11 @@ <para> This variable controls how to delay <literal role="stmt">INSERT</literal>, - <literal role="stmt">UPDATE</literal> and - <literal role="stmt">DELETE</literal> operations when the - purge operations are lagging (see + <literal role="stmt">UPDATE</literal>, and + <literal role="stmt">DELETE</literal> operations when purge + operations are lagging (see <xref linkend="innodb-multi-versioning"/>). The default value - of this variable is 0, meaning that there are no delays. + 0 (no delays). </para> <para> @@ -1935,7 +1936,7 @@ When <replaceable>purge_lag</replaceable> exceeds <literal>innodb_max_purge_lag</literal>, each <literal role="stmt">INSERT</literal>, - <literal role="stmt">UPDATE</literal> and + <literal role="stmt">UPDATE</literal>, and <literal role="stmt">DELETE</literal> operation is delayed by ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)×10)−5 milliseconds. The delay is computed in the beginning of a @@ -1946,9 +1947,9 @@ <para> A typical setting for a problematic workload might be 1 - million, assuming that our transactions are small, only 100 - bytes in size, and we can allow 100MB of unpurged rows in our - tables. + million, assuming that transactions are small, only 100 bytes + in size, and it is allowable to have 100MB of unpurged + <literal>InnoDB</literal> table rows. </para> </listitem> @@ -1959,7 +1960,7 @@ <para> The number of identical copies of log groups to keep for the - database. Currently, this should be set to 1. + database. This should be set to 1. </para> </listitem> @@ -1973,7 +1974,7 @@ 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. + minimum value is 10. The default value is 300. </para> <para> @@ -1992,11 +1993,12 @@ <para> In MySQL 5.0.13 and up, <literal>InnoDB</literal> rolls back - only the last statement on a transaction timeout. If this - option is given, a transaction timeout causes - <literal>InnoDB</literal> to abort and roll back the entire - transaction (the same behavior as before MySQL 5.0.13). This - variable was added in MySQL 5.0.32. + only the last statement on a transaction timeout by default. + If <option>--innodb_rollback_on_timeout</option> is specified, + a transaction timeout causes <literal>InnoDB</literal> to + abort and roll back the entire transaction (the same behavior + as before MySQL 5.0.13). This variable was added in MySQL + 5.0.32. </para> </listitem> @@ -2023,26 +2025,23 @@ </para> <para> - When set to <literal>ON</literal> or 1 (the default), this - variable enables <literal>InnoDB</literal> support for - two-phase commit in XA transactions. Enabling - <literal>innodb_support_xa</literal> causes an extra disk - flush for transaction preparation. + When the variable is enabled (the default), + <literal>InnoDB</literal> support for two-phase commit in XA + transactions is enabled, which causes an extra disk flush for + transaction preparation. </para> <para> - If you do not wish to use XA, you can disable this variable by - setting it to <literal>OFF</literal> or 0 to reduce the number - of disk flushes and get better <literal>InnoDB</literal> - performance. + If you do not wish to use XA transactions, you can disable + this variable to reduce the number of disk flushes and get + better <literal>InnoDB</literal> performance. </para> <para> - Setting <literal>innodb_support_xa</literal> to - <literal>ON</literal> or 1 on a replication master — or - on any MySQL server where binary logging is in use — - ensures that the binary log does not get out of sync compared - to the table data. + Having <literal>innodb_support_xa</literal> enabled on a + replication master — or on any MySQL server where binary + logging is in use — ensures that the binary log does not + get out of sync compared to the table data. </para> <para> @@ -2058,7 +2057,8 @@ <para> The number of times a thread waits for an <literal>InnoDB</literal> mutex to be freed before the thread - is suspended. This variable was added in MySQL 5.0.3. + is suspended. The default value is 20. This variable was added + in MySQL 5.0.3. </para> </listitem> @@ -2070,7 +2070,7 @@ <para> If <literal>AUTOCOMMIT=0</literal>, <literal>InnoDB</literal> honors <literal role="stmt">LOCK TABLES</literal>; MySQL does - not return from <literal>LOCK TABLE .. WRITE</literal> until + not return from <literal>LOCK TABLES ... WRITE</literal> until all other threads have released all their locks to the table. The default value of <literal>innodb_table_locks</literal> is 1, which means that <literal role="stmt">LOCK TABLES</literal> @@ -2099,15 +2099,16 @@ The correct value for this variable is dependent on environment and workload. You will need to try a range of different values to determine what value works for your - application. + applications. </para> <para> The range of this variable is 0 to 1000. A value of 20 or higher is interpreted as infinite concurrency before MySQL 5.0.19. From 5.0.19 on, you can disable thread concurrency - checking by setting the value to 0, which allows InnoDB to - create as many threads as it needs. + checking by setting the value to 0. Disabling thread + concurrency checking allows InnoDB to create as many threads + as it needs. </para> <para> @@ -2136,18 +2137,18 @@ </para> <para> - 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> writes 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 transaction. The - default value is 0 which does no synchronizing to disk. A - value of 1 is the safest choice, because in the event of a - crash you lose at most one statement/transaction from the - binary log; however, it is also the slowest choice (unless the - disk has a battery-backed cache, which makes synchronization - very fast). + If the value of this variable is greater than 0, the MySQL + server synchronizes its binary log to disk (using + <literal>fdatasync()</literal>) after every + <literal>sync_binlog</literal> writes to the binary log. There + is one write to the binary log per statement if autocommit is + enabled, and one write per transaction otherwise. The default + value of <literal>sync_binlog</literal> is 0, which does no + synchronizing to disk. A value of 1 is the safest choice, + because in the event of a crash you lose at most one statement + or transaction from the binary log. However, it is also the + slowest choice (unless the disk has a battery-backed cache, + which makes synchronization very fast). </para> </listitem> Modified: trunk/refman-5.1/dba-core.xml =================================================================== --- trunk/refman-5.1/dba-core.xml 2008-11-05 21:04:30 UTC (rev 12296) +++ trunk/refman-5.1/dba-core.xml 2008-11-05 22:01:15 UTC (rev 12297) Changed blocks: 1, Lines Added: 6, Lines Deleted: 5; 1398 bytes @@ -7766,13 +7766,14 @@ <para condition="dynamic:optvar:item" role="5.1:mysqld:sync-binlog"/> <para> - If the value of this variable is positive, the MySQL server - synchronizes its binary log to disk (using + If the value of this variable is greater than 0, the MySQL + server synchronizes its binary log to disk (using <literal>fdatasync()</literal>) after every <literal>sync_binlog</literal> writes to the binary log. - Note that there is one write to the binary log per statement - if autocommit is enabled, and one write per transaction - otherwise. The default value is 0, which does no + There is one write to the binary log per statement if + autocommit is enabled, and one write per transaction + otherwise. The default value of + <literal>sync_binlog</literal> is 0, which does no synchronizing to disk. A value of 1 is the safest choice, because in the event of a crash you lose at most one statement or transaction from the binary log. However, it is Modified: trunk/refman-5.1/se-innodb-core.xml =================================================================== --- trunk/refman-5.1/se-innodb-core.xml 2008-11-05 21:04:30 UTC (rev 12296) +++ trunk/refman-5.1/se-innodb-core.xml 2008-11-05 22:01:15 UTC (rev 12297) Changed blocks: 15, Lines Added: 54, Lines Deleted: 54; 10415 bytes @@ -1883,11 +1883,11 @@ <para> The size in bytes of the buffer that <literal>InnoDB</literal> - uses to write to the log files on disk. Sensible values range - from 1MB to 8MB. The default is 1MB. A large log buffer allows - large transactions to run without a need to write the log to - disk before the transactions commit. Thus, if you have big - transactions, making the log buffer larger saves disk I/O. + uses to write to the log files on disk. The default value is + 1MB. Sensible values range from 1MB to 8MB. A large log buffer + allows large transactions to run without a need to write the + log to disk before the transactions commit. Thus, if you have + big transactions, making the log buffer larger saves disk I/O. </para> </listitem> @@ -1899,7 +1899,7 @@ <para> The size in bytes of each log file in a log group. The combined size of log files must be less than 4GB. The default - is 5MB. Sensible values range from 1MB to + value is 5MB. Sensible values range from 1MB to 1/<replaceable>N</replaceable>-th of the size of the buffer pool, where <replaceable>N</replaceable> is the number of log files in the group. The larger the value, the less checkpoint @@ -1917,7 +1917,7 @@ <para> The number of log files in the log group. <literal>InnoDB</literal> writes to the files in a circular - fashion. The default (and recommended) is 2. + fashion. The default (and recommended) value is 2. </para> </listitem> @@ -1941,10 +1941,11 @@ </para> <para> - 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. + This is an integer in the range from 0 to 100. The default + value 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. </para> </listitem> @@ -1956,11 +1957,11 @@ <para> This variable controls how to delay <literal role="stmt">INSERT</literal>, - <literal role="stmt">UPDATE</literal> and - <literal role="stmt">DELETE</literal> operations when the - purge operations are lagging (see + <literal role="stmt">UPDATE</literal>, and + <literal role="stmt">DELETE</literal> operations when purge + operations are lagging (see <xref linkend="innodb-multi-versioning"/>). The default value - of this variable is 0, meaning that there are no delays. + 0 (no delays). </para> <para> @@ -1972,7 +1973,7 @@ When <replaceable>purge_lag</replaceable> exceeds <literal>innodb_max_purge_lag</literal>, each <literal role="stmt">INSERT</literal>, - <literal role="stmt">UPDATE</literal> and + <literal role="stmt">UPDATE</literal>, and <literal role="stmt">DELETE</literal> operation is delayed by ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)×10)−5 milliseconds. The delay is computed in the beginning of a @@ -1983,9 +1984,9 @@ <para> A typical setting for a problematic workload might be 1 - million, assuming that our transactions are small, only 100 - bytes in size, and we can allow 100MB of unpurged rows in our - tables. + million, assuming that transactions are small, only 100 bytes + in size, and it is allowable to have 100MB of unpurged + <literal>InnoDB</literal> table rows. </para> </listitem> @@ -1996,7 +1997,7 @@ <para> The number of identical copies of log groups to keep for the - database. Currently, this should be set to 1. + database. This should be set to 1. </para> </listitem> @@ -2010,7 +2011,7 @@ 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. + minimum value is 10. The default value is 300. </para> <para> @@ -2029,8 +2030,9 @@ <para> In MySQL ¤t-series;, <literal>InnoDB</literal> rolls - back only the last statement on a transaction timeout. If this - option is given, a transaction timeout causes + back only the last statement on a transaction timeout by + default. If <option>--innodb_rollback_on_timeout</option> is + specified, a transaction timeout causes <literal>InnoDB</literal> to abort and roll back the entire transaction (the same behavior as in MySQL 4.1). This variable was added in MySQL 5.1.15. @@ -2071,26 +2073,23 @@ </para> <para> - When set to <literal>ON</literal> or 1 (the default), this - variable enables <literal>InnoDB</literal> support for - two-phase commit in XA transactions. Enabling - <literal>innodb_support_xa</literal> causes an extra disk - flush for transaction preparation. + When the variable is enabled (the default), + <literal>InnoDB</literal> support for two-phase commit in XA + transactions is enabled, which causes an extra disk flush for + transaction preparation. </para> <para> - If you do not wish to use XA, you can disable this variable by - setting it to <literal>OFF</literal> or 0 to reduce the number - of disk flushes and get better <literal>InnoDB</literal> - performance. + If you do not wish to use XA transactions, you can disable + this variable to reduce the number of disk flushes and get + better <literal>InnoDB</literal> performance. </para> <para> - Setting <literal>innodb_support_xa</literal> to - <literal>ON</literal> or 1 on a replication master — or - on any MySQL server where binary logging is in use — - ensures that the binary log does not get out of sync compared - to the table data. + Having <literal>innodb_support_xa</literal> enabled on a + replication master — or on any MySQL server where binary + logging is in use — ensures that the binary log does not + get out of sync compared to the table data. </para> </listitem> @@ -2102,7 +2101,7 @@ <para> The number of times a thread waits for an <literal>InnoDB</literal> mutex to be freed before the thread - is suspended. + is suspended. The default value is 20. </para> </listitem> @@ -2114,7 +2113,7 @@ <para> If <literal>AUTOCOMMIT=0</literal>, <literal>InnoDB</literal> honors <literal role="stmt">LOCK TABLES</literal>; MySQL does - not return from <literal>LOCK TABLE .. WRITE</literal> until + not return from <literal>LOCK TABLES ... WRITE</literal> until all other threads have released all their locks to the table. The default value of <literal>innodb_table_locks</literal> is 1, which means that <literal role="stmt">LOCK TABLES</literal> @@ -2143,15 +2142,16 @@ The correct value for this variable is dependent on environment and workload. You will need to try a range of different values to determine what value works for your - application. + applications. </para> <para> The range of this variable is 0 to 1000. A value of 20 or higher is interpreted as infinite concurrency before MySQL 5.1.12. From 5.1.12 on, you can disable thread concurrency - checking by setting the value to 0, which allows InnoDB to - create as many threads as it needs. + checking by setting the value to 0. Disabling thread + concurrency checking allows InnoDB to create as many threads + as it needs. </para> <para> @@ -2178,18 +2178,18 @@ </para> <para> - 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> writes 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 transaction. The - default value is 0 which does no synchronizing to disk. A - value of 1 is the safest choice, because in the event of a - crash you lose at most one statement/transaction from the - binary log; however, it is also the slowest choice (unless the - disk has a battery-backed cache, which makes synchronization - very fast). + If the value of this variable is greater than 0, the MySQL + server synchronizes its binary log to disk (using + <literal>fdatasync()</literal>) after every + <literal>sync_binlog</literal> writes to the binary log. There + is one write to the binary log per statement if autocommit is + enabled, and one write per transaction otherwise. The default + value of <literal>sync_binlog</literal> is 0, which does no + synchronizing to disk. A value of 1 is the safest choice, + because in the event of a crash you lose at most one statement + or transaction from the binary log. However, it is also the + slowest choice (unless the disk has a battery-backed cache, + which makes synchronization very fast). </para> </listitem> Modified: trunk/refman-6.0/dba-core.xml =================================================================== --- trunk/refman-6.0/dba-core.xml 2008-11-05 21:04:30 UTC (rev 12296) +++ trunk/refman-6.0/dba-core.xml 2008-11-05 22:01:15 UTC (rev 12297) Changed blocks: 1, Lines Added: 6, Lines Deleted: 5; 1398 bytes @@ -7804,13 +7804,14 @@ <para condition="dynamic:optvar:item" role="6.0:mysqld:sync-binlog"/> <para> - If the value of this variable is positive, the MySQL server - synchronizes its binary log to disk (using + If the value of this variable is greater than 0, the MySQL + server synchronizes its binary log to disk (using <literal>fdatasync()</literal>) after every <literal>sync_binlog</literal> writes to the binary log. - Note that there is one write to the binary log per statement - if autocommit is enabled, and one write per transaction - otherwise. The default value is 0, which does no + There is one write to the binary log per statement if + autocommit is enabled, and one write per transaction + otherwise. The default value of + <literal>sync_binlog</literal> is 0, which does no synchronizing to disk. A value of 1 is the safest choice, because in the event of a crash you lose at most one statement or transaction from the binary log. However, it is Modified: trunk/refman-6.0/se-innodb-core.xml =================================================================== --- trunk/refman-6.0/se-innodb-core.xml 2008-11-05 21:04:30 UTC (rev 12296) +++ trunk/refman-6.0/se-innodb-core.xml 2008-11-05 22:01:15 UTC (rev 12297) Changed blocks: 15, Lines Added: 54, Lines Deleted: 54; 10279 bytes @@ -1792,11 +1792,11 @@ <para> The size in bytes of the buffer that <literal>InnoDB</literal> - uses to write to the log files on disk. Sensible values range - from 1MB to 8MB. The default is 1MB. A large log buffer allows - large transactions to run without a need to write the log to - disk before the transactions commit. Thus, if you have big - transactions, making the log buffer larger saves disk I/O. + uses to write to the log files on disk. The default value is + 1MB. Sensible values range from 1MB to 8MB. A large log buffer + allows large transactions to run without a need to write the + log to disk before the transactions commit. Thus, if you have + big transactions, making the log buffer larger saves disk I/O. </para> </listitem> @@ -1808,7 +1808,7 @@ <para> The size in bytes of each log file in a log group. The combined size of log files must be less than 4GB. The default - is 5MB. Sensible values range from 1MB to + value is 5MB. Sensible values range from 1MB to 1/<replaceable>N</replaceable>-th of the size of the buffer pool, where <replaceable>N</replaceable> is the number of log files in the group. The larger the value, the less checkpoint @@ -1826,7 +1826,7 @@ <para> The number of log files in the log group. <literal>InnoDB</literal> writes to the files in a circular - fashion. The default (and recommended) is 2. + fashion. The default (and recommended) value is 2. </para> </listitem> @@ -1850,10 +1850,11 @@ </para> <para> - 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. + This is an integer in the range from 0 to 100. The default + value 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. </para> </listitem> @@ -1865,11 +1866,11 @@ <para> This variable controls how to delay <literal role="stmt">INSERT</literal>, - <literal role="stmt">UPDATE</literal> and - <literal role="stmt">DELETE</literal> operations when the - purge operations are lagging (see + <literal role="stmt">UPDATE</literal>, and + <literal role="stmt">DELETE</literal> operations when purge + operations are lagging (see <xref linkend="innodb-multi-versioning"/>). The default value - of this variable is 0, meaning that there are no delays. + 0 (no delays). </para> <para> @@ -1881,7 +1882,7 @@ When <replaceable>purge_lag</replaceable> exceeds <literal>innodb_max_purge_lag</literal>, each <literal role="stmt">INSERT</literal>, - <literal role="stmt">UPDATE</literal> and + <literal role="stmt">UPDATE</literal>, and <literal role="stmt">DELETE</literal> operation is delayed by ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)×10)−5 milliseconds. The delay is computed in the beginning of a @@ -1892,9 +1893,9 @@ <para> A typical setting for a problematic workload might be 1 - million, assuming that our transactions are small, only 100 - bytes in size, and we can allow 100MB of unpurged rows in our - tables. + million, assuming that transactions are small, only 100 bytes + in size, and it is allowable to have 100MB of unpurged + <literal>InnoDB</literal> table rows. </para> </listitem> @@ -1905,7 +1906,7 @@ <para> The number of identical copies of log groups to keep for the - database. Currently, this should be set to 1. + database. This should be set to 1. </para> </listitem> @@ -1919,7 +1920,7 @@ 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. + minimum value is 10. The default value is 300. </para> <para> @@ -1938,8 +1939,9 @@ <para> In MySQL ¤t-series;, <literal>InnoDB</literal> rolls - back only the last statement on a transaction timeout. If this - option is given, a transaction timeout causes + back only the last statement on a transaction timeout by + default. If <option>--innodb_rollback_on_timeout</option> is + specified, a transaction timeout causes <literal>InnoDB</literal> to abort and roll back the entire transaction (the same behavior as in MySQL 4.1). </para> @@ -1975,26 +1977,23 @@ </para> <para> - When set to <literal>ON</literal> or 1 (the default), this - variable enables <literal>InnoDB</literal> support for - two-phase commit in XA transactions. Enabling - <literal>innodb_support_xa</literal> causes an extra disk - flush for transaction preparation. + When the variable is enabled (the default), + <literal>InnoDB</literal> support for two-phase commit in XA + transactions is enabled, which causes an extra disk flush for + transaction preparation. </para> <para> - If you do not wish to use XA, you can disable this variable by - setting it to <literal>OFF</literal> or 0 to reduce the number - of disk flushes and get better <literal>InnoDB</literal> - performance. + If you do not wish to use XA transactions, you can disable + this variable to reduce the number of disk flushes and get + better <literal>InnoDB</literal> performance. </para> <para> - Setting <literal>innodb_support_xa</literal> to - <literal>ON</literal> or 1 on a replication master — or - on any MySQL server where binary logging is in use — - ensures that the binary log does not get out of sync compared - to the table data. + Having <literal>innodb_support_xa</literal> enabled on a + replication master — or on any MySQL server where binary + logging is in use — ensures that the binary log does not + get out of sync compared to the table data. </para> </listitem> @@ -2006,7 +2005,7 @@ <para> The number of times a thread waits for an <literal>InnoDB</literal> mutex to be freed before the thread - is suspended. + is suspended. The default value is 20. </para> </listitem> @@ -2018,7 +2017,7 @@ <para> If <literal>AUTOCOMMIT=0</literal>, <literal>InnoDB</literal> honors <literal role="stmt">LOCK TABLES</literal>; MySQL does - not return from <literal>LOCK TABLE .. WRITE</literal> until + not return from <literal>LOCK TABLES ... WRITE</literal> until all other threads have released all their locks to the table. The default value of <literal>innodb_table_locks</literal> is 1, which means that <literal role="stmt">LOCK TABLES</literal> @@ -2047,13 +2046,14 @@ The correct value for this variable is dependent on environment and workload. You will need to try a range of different values to determine what value works for your - application. + applications. </para> <para> The range of this variable is 0 to 1000. You can disable - thread concurrency checking by setting the value to 0, which - allows InnoDB to create as many threads as it needs. + thread concurrency checking by setting the value to 0. + Disabling thread concurrency checking allows InnoDB to create + as many threads as it needs. </para> <para> @@ -2079,18 +2079,18 @@ </para> <para> - 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> writes 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 transaction. The - default value is 0 which does no synchronizing to disk. A - value of 1 is the safest choice, because in the event of a - crash you lose at most one statement/transaction from the - binary log; however, it is also the slowest choice (unless the - disk has a battery-backed cache, which makes synchronization - very fast). + If the value of this variable is greater than 0, the MySQL + server synchronizes its binary log to disk (using + <literal>fdatasync()</literal>) after every + <literal>sync_binlog</literal> writes to the binary log. There + is one write to the binary log per statement if autocommit is + enabled, and one write per transaction otherwise. The default + value of <literal>sync_binlog</literal> is 0, which does no + synchronizing to disk. A value of 1 is the safest choice, + because in the event of a crash you lose at most one statement + or transaction from the binary log. However, it is also the + slowest choice (unless the disk has a battery-backed cache, + which makes synchronization very fast). </para> </listitem>
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r12297 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul.dubois | 5 Nov |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 0.847 sec. using MySQL 5.1.14-beta-log