Author: paul
Date: 2006-01-08 02:33:03 +0100 (Sun, 08 Jan 2006)
New Revision: 720
Log:
r5956@frost: paul | 2006-01-07 19:32:44 -0600
Format.
Modified:
trunk/
trunk/refman-4.1/charset.xml
trunk/refman-4.1/connector-j.xml
trunk/refman-4.1/connector-odbc.xml
trunk/refman-4.1/database-administration.xml
trunk/refman-4.1/innodb.xml
trunk/refman-4.1/installing.xml
trunk/refman-4.1/ndbcluster.xml
trunk/refman-4.1/optimization.xml
trunk/refman-4.1/replication.xml
trunk/refman-4.1/sql-syntax.xml
trunk/refman-4.1/tutorial.xml
trunk/refman-5.0/apis.xml
trunk/refman-5.0/charset.xml
trunk/refman-5.0/connector-j.xml
trunk/refman-5.0/connector-odbc.xml
trunk/refman-5.0/database-administration.xml
trunk/refman-5.0/innodb.xml
trunk/refman-5.0/installing.xml
trunk/refman-5.0/ndbcluster.xml
trunk/refman-5.0/optimization.xml
trunk/refman-5.0/replication.xml
trunk/refman-5.0/sql-syntax.xml
trunk/refman-5.1/apis.xml
trunk/refman-5.1/charset.xml
trunk/refman-5.1/connector-j.xml
trunk/refman-5.1/connector-odbc.xml
trunk/refman-5.1/custom-engine.xml
trunk/refman-5.1/database-administration.xml
trunk/refman-5.1/innodb.xml
trunk/refman-5.1/installing.xml
trunk/refman-5.1/ndbcluster.xml
trunk/refman-5.1/optimization.xml
trunk/refman-5.1/pluggable-storage.xml
trunk/refman-5.1/replication.xml
trunk/refman-5.1/sql-syntax.xml
trunk/refman-5.1/storage-engines.xml
trunk/refman-common/news-4.0.xml
trunk/refman-common/news-4.1.xml
trunk/refman-common/news-5.0.xml
trunk/refman-common/news-5.1.xml
trunk/refman-common/news-innodb.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5951
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5956
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
Modified: trunk/refman-4.1/charset.xml
===================================================================
--- trunk/refman-4.1/charset.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-4.1/charset.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -3385,8 +3385,8 @@
<literal>latin1</literal> is the default character set. The
<literal>latin1_swedish_ci</literal> collation is the
default that probably is used by the majority of MySQL
- customers. Although it is frequently said that it is based on
- the Swedish/Finnish collation rules, there are Swedes and
+ customers. Although it is frequently said that it is based
+ on the Swedish/Finnish collation rules, there are Swedes and
Finns who disagree with this statement.
</para>
Modified: trunk/refman-4.1/connector-j.xml
===================================================================
--- trunk/refman-4.1/connector-j.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-4.1/connector-j.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -2741,9 +2741,9 @@
<para>
The earliest the locks these statements hold can be released
- (whether they be <literal>MyISAM</literal> table-level locks or row-level locks
- in some other storage engine such as <literal>InnoDB</literal>) is when the
- statement completes.
+ (whether they be <literal>MyISAM</literal> table-level locks
+ or row-level locks in some other storage engine such as
+ <literal>InnoDB</literal>) is when the statement completes.
</para>
<para>
@@ -4573,9 +4573,9 @@
Because MySQL does not have row identifiers, MySQL
Connector/J can only update result sets that have come
from queries on tables that have at least one primary key,
- the query must select every primary key and the
- query can only span one table (that is, no joins). This is
- outlined in the JDBC specification.
+ the query must select every primary key and the query can
+ only span one table (that is, no joins). This is outlined
+ in the JDBC specification.
</para>
</answer>
Modified: trunk/refman-4.1/connector-odbc.xml
===================================================================
--- trunk/refman-4.1/connector-odbc.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-4.1/connector-odbc.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -4455,8 +4455,8 @@
</para>
<para>
- <emphasis role="bold">To import or link a table or tables from MySQL to
- Access, follow the instructions:</emphasis>
+ <emphasis role="bold">To import or link a table or tables from
+ MySQL to Access, follow the instructions:</emphasis>
</para>
<orderedlist>
Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-4.1/database-administration.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -351,10 +351,9 @@
<literal>InnoDB</literal> storage engine. MySQL-Max servers
always include <literal>InnoDB</literal> support, but this
option actually is needed only for MySQL 3.23. From MySQL
- 4.0 onward, <literal>InnoDB</literal> is included by
- default in all binary distributions, so you do not need a
- MySQL-Max server merely to obtain <literal>InnoDB</literal>
- support.
+ 4.0 onward, <literal>InnoDB</literal> is included by default
+ in all binary distributions, so you do not need a MySQL-Max
+ server merely to obtain <literal>InnoDB</literal> support.
</para>
</listitem>
@@ -4139,17 +4138,17 @@
</para>
<para>
-When you use a startup option to set a variable that takes a numeric value,
- the value can be given with a suffix of
- <literal>K</literal>, <literal>M</literal>, or
- <literal>G</literal> (either uppercase or lowercase) to indicate
- a multiplier of 1024, 1024<superscript>2</superscript> or
- 1024<superscript>3</superscript>. For example, when used to set
- <literal>key_buffer_size</literal>, the suffixes indicate
- units of kilobytes, megabytes, or gigabygtes.
- Thus,
- the following command starts the server with a key buffer size
- of 16 megabytes:
+ When you use a startup option to set a variable that takes a
+ numeric value, the value can be given with a suffix of
+ <literal>K</literal>, <literal>M</literal>, or
+ <literal>G</literal> (either uppercase or lowercase) to
+ indicate a multiplier of 1024,
+ 1024<superscript>2</superscript> or
+ 1024<superscript>3</superscript>. For example, when used to
+ set <literal>key_buffer_size</literal>, the suffixes indicate
+ units of kilobytes, megabytes, or gigabygtes. Thus, the
+ following command starts the server with a key buffer size of
+ 16 megabytes:
</para>
<programlisting>
@@ -9469,8 +9468,9 @@
<para>
Each storage engine performs any actions necessary for tables
- that it manages. For example, <literal>MyISAM</literal> flushes any pending index
- writes for a table. <literal>InnoDB</literal> flushes its buffer pool to disk,
+ that it manages. For example, <literal>MyISAM</literal>
+ flushes any pending index writes for a table.
+ <literal>InnoDB</literal> flushes its buffer pool to disk,
writes the current LSN to the tablespace, and terminates its
own internal threads.
</para>
Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-4.1/innodb.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -270,10 +270,10 @@
because of write operations having been reordered. If data
integrity is important to you, you should perform some
<quote>pull-the-plug</quote> tests before using anything in
- production. On Mac OS X 10.3 and later, <literal>InnoDB</literal> uses a special
- <literal>fcntl()</literal> file flush method. Under Linux, it is
- advisable to <emphasis role="bold">disable the write-back
- cache</emphasis>.
+ production. On Mac OS X 10.3 and later, <literal>InnoDB</literal>
+ uses a special <literal>fcntl()</literal> file flush method. Under
+ Linux, it is advisable to <emphasis role="bold">disable the
+ write-back cache</emphasis>.
</para>
<para>
@@ -975,21 +975,21 @@
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
+ <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).
+ 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).
</para>
<para>
@@ -1056,15 +1056,15 @@
transaction may wait for a lock before being rolled back.
<literal>InnoDB</literal> automatically detects transaction
deadlocks in its own lock table and rolls back the
- transaction. Beginning with MySQL 4.0.20 and 4.1.2, <literal>InnoDB</literal>
- notices locks set using the <literal>LOCK TABLES</literal>
- statement. Before that, if you use the <literal>LOCK
- TABLES</literal> statement, or other transaction-safe storage
- engines than <literal>InnoDB</literal> in the same
- transaction, a deadlock may arise that
- <literal>InnoDB</literal> cannot notice. In cases like this,
- the timeout is useful to resolve the situation. The default is
- 50 seconds.
+ transaction. Beginning with MySQL 4.0.20 and 4.1.2,
+ <literal>InnoDB</literal> notices locks set using the
+ <literal>LOCK TABLES</literal> statement. Before that, if you
+ use the <literal>LOCK TABLES</literal> statement, or other
+ transaction-safe storage engines than
+ <literal>InnoDB</literal> in the same transaction, a deadlock
+ may arise that <literal>InnoDB</literal> cannot notice. In
+ cases like this, the timeout is useful to resolve the
+ situation. The default is 50 seconds.
</para>
</listitem>
@@ -1115,11 +1115,12 @@
same <literal>SELECT</literal> within the same transaction,
you see a new row in the result set returned by the query.
This also means, that if new items are added to the database,
- <literal>InnoDB</literal> does not guarantee serializability instead conflict
- serializability is still guaranteed. Therefore, if this option
- is used <literal>InnoDB</literal> guarantees at most isolation level
- <literal>READ COMMITTED</literal>. This option is available as
- of MySQL 4.1.4.
+ <literal>InnoDB</literal> does not guarantee serializability
+ instead conflict serializability is still guaranteed.
+ Therefore, if this option is used <literal>InnoDB</literal>
+ guarantees at most isolation level <literal>READ
+ COMMITTED</literal>. This option is available as of MySQL
+ 4.1.4.
</para>
</listitem>
@@ -1249,8 +1250,8 @@
</para>
<para>
- The <literal>InnoDB</literal> transaction system maintains a list of transactions
- that have delete-marked index records by
+ The <literal>InnoDB</literal> transaction system maintains a
+ list of transactions that have delete-marked index records by
<literal>UPDATE</literal> or <literal>DELETE</literal>
operations. Let the length of this list be
<replaceable>purge_lag</replaceable>. When
@@ -1347,12 +1348,14 @@
TABLES</literal>; MySQL does not return from <literal>LOCK
TABLE .. WRITE</literal> until all other threads have released
all their locks to the table. In MySQL 4.0.19 and before,
- <literal>InnoDB</literal> ignored table locks, which allowed one to more easily
- simulate transactions with a combination of <literal>MyISAM</literal> and <literal>InnoDB</literal>
+ <literal>InnoDB</literal> ignored table locks, which allowed
+ one to more easily simulate transactions with a combination of
+ <literal>MyISAM</literal> and <literal>InnoDB</literal>
tables. The default value is 1, which means that <literal>LOCK
- TABLES</literal> causes also <literal>InnoDB</literal> 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
+ TABLES</literal> causes also <literal>InnoDB</literal>
+ 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.
@@ -1501,9 +1504,10 @@
<para>
Starting from MySQL 4.1.1, you can add the option
<literal>innodb_file_per_table</literal> to
- <filename>my.cnf</filename>, and make <literal>InnoDB</literal> to store each table
- into its own <filename>.ibd</filename> file in a database
- directory of MySQL. See <xref linkend="multiple-tablespaces"/>.
+ <filename>my.cnf</filename>, and make <literal>InnoDB</literal> to
+ store each table into its own <filename>.ibd</filename> file in a
+ database directory of MySQL. See
+ <xref linkend="multiple-tablespaces"/>.
</para>
<section id="error-creating-innodb">
@@ -2019,13 +2023,13 @@
<listitem>
<para>
<literal>SET NULL</literal>: Delete or update the row from
- the parent table and set the foreign key column or columns in the
- child table to <literal>NULL</literal>. This is only valid
- if the foreign key columns do not have the <literal>NOT
- NULL</literal> qualifier specified. <literal>ON DELETE SET
- NULL</literal> is available starting from MySQL 3.23.50 and
- <literal>ON UPDATE SET NULL</literal> is available starting
- from 4.0.8.
+ the parent table and set the foreign key column or columns
+ in the child table to <literal>NULL</literal>. This is only
+ valid if the foreign key columns do not have the
+ <literal>NOT NULL</literal> qualifier specified. <literal>ON
+ DELETE SET NULL</literal> is available starting from MySQL
+ 3.23.50 and <literal>ON UPDATE SET NULL</literal> is
+ available starting from 4.0.8.
</para>
</listitem>
@@ -2071,11 +2075,11 @@
<para>
<literal>InnoDB</literal> supports the same options when the
candidate key in the parent table is updated. With
- <literal>CASCADE</literal>, the foreign key column or columns in the
- child table are set to the new values of the candidate key in the
- parent table. In the same way, the updates cascade if updated
- columns in the child table reference foreign keys in another
- table.
+ <literal>CASCADE</literal>, the foreign key column or columns in
+ the child table are set to the new values of the candidate key
+ in the parent table. In the same way, the updates cascade if
+ updated columns in the child table reference foreign keys in
+ another table.
</para>
<para>
@@ -2166,9 +2170,9 @@
default behavior should be deferred checking, that is,
constraints are only checked after the
<emphasis role="bold">whole SQL statement</emphasis> has been
- processed. Until <literal>InnoDB</literal> implements deferred constraint checking,
- some things will be impossible, such as deleting a record that
- refers to itself via a foreign key.
+ processed. Until <literal>InnoDB</literal> implements deferred
+ constraint checking, some things will be impossible, such as
+ deleting a record that refers to itself via a foreign key.
</para>
<para>
@@ -4572,12 +4576,12 @@
<para>
If nothing else helps, serialize your transactions with
table-level locks. The correct way to use <literal>LOCK
- TABLES</literal> with transactional tables, like <literal>InnoDB</literal>, is
- to set <literal>AUTOCOMMIT = 0</literal> and not to call
- <literal>UNLOCK TABLES</literal> until you commit the
- transaction explicitly. For example, if you need to write to
- table <literal>t1</literal> and read from table
- <literal>t2</literal>, you can do this:
+ TABLES</literal> with transactional tables, like
+ <literal>InnoDB</literal>, is to set <literal>AUTOCOMMIT =
+ 0</literal> and not to call <literal>UNLOCK TABLES</literal>
+ until you commit the transaction explicitly. For example, if
+ you need to write to table <literal>t1</literal> and read
+ from table <literal>t2</literal>, you can do this:
</para>
<programlisting>
@@ -4611,13 +4615,15 @@
<listitem>
<para>
In applications using <literal>AUTOCOMMIT=1</literal> and
- MySQL's <literal>LOCK TABLES</literal> command, <literal>InnoDB</literal>'s
- internal table locks that were present from 4.0.20 to 4.0.23
- can cause deadlocks. Starting from 4.0.22, you can set
+ MySQL's <literal>LOCK TABLES</literal> command,
+ <literal>InnoDB</literal>'s internal table locks that were
+ present from 4.0.20 to 4.0.23 can cause deadlocks. Starting
+ from 4.0.22, you can set
<literal>innodb_table_locks=0</literal> in
<filename>my.cnf</filename> to fall back to the old behavior
- and remove the problem. 4.0.24 does not set <literal>InnoDB</literal> table
- locks if <literal>AUTOCOMMIT=1</literal>.
+ and remove the problem. 4.0.24 does not set
+ <literal>InnoDB</literal> table locks if
+ <literal>AUTOCOMMIT=1</literal>.
</para>
</listitem>
@@ -4722,15 +4728,16 @@
<para>
(Verified using MySQL 4.1, assumed for other MySQL versions,
given that this is a platform architecture issue.) When using
- the <literal>InnoDB</literal> storage engine on Solaris 10 for x86_64
- architecture (AMD Opteron), it is important to mount any
- filesystems used for storing <literal>InnoDB</literal>-related files using the
+ the <literal>InnoDB</literal> storage engine on Solaris 10 for
+ x86_64 architecture (AMD Opteron), it is important to mount
+ any filesystems used for storing
+ <literal>InnoDB</literal>-related files using the
<literal>forcedirectio</literal> option. (The default on
Solaris 10/x86_64 is <emphasis>not</emphasis> to use this
filesystem mounting option.) Failing to use
<literal>forcedirectio</literal> will cause a serious
- degradation of <literal>InnoDB</literal>'s speed and performance on this
- platform.
+ degradation of <literal>InnoDB</literal>'s speed and
+ performance on this platform.
</para>
<para>
@@ -5844,9 +5851,10 @@
<para>
A symptom of fragmentation is that a table takes more space than
it <quote>should</quote> take. How much that is exactly, is
- difficult to determine. All <literal>InnoDB</literal> data and indexes are stored
- in B-trees, and their fill factor may vary from 50% to 100%.
- Another symptom of fragmentation is that a table scan such as:
+ difficult to determine. All <literal>InnoDB</literal> data and
+ indexes are stored in B-trees, and their fill factor may vary
+ from 50% to 100%. Another symptom of fragmentation is that a
+ table scan such as:
</para>
<programlisting>
@@ -7121,9 +7129,9 @@
course of a transaction. Unfortunately, <literal>LOCK
TABLES</literal> in MySQL performs an implicit
<literal>COMMIT</literal> and <literal>UNLOCK
- TABLES</literal>. An <literal>InnoDB</literal> variant of <literal>LOCK
- TABLES</literal> has been planned that can be executed in the
- middle of a transaction.
+ TABLES</literal>. An <literal>InnoDB</literal> variant of
+ <literal>LOCK TABLES</literal> has been planned that can be
+ executed in the middle of a transaction.
</para>
</listitem>
@@ -7316,10 +7324,11 @@
<para>
Older MySQL versions did not allow accessing any table with a
name containing &lsquo;<literal>#</literal>&rsquo;. The solution
- in older MySQL versions is to use a special <literal>InnoDB</literal> mechanism
- available starting from MySQL 3.23.48. When you have an orphaned
- table <filename>#sql-id</filename> inside the tablespace, you
- can cause <literal>InnoDB</literal> to rename it to
+ in older MySQL versions is to use a special
+ <literal>InnoDB</literal> mechanism available starting from
+ MySQL 3.23.48. When you have an orphaned table
+ <filename>#sql-id</filename> inside the tablespace, you can
+ cause <literal>InnoDB</literal> to rename it to
<filename>rsql-id_recover_innodb_tmp_table</filename> with the
following statement:
</para>
Modified: trunk/refman-4.1/installing.xml
===================================================================
--- trunk/refman-4.1/installing.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-4.1/installing.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -12877,10 +12877,10 @@
<para>
A new startup option named
<option>innodb_table_locks</option> was added that causes
- <literal>LOCK TABLE</literal> to also acquire <literal>InnoDB</literal> table
- locks. This option is enabled by default. This can cause
- deadlocks in applications that use
- <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
+ <literal>LOCK TABLE</literal> to also acquire
+ <literal>InnoDB</literal> table locks. This option is
+ enabled by default. This can cause deadlocks in applications
+ that use <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
TABLES</literal>. If you application encounters deadlocks
after upgrading, you may need to add
<literal>innodb_table_locks=0</literal> to your
@@ -12892,10 +12892,10 @@
<para>
A new startup option named
<option>innodb_table_locks</option> was added that causes
- <literal>LOCK TABLE</literal> to also acquire <literal>InnoDB</literal> table
- locks. This option is enabled by default. This can cause
- deadlocks in applications that use
- <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
+ <literal>LOCK TABLE</literal> to also acquire
+ <literal>InnoDB</literal> table locks. This option is
+ enabled by default. This can cause deadlocks in applications
+ that use <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
TABLES</literal>. If you application encounters deadlocks
after upgrading, you may need to add
<literal>innodb_table_locks=0</literal> to your
@@ -15056,7 +15056,8 @@
<para>
When using Solaris 10 for x86_64, you should mount any
- filesystems on which you intend to store <literal>InnoDB</literal> files with the
+ filesystems on which you intend to store
+ <literal>InnoDB</literal> files with the
<option>forcedirectio</option> option. (By default mounting is
done without this option.) Failing to do so will cause a
significant drop in performance when using the
@@ -17192,8 +17193,8 @@
<command>configure</command> command needs to build both a
static and a dynamic library in
<filename><replaceable>src_directory</replaceable>/bdb/build_unix/</filename>,
- but it does not with MySQL's own <literal>BDB</literal> version. The workaround
- is as follows.
+ but it does not with MySQL's own <literal>BDB</literal>
+ version. The workaround is as follows.
</para>
<orderedlist>
@@ -17515,8 +17516,8 @@
<command>configure</command> command needs to build both a
static and a dynamic library in
<filename><replaceable>src_directory</replaceable>/bdb/build_unix/</filename>,
- but it does not with MySQL's own <literal>BDB</literal> version. The workaround
- is as follows.
+ but it does not with MySQL's own <literal>BDB</literal>
+ version. The workaround is as follows.
</para>
<orderedlist>
Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-4.1/ndbcluster.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -1147,9 +1147,9 @@
CLuster storage engine in order to have them replicated in
the cluster. If you are importing tables from an existing
database using the output of <command>mysqldump</command>,
- you can open the SQL script or scripts in a text editor and add this
- option to any table creation statements, or replace any
- existing <literal>ENGINE</literal> (or
+ you can open the SQL script or scripts in a text editor and
+ add this option to any table creation statements, or replace
+ any existing <literal>ENGINE</literal> (or
<literal>TYPE</literal>) option with one of these. For
example, suppose that you have the sample
<literal>world</literal> database on another MySQL server
@@ -3101,11 +3101,10 @@
<para>
Records are kept for each transaction updating cluster
- data, both in the transaction coordinator and in the
- nodes where the actual updates are performed. These
- records contain state information needed in order to find
- UNDO records for rollback, lock queues, and other
- purposes.
+ data, both in the transaction coordinator and in the nodes
+ where the actual updates are performed. These records
+ contain state information needed in order to find UNDO
+ records for rollback, lock queues, and other purposes.
</para>
<para>
@@ -3464,9 +3463,9 @@
<para>
If the checkpointing is slow and there are so many writes
to the database that the log files are full and the log
- tail cannot be cut without jeopardizing recovery, then
- all updating transactions will be aborted with internal
- error code 410, or <literal>Out of log file space
+ tail cannot be cut without jeopardizing recovery, then all
+ updating transactions will be aborted with internal error
+ code 410, or <literal>Out of log file space
temporarily</literal>. This condition will prevail until a
checkpoint has completed and the log tail can be moved
forward.
@@ -4197,8 +4196,8 @@
<para>
Controls the number of index memory pages that can be
- written to disk during the local checkpoint phase of a node
- restart.
+ written to disk during the local checkpoint phase of a
+ node restart.
</para>
<para>
@@ -4728,9 +4727,9 @@
<para>
The speed at which queries are performed can vary by more
than 40% depending upon how this parameter is set. In
- future releases, MySQL Server will make educated
- guesses on how to set parameters relating to batch size,
- based on the query type.
+ future releases, MySQL Server will make educated guesses
+ on how to set parameters relating to batch size, based on
+ the query type.
</para>
<para>
@@ -8739,14 +8738,15 @@
<para>
In this section, we provide a listing of known limitations in
MySQL Cluster releases in the &current-series;.x series when
- compared to features available when using the <literal>MyISAM</literal> and <literal>InnoDB</literal>
- storage engines. Currently there are no plans to address these in
- coming releases of MySQL &current-series;; however, we will
- attempt to supply fixes for these issues in subsequent release
- series. If you check the <quote>Cluster</quote> category in the
- MySQL bugs database at <ulink url="http://bugs.mysql.com"/>, you
- can find known bugs which (if marked 4.1) we intend to correct in
- upcoming releases of MySQL 4.1.
+ compared to features available when using the
+ <literal>MyISAM</literal> and <literal>InnoDB</literal> storage
+ engines. Currently there are no plans to address these in coming
+ releases of MySQL &current-series;; however, we will attempt to
+ supply fixes for these issues in subsequent release series. If you
+ check the <quote>Cluster</quote> category in the MySQL bugs
+ database at <ulink url="http://bugs.mysql.com"/>, you can find
+ known bugs which (if marked 4.1) we intend to correct in upcoming
+ releases of MySQL 4.1.
</para>
<itemizedlist>
@@ -9240,14 +9240,15 @@
slow transaction can cause the slave to lag behind the master.
This means that if the master fails, it is possible that the
slave might not have recorded the last few transactions. If a
- transaction-safe engine such as <literal>InnoDB</literal> is being used, then a
- transaction will either be complete on the slave or not
- applied at all, but replication does not guarantee that all
- data on the master and the slave will be consistent at all
- times. In MySQL Cluster, all data nodes are kept in synch, and
- a transaction committed by any one data node is committed for
- all data nodes. In the event of a data node failure, all
- remaining data nodes will remain in a consistent state.
+ transaction-safe engine such as <literal>InnoDB</literal> is
+ being used, then a transaction will either be complete on the
+ slave or not applied at all, but replication does not
+ guarantee that all data on the master and the slave will be
+ consistent at all times. In MySQL Cluster, all data nodes are
+ kept in synch, and a transaction committed by any one data
+ node is committed for all data nodes. In the event of a data
+ node failure, all remaining data nodes will remain in a
+ consistent state.
</para>
<para>
Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-4.1/optimization.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -8247,8 +8247,8 @@
<para>
Symlinking can be accomplished manually from the command
line using <command>ln -s</command> if
- <command>mysqld</command> is not running. Alternatively, you
- can instruct a running MySQL server to perform the
+ <command>mysqld</command> is not running. Alternatively,
+ you can instruct a running MySQL server to perform the
symlinking by using the <literal>DATA DIRECTORY</literal>
and <literal>INDEX DIRECTORY</literal> options to
<literal>CREATE TABLE</literal>. See
Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-4.1/replication.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -179,11 +179,11 @@
Due to these limitations, we recommend that at this point you use
<literal>LOAD DATA FROM MASTER</literal> only if the dataset on
the master is relatively small, or if a prolonged read lock on the
- master is acceptable. Although the actual speed of <literal>LOAD DATA
- FROM MASTER</literal> may vary from system to system, a good rule
- of thumb for how long it takes is 1 second per 1MB of data. This
- is a rough estimate, but you should find it fairly accurate if
- both master and slave are equivalent to 700MHz Pentium CPUs in
+ master is acceptable. Although the actual speed of <literal>LOAD
+ DATA FROM MASTER</literal> may vary from system to system, a good
+ rule of thumb for how long it takes is 1 second per 1MB of data.
+ This is a rough estimate, but you should find it fairly accurate
+ if both master and slave are equivalent to 700MHz Pentium CPUs in
performance and are connected through a 100Mbps network.
</para>
@@ -1070,12 +1070,13 @@
<literal>InnoDB</literal> storage engine) the snapshot won't
be consistent (because the <literal>InnoDB</literal> caches
are not flushed), but there's no need to worry at all, because
- <literal>InnoDB</literal> will resolve this at startup, and consequently deliver
- a consistent result. This means that <literal>InnoDB</literal>
- will perform a crash recovery when started on this snapshot,
- but it will not be corrupted. If you want to have a consistent
- snapshot of your <literal>InnoDB</literal> tables, there's no
- way around taking down the MySQL server, though.
+ <literal>InnoDB</literal> will resolve this at startup, and
+ consequently deliver a consistent result. This means that
+ <literal>InnoDB</literal> will perform a crash recovery when
+ started on this snapshot, but it will not be corrupted. If you
+ want to have a consistent snapshot of your
+ <literal>InnoDB</literal> tables, there's no way around taking
+ down the MySQL server, though.
</para>
<para>
@@ -1835,8 +1836,8 @@
<literal>slave_transaction_retries</literal>: If the
replication slave SQL thread fails to execute a transaction
because of an <literal>InnoDB</literal> deadlock or exceeded
- <literal>InnoDB</literal>'s <literal>innodb_lock_wait_timeout</literal> or
- NDBCluster's
+ <literal>InnoDB</literal>'s
+ <literal>innodb_lock_wait_timeout</literal> or NDBCluster's
<literal>TransactionDeadlockDetectionTimeout</literal> or
<literal>TransactionInactiveTimeout</literal>, it
automatically retries
Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-4.1/sql-syntax.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -12884,10 +12884,11 @@
checks for secondary indexes in <literal>InnoDB</literal>
tables are performed. If set to <literal>0</literal>,
uniqueness checks are not done for index entries inserted
- into <literal>InnoDB</literal>'s insert buffer. If you know for certain that
- your data does not contain uniqueness violations, you can
- set this to 0 to speed up large table imports to <literal>InnoDB</literal>.
- This variable was added in MySQL 3.23.52.
+ into <literal>InnoDB</literal>'s insert buffer. If you know
+ for certain that your data does not contain uniqueness
+ violations, you can set this to 0 to speed up large table
+ imports to <literal>InnoDB</literal>. This variable was
+ added in MySQL 3.23.52.
</para>
</listitem>
Modified: trunk/refman-4.1/tutorial.xml
===================================================================
--- trunk/refman-4.1/tutorial.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-4.1/tutorial.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -3400,11 +3400,11 @@
<remark role="todo">
[js] This doesn't actually involve the creation of foreign keys
at all. If anything, it's an example of a rather novel sort of
- comment, and can't even be used with <literal>InnoDB</literal> tables. We should
- either (a) rewrite the section to include a real example using
- real foreign keys or (b) rename the section - or perhaps remove
- it altogether. IMO, all this does now is provide fuel for "See?
- MySQL doesn't really support FKs!" FUD.
+ comment, and can't even be used with <literal>InnoDB</literal>
+ tables. We should either (a) rewrite the section to include a
+ real example using real foreign keys or (b) rename the section -
+ or perhaps remove it altogether. IMO, all this does now is
+ provide fuel for "See? MySQL doesn't really support FKs!" FUD.
</remark>
<para>
Modified: trunk/refman-5.0/apis.xml
===================================================================
--- trunk/refman-5.0/apis.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.0/apis.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -359,9 +359,10 @@
<listitem>
<para>
- We have to change <literal>InnoDB</literal> not to be so verbose when using the
- embedded version. If your database does not contain <literal>InnoDB</literal>
- tables, to suppress related messages you can add the
+ We have to change <literal>InnoDB</literal> not to be so
+ verbose when using the embedded version. If your database
+ does not contain <literal>InnoDB</literal> tables, to
+ suppress related messages you can add the
<option>--skip-innodb</option> option to the options file
under the group <literal>[libmysqd_server]</literal>, or
when initializing the server with
Modified: trunk/refman-5.0/charset.xml
===================================================================
--- trunk/refman-5.0/charset.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.0/charset.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -2714,8 +2714,8 @@
<literal>latin1</literal> is the default character set. The
<literal>latin1_swedish_ci</literal> collation is the
default that probably is used by the majority of MySQL
- customers. Although it is frequently said that it is based on
- the Swedish/Finnish collation rules, there are Swedes and
+ customers. Although it is frequently said that it is based
+ on the Swedish/Finnish collation rules, there are Swedes and
Finns who disagree with this statement.
</para>
Modified: trunk/refman-5.0/connector-j.xml
===================================================================
--- trunk/refman-5.0/connector-j.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.0/connector-j.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -2741,9 +2741,9 @@
<para>
The earliest the locks these statements hold can be released
- (whether they be <literal>MyISAM</literal> table-level locks or row-level locks
- in some other storage engine such as <literal>InnoDB</literal>) is when the
- statement completes.
+ (whether they be <literal>MyISAM</literal> table-level locks
+ or row-level locks in some other storage engine such as
+ <literal>InnoDB</literal>) is when the statement completes.
</para>
<para>
@@ -4573,9 +4573,9 @@
Because MySQL does not have row identifiers, MySQL
Connector/J can only update result sets that have come
from queries on tables that have at least one primary key,
- the query must select every primary key and the
- query can only span one table (that is, no joins). This is
- outlined in the JDBC specification.
+ the query must select every primary key and the query can
+ only span one table (that is, no joins). This is outlined
+ in the JDBC specification.
</para>
</answer>
Modified: trunk/refman-5.0/connector-odbc.xml
===================================================================
--- trunk/refman-5.0/connector-odbc.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.0/connector-odbc.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -4455,8 +4455,8 @@
</para>
<para>
- <emphasis role="bold">To import or link a table or tables from MySQL to
- Access, follow the instructions:</emphasis>
+ <emphasis role="bold">To import or link a table or tables from
+ MySQL to Access, follow the instructions:</emphasis>
</para>
<orderedlist>
Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.0/database-administration.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -350,11 +350,12 @@
</para>
<para>
- This option enables support for the <literal>InnoDB</literal> storage engine.
- MySQL-Max servers always include <literal>InnoDB</literal> support. From MySQL
- 4.0 onward, <literal>InnoDB</literal> is included by default in all binary
- distributions, so you do not need a MySQL-Max server merely
- to obtain <literal>InnoDB</literal> support.
+ This option enables support for the
+ <literal>InnoDB</literal> storage engine. MySQL-Max servers
+ always include <literal>InnoDB</literal> support. From MySQL
+ 4.0 onward, <literal>InnoDB</literal> is included by default
+ in all binary distributions, so you do not need a MySQL-Max
+ server merely to obtain <literal>InnoDB</literal> support.
</para>
</listitem>
@@ -419,8 +420,9 @@
</para>
<para>
- MySQL-Max servers include the <literal>BerkeleyDB</literal> (<literal>BDB</literal>) storage engine
- whenever possible, but not all platforms support <literal>BDB</literal>.
+ MySQL-Max servers include the <literal>BerkeleyDB</literal>
+ (<literal>BDB</literal>) storage engine whenever possible, but
+ not all platforms support <literal>BDB</literal>.
</para>
<para>
@@ -2408,7 +2410,8 @@
shut down. The default is 35 seconds. After the delay
expires, the IM assumes that the instance is hanging and
attempts to <literal>kill -9</literal> it. If you use
- <literal>InnoDB</literal> with large tables, you should increase this value.
+ <literal>InnoDB</literal> with large tables, you should
+ increase this value.
</para>
</listitem>
@@ -5222,17 +5225,17 @@
</para>
<para>
-When you use a startup option to set a variable that takes a numeric value,
- the value can be given with a suffix of
- <literal>K</literal>, <literal>M</literal>, or
- <literal>G</literal> (either uppercase or lowercase) to indicate
- a multiplier of 1024, 1024<superscript>2</superscript> or
- 1024<superscript>3</superscript>. For example, when used to set
- <literal>key_buffer_size</literal>, the suffixes indicate
- units of kilobytes, megabytes, or gigabygtes.
- Thus,
- the following command starts the server with a key buffer size
- of 16 megabytes:
+ When you use a startup option to set a variable that takes a
+ numeric value, the value can be given with a suffix of
+ <literal>K</literal>, <literal>M</literal>, or
+ <literal>G</literal> (either uppercase or lowercase) to
+ indicate a multiplier of 1024,
+ 1024<superscript>2</superscript> or
+ 1024<superscript>3</superscript>. For example, when used to
+ set <literal>key_buffer_size</literal>, the suffixes indicate
+ units of kilobytes, megabytes, or gigabygtes. Thus, the
+ following command starts the server with a key buffer size of
+ 16 megabytes:
</para>
<programlisting>
@@ -6190,18 +6193,16 @@
</row>
<row>
<entry>1</entry>
- <entry>(Default) Enables concurrent insert for
-<literal>MyISAM</literal> tables that don't have
- holes</entry>
+ <entry>(Default) Enables concurrent insert for <literal>MyISAM</literal> tables
+ that don't have holes</entry>
</row>
<row>
<entry>2</entry>
- <entry>Enables concurrent inserts for all
-<literal>MyISAM</literal> tables. If table has a hole
- and is in use by another thread the new row will
- be inserted at end of table. If table is not in
- use then MySQL will do a normal read lock and
- insert the new row into the hole.</entry>
+ <entry>Enables concurrent inserts for all <literal>MyISAM</literal> tables. If
+ table has a hole and is in use by another thread
+ the new row will be inserted at end of table. If
+ table is not in use then MySQL will do a normal
+ read lock and insert the new row into the hole.</entry>
</row>
</tbody>
</tgroup>
@@ -7034,9 +7035,10 @@
</para>
<para>
- It is possible to create multiple <literal>MyISAM</literal> key caches. The
- size limit of 4GB applies to each cache individually, not
- as a group. See <xref linkend="myisam-key-cache"/>.
+ It is possible to create multiple
+ <literal>MyISAM</literal> key caches. The size limit of
+ 4GB applies to each cache individually, not as a group.
+ See <xref linkend="myisam-key-cache"/>.
</para>
</listitem>
@@ -11430,8 +11432,9 @@
<para>
Each storage engine performs any actions necessary for tables
- that it manages. For example, <literal>MyISAM</literal> flushes any pending index
- writes for a table. <literal>InnoDB</literal> flushes its buffer pool to disk
+ that it manages. For example, <literal>MyISAM</literal>
+ flushes any pending index writes for a table.
+ <literal>InnoDB</literal> flushes its buffer pool to disk
(starting from 5.0.5: unless
<literal>innodb_fast_shutdown</literal> is 2), writes the
current LSN to the tablespace, and terminates its own internal
Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.0/innodb.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -195,10 +195,10 @@
because of write operations having been reordered. If data
integrity is important to you, you should perform some
<quote>pull-the-plug</quote> tests before using anything in
- production. On Mac OS X 10.3 and later, <literal>InnoDB</literal> uses a special
- <literal>fcntl()</literal> file flush method. Under Linux, it is
- advisable to <emphasis role="bold">disable the write-back
- cache</emphasis>.
+ production. On Mac OS X 10.3 and later, <literal>InnoDB</literal>
+ uses a special <literal>fcntl()</literal> file flush method. Under
+ Linux, it is advisable to <emphasis role="bold">disable the
+ write-back cache</emphasis>.
</para>
<para>
@@ -881,10 +881,10 @@
If you set this parameter to 1, <literal>InnoDB</literal>
skips these operations at shutdown. The default value is 1. If
you set it to 2 (available starting from MySQL 5.0.5, except
- on Netware), <literal>InnoDB</literal> will just flush its logs and then shut
- down cold, as if MySQL had crashed; no committed transaction
- will be lost, but a crash recovery will be done at next
- startup.
+ on Netware), <literal>InnoDB</literal> will just flush its
+ logs and then shut down cold, as if MySQL had crashed; no
+ committed transaction will be lost, but a crash recovery will
+ be done at next startup.
</para>
</listitem>
@@ -961,20 +961,21 @@
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
+ <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.
+ 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.
</para>
</listitem>
@@ -1029,8 +1030,9 @@
transaction may wait for a lock before being rolled back.
<literal>InnoDB</literal> automatically detects transaction
deadlocks in its own lock table and rolls back the
- transaction. <literal>InnoDB</literal> notices locks set using the <literal>LOCK
- TABLES</literal> statement. The default is 50 seconds.
+ transaction. <literal>InnoDB</literal> notices locks set using
+ the <literal>LOCK TABLES</literal> statement. The default is
+ 50 seconds.
</para>
<para>
@@ -1092,9 +1094,10 @@
you execute the same <literal>SELECT</literal> within the same
transaction, you see a new row in the result set returned by
the query. This also means, that if new items are added to the
- database, <literal>InnoDB</literal> does not guarantee serializability; however,
- conflict serializability is still guaranteed. Therefore, if
- this option is used <literal>InnoDB</literal> guarantees at most isolation level
+ database, <literal>InnoDB</literal> does not guarantee
+ serializability; however, conflict serializability is still
+ guaranteed. Therefore, if this option is used
+ <literal>InnoDB</literal> guarantees at most isolation level
<literal>READ COMMITTED</literal>.
</para>
@@ -1297,8 +1300,8 @@
</para>
<para>
- The <literal>InnoDB</literal> transaction system maintains a list of transactions
- that have delete-marked index records by
+ The <literal>InnoDB</literal> transaction system maintains a
+ list of transactions that have delete-marked index records by
<literal>UPDATE</literal> or <literal>DELETE</literal>
operations. Let the length of this list be
<replaceable>purge_lag</replaceable>. When
@@ -1421,13 +1424,13 @@
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 is 1, which
- means that <literal>LOCK TABLES</literal> causes <literal>InnoDB</literal> to
- lock a table internally. 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.
+ means that <literal>LOCK TABLES</literal> causes
+ <literal>InnoDB</literal> to lock a table internally. 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.
</para>
</listitem>
@@ -1565,9 +1568,10 @@
<para>
You can add the option <literal>innodb_file_per_table</literal> to
- <filename>my.cnf</filename>, and make <literal>InnoDB</literal> to store each table
- into its own <filename>.ibd</filename> file in a database
- directory of MySQL. See <xref linkend="multiple-tablespaces"/>.
+ <filename>my.cnf</filename>, and make <literal>InnoDB</literal> to
+ store each table into its own <filename>.ibd</filename> file in a
+ database directory of MySQL. See
+ <xref linkend="multiple-tablespaces"/>.
</para>
<section id="error-creating-innodb">
@@ -2073,12 +2077,12 @@
<listitem>
<para>
<literal>SET NULL</literal>: Delete or update the row from
- the parent table and set the foreign key column or columns in the
- child table to <literal>NULL</literal>. This is only valid
- if the foreign key columns do not have the <literal>NOT
- NULL</literal> qualifier specified. Both <literal>ON DELETE
- SET NULL</literal> and <literal>ON UPDATE SET NULL</literal>
- clauses are supported.
+ the parent table and set the foreign key column or columns
+ in the child table to <literal>NULL</literal>. This is only
+ valid if the foreign key columns do not have the
+ <literal>NOT NULL</literal> qualifier specified. Both
+ <literal>ON DELETE SET NULL</literal> and <literal>ON UPDATE
+ SET NULL</literal> clauses are supported.
</para>
</listitem>
@@ -2124,11 +2128,11 @@
<para>
<literal>InnoDB</literal> supports the same options when the
candidate key in the parent table is updated. With
- <literal>CASCADE</literal>, the foreign key column or columns in the
- child table are set to the new values of the candidate key in the
- parent table. In the same way, the updates cascade if updated
- columns in the child table reference foreign keys in another
- table.
+ <literal>CASCADE</literal>, the foreign key column or columns in
+ the child table are set to the new values of the candidate key
+ in the parent table. In the same way, the updates cascade if
+ updated columns in the child table reference foreign keys in
+ another table.
</para>
<para>
@@ -2218,10 +2222,10 @@
constraints row-by-row. According to the SQL standard, the
default behavior should be deferred checking, that is,
constraints are only checked after the <emphasis>entire SQL
- statement</emphasis> has been processed. Until <literal>InnoDB</literal> implements
- deferred constraint checking, some things will be impossible,
- such as deleting a record that refers to itself via a foreign
- key.
+ statement</emphasis> has been processed. Until
+ <literal>InnoDB</literal> implements deferred constraint
+ checking, some things will be impossible, such as deleting a
+ record that refers to itself via a foreign key.
</para>
<para>
@@ -4531,12 +4535,12 @@
<para>
If nothing else helps, serialize your transactions with
table-level locks. The correct way to use <literal>LOCK
- TABLES</literal> with transactional tables, like <literal>InnoDB</literal>, is
- to set <literal>AUTOCOMMIT = 0</literal> and not to call
- <literal>UNLOCK TABLES</literal> until you commit the
- transaction explicitly. For example, if you need to write to
- table <literal>t1</literal> and read from table
- <literal>t2</literal>, you can do this:
+ TABLES</literal> with transactional tables, like
+ <literal>InnoDB</literal>, is to set <literal>AUTOCOMMIT =
+ 0</literal> and not to call <literal>UNLOCK TABLES</literal>
+ until you commit the transaction explicitly. For example, if
+ you need to write to table <literal>t1</literal> and read
+ from table <literal>t2</literal>, you can do this:
</para>
<programlisting>
@@ -4570,8 +4574,8 @@
<listitem>
<para>
In applications using the <literal>LOCK TABLES</literal>
- command, MySQL does not set <literal>InnoDB</literal> table locks if
- <literal>AUTOCOMMIT=1</literal>.
+ command, MySQL does not set <literal>InnoDB</literal> table
+ locks if <literal>AUTOCOMMIT=1</literal>.
</para>
</listitem>
@@ -4657,8 +4661,8 @@
<para>
When using <literal>row_format=compact</literal> (the default
- <literal>InnoDB</literal> record format in MySQL &current-series;) and
- variable-length character sets, such as
+ <literal>InnoDB</literal> record format in MySQL
+ &current-series;) and variable-length character sets, such as
<literal>utf8</literal> or <literal>sjis</literal>,
<literal>CHAR(<replaceable>N</replaceable>)</literal> will
occupy a variable amount of space, at least
@@ -4682,15 +4686,16 @@
<listitem>
<para>
- When using the <literal>InnoDB</literal> storage engine on Solaris 10 for x86_64
- architecture (AMD Opteron), it is important to mount any
- filesystems used for storing <literal>InnoDB</literal>-related files using the
+ When using the <literal>InnoDB</literal> storage engine on
+ Solaris 10 for x86_64 architecture (AMD Opteron), it is
+ important to mount any filesystems used for storing
+ <literal>InnoDB</literal>-related files using the
<literal>forcedirectio</literal> option. (The default on
Solaris 10/x86_64 is <emphasis>not</emphasis> to use this
filesystem mounting option.) Failing to use
<literal>forcedirectio</literal> will cause a serious
- degradation of <literal>InnoDB</literal>'s speed and performance on this
- platform.
+ degradation of <literal>InnoDB</literal>'s speed and
+ performance on this platform.
</para>
<para>
@@ -5794,9 +5799,10 @@
<para>
A symptom of fragmentation is that a table takes more space than
it <quote>should</quote> take. How much that is exactly, is
- difficult to determine. All <literal>InnoDB</literal> data and indexes are stored
- in B-trees, and their fill factor may vary from 50% to 100%.
- Another symptom of fragmentation is that a table scan such as:
+ difficult to determine. All <literal>InnoDB</literal> data and
+ indexes are stored in B-trees, and their fill factor may vary
+ from 50% to 100%. Another symptom of fragmentation is that a
+ table scan such as:
</para>
<programlisting>
@@ -7063,9 +7069,9 @@
course of a transaction. Unfortunately, <literal>LOCK
TABLES</literal> in MySQL performs an implicit
<literal>COMMIT</literal> and <literal>UNLOCK
- TABLES</literal>. An <literal>InnoDB</literal> variant of <literal>LOCK
- TABLES</literal> has been planned that can be executed in the
- middle of a transaction.
+ TABLES</literal>. An <literal>InnoDB</literal> variant of
+ <literal>LOCK TABLES</literal> has been planned that can be
+ executed in the middle of a transaction.
</para>
</listitem>
Modified: trunk/refman-5.0/installing.xml
===================================================================
--- trunk/refman-5.0/installing.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.0/installing.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -12560,10 +12560,10 @@
<para>
A new startup option named
<option>innodb_table_locks</option> was added that causes
- <literal>LOCK TABLE</literal> to also acquire <literal>InnoDB</literal> table
- locks. This option is enabled by default. This can cause
- deadlocks in applications that use
- <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
+ <literal>LOCK TABLE</literal> to also acquire
+ <literal>InnoDB</literal> table locks. This option is
+ enabled by default. This can cause deadlocks in applications
+ that use <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
TABLES</literal>. If you application encounters deadlocks
after upgrading, you may need to add
<literal>innodb_table_locks=0</literal> to your
@@ -12575,10 +12575,10 @@
<para>
A new startup option named
<option>innodb_table_locks</option> was added that causes
- <literal>LOCK TABLE</literal> to also acquire <literal>InnoDB</literal> table
- locks. This option is enabled by default. This can cause
- deadlocks in applications that use
- <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
+ <literal>LOCK TABLE</literal> to also acquire
+ <literal>InnoDB</literal> table locks. This option is
+ enabled by default. This can cause deadlocks in applications
+ that use <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
TABLES</literal>. If you application encounters deadlocks
after upgrading, you may need to add
<literal>innodb_table_locks=0</literal> to your
@@ -14226,11 +14226,12 @@
<para>
When using Solaris 10 for x86_64, you should mount any
- filesystems on which you intend to store <literal>InnoDB</literal> files with the
+ filesystems on which you intend to store
+ <literal>InnoDB</literal> files with the
<literal>forcedirectio</literal> option. (By default mounting is
done without this option.) Failing to do so will cause a
- significant drop in performance when using the <literal>InnoDB</literal> storage
- engine on this platform.
+ significant drop in performance when using the
+ <literal>InnoDB</literal> storage engine on this platform.
</para>
<para>
@@ -16357,8 +16358,8 @@
<command>configure</command> command needs to build both a
static and a dynamic library in
<filename><replaceable>src_directory</replaceable>/bdb/build_unix/</filename>,
- but it does not with MySQL's own <literal>BDB</literal> version. The workaround
- is as follows.
+ but it does not with MySQL's own <literal>BDB</literal>
+ version. The workaround is as follows.
</para>
<orderedlist>
@@ -16675,8 +16676,8 @@
<command>configure</command> command needs to build both a
static and a dynamic library in
<filename><replaceable>src_directory</replaceable>/bdb/build_unix/</filename>,
- but it does not with MySQL's own <literal>BDB</literal> version. The workaround
- is as follows.
+ but it does not with MySQL's own <literal>BDB</literal>
+ version. The workaround is as follows.
</para>
<orderedlist>
Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.0/ndbcluster.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -1153,9 +1153,9 @@
CLuster storage engine in order to have them replicated in
the cluster. If you are importing tables from an existing
database using the output of <command>mysqldump</command>,
- you can open the SQL script or scripts in a text editor and add this
- option to any table creation statements, or replace any
- existing <literal>ENGINE</literal> (or
+ you can open the SQL script or scripts in a text editor and
+ add this option to any table creation statements, or replace
+ any existing <literal>ENGINE</literal> (or
<literal>TYPE</literal>) option with one of these. For
example, suppose that you have the sample
<literal>world</literal> database on another MySQL server
@@ -3107,11 +3107,10 @@
<para>
Records are kept for each transaction updating cluster
- data, both in the transaction coordinator and in the
- nodes where the actual updates are performed. These
- records contain state information needed in order to find
- UNDO records for rollback, lock queues, and other
- purposes.
+ data, both in the transaction coordinator and in the nodes
+ where the actual updates are performed. These records
+ contain state information needed in order to find UNDO
+ records for rollback, lock queues, and other purposes.
</para>
<para>
@@ -3474,9 +3473,9 @@
<para>
If the checkpointing is slow and there are so many writes
to the database that the log files are full and the log
- tail cannot be cut without jeopardizing recovery, then
- all updating transactions will be aborted with internal
- error code 410, or <literal>Out of log file space
+ tail cannot be cut without jeopardizing recovery, then all
+ updating transactions will be aborted with internal error
+ code 410, or <literal>Out of log file space
temporarily</literal>. This condition will prevail until a
checkpoint has completed and the log tail can be moved
forward.
@@ -4211,8 +4210,8 @@
<para>
Controls the number of index memory pages that can be
- written to disk during the local checkpoint phase of a node
- restart.
+ written to disk during the local checkpoint phase of a
+ node restart.
</para>
<para>
@@ -4741,9 +4740,9 @@
<para>
The speed at which queries are performed can vary by more
than 40% depending upon how this parameter is set. In
- future releases, MySQL Server will make educated
- guesses on how to set parameters relating to batch size,
- based on the query type.
+ future releases, MySQL Server will make educated guesses
+ on how to set parameters relating to batch size, based on
+ the query type.
</para>
<para>
@@ -8009,13 +8008,13 @@
<para>
<literal>NDB</literal> does not support repeatable reads,
- which can cause problems with the restoration process. Although
- the backup process is <quote>hot</quote>, restoring a MySQL
- Cluster from backup is not a 100% <quote>hot</quote> process.
- This is due to the fact that, for the duration of the restore
- process, running transactions get non-repeatable reads from
- the restored data. This means that the state of the data is
- inconsistent while the restore is in progress.
+ which can cause problems with the restoration process.
+ Although the backup process is <quote>hot</quote>, restoring a
+ MySQL Cluster from backup is not a 100% <quote>hot</quote>
+ process. This is due to the fact that, for the duration of the
+ restore process, running transactions get non-repeatable reads
+ from the restored data. This means that the state of the data
+ is inconsistent while the restore is in progress.
</para>
<remark role="todo">
@@ -8720,15 +8719,15 @@
<para>
In this section, we provide a listing of known limitations in
MySQL Cluster releases in the &current-series;.x series when
- compared to features available when using the <literal>MyISAM</literal> and <literal>InnoDB</literal>
- storage engines. Currently there are no plans to address these in
- coming releases of MySQL &current-series;; however, we will
- attempt to supply fixes for these issues in subsequent release
- series. If you check the <quote>Cluster</quote> category in the
- MySQL bugs database at <ulink url="http://bugs.mysql.com"/>, you
- can find known bugs which (if marked
- <quote>&current-series;</quote>) we intend to correct in upcoming
- releases of MySQL &current-series;.
+ compared to features available when using the
+ <literal>MyISAM</literal> and <literal>InnoDB</literal> storage
+ engines. Currently there are no plans to address these in coming
+ releases of MySQL &current-series;; however, we will attempt to
+ supply fixes for these issues in subsequent release series. If you
+ check the <quote>Cluster</quote> category in the MySQL bugs
+ database at <ulink url="http://bugs.mysql.com"/>, you can find
+ known bugs which (if marked <quote>&current-series;</quote>) we
+ intend to correct in upcoming releases of MySQL &current-series;.
</para>
<para>
@@ -9517,14 +9516,15 @@
slow transaction can cause the slave to lag behind the master.
This means that if the master fails, it is possible that the
slave might not have recorded the last few transactions. If a
- transaction-safe engine such as <literal>InnoDB</literal> is being used, then a
- transaction will either be complete on the slave or not
- applied at all, but replication does not guarantee that all
- data on the master and the slave will be consistent at all
- times. In MySQL Cluster, all data nodes are kept in synch, and
- a transaction committed by any one data node is committed for
- all data nodes. In the event of a data node failure, all
- remaining data nodes will remain in a consistent state.
+ transaction-safe engine such as <literal>InnoDB</literal> is
+ being used, then a transaction will either be complete on the
+ slave or not applied at all, but replication does not
+ guarantee that all data on the master and the slave will be
+ consistent at all times. In MySQL Cluster, all data nodes are
+ kept in synch, and a transaction committed by any one data
+ node is committed for all data nodes. In the event of a data
+ node failure, all remaining data nodes will remain in a
+ consistent state.
</para>
<para>
Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.0/optimization.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -6688,20 +6688,20 @@
<para>
Starting with MySQL/InnoDB 5.0.3, <literal>InnoDB</literal>
tables use a more compact storage format. In earlier
- versions of MySQL, <literal>InnoDB</literal> records contain some redundant
- information, such as the number of columns and the length of
- each column, even for fixed-size columns. By default, tables
- are created in the compact format
+ versions of MySQL, <literal>InnoDB</literal> records contain
+ some redundant information, such as the number of columns
+ and the length of each column, even for fixed-size columns.
+ By default, tables are created in the compact format
(<literal>ROW_FORMAT=COMPACT</literal>). If you wish to
downgrade to older versions of MySQL/InnoDB, you can request
the old format with <literal>ROW_FORMAT=REDUNDANT</literal>.
</para>
<para>
- The compact <literal>InnoDB</literal> format also changes the way how
- <literal>CHAR</literal> columns containing UTF-8 data are
- stored. In the <literal>ROW_FORMAT=REDUNDANT</literal>
- format, a UTF-8
+ The compact <literal>InnoDB</literal> format also changes
+ the way how <literal>CHAR</literal> columns containing UTF-8
+ data are stored. In the
+ <literal>ROW_FORMAT=REDUNDANT</literal> format, a UTF-8
<literal>CHAR(<replaceable>n</replaceable>)</literal>
occupies 3*<replaceable>n</replaceable> bytes, given that
the maximum length of a UTF-8 encoded character is 3 bytes.
@@ -9801,8 +9801,8 @@
<para>
Symlinking can be accomplished manually from the command
line using <literal>ln -s</literal> if
- <command>mysqld</command> is not running. Alternatively, you
- can instruct a running MySQL server to perform the
+ <command>mysqld</command> is not running. Alternatively,
+ you can instruct a running MySQL server to perform the
symlinking by using the <literal>DATA DIRECTORY</literal>
and <literal>INDEX DIRECTORY</literal> options to
<literal>CREATE TABLE</literal>. See
Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.0/replication.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -71,11 +71,11 @@
<xref linkend="ndbcluster"/>.) The master server writes updates to
its binary log files, and maintains an index of the files to keep
track of log rotation. These logs serve as records of updates to
- be sent to any slave servers. When a slave connects to the
- master, it informs the master of the position up to which the
- slave read in the logs at the last successful update. The slave
- receives any updates that have taken place since that time, and
- then blocks and waits for the master to notify it of new updates.
+ be sent to any slave servers. When a slave connects to the master,
+ it informs the master of the position up to which the slave read
+ in the logs at the last successful update. The slave receives any
+ updates that have taken place since that time, and then blocks and
+ waits for the master to notify it of new updates.
</para>
<para>
@@ -180,11 +180,11 @@
Due to these limitations, we recommend that at this point you use
<literal>LOAD DATA FROM MASTER</literal> only if the dataset on
the master is relatively small, or if a prolonged read lock on the
- master is acceptable. Although the actual speed of <literal>LOAD DATA
- FROM MASTER</literal> may vary from system to system, a good rule
- of thumb for how long it takes is 1 second per 1MB of data. This
- is a rough estimate, but you should find it fairly accurate if
- both master and slave are equivalent to 700MHz Pentium CPUs in
+ master is acceptable. Although the actual speed of <literal>LOAD
+ DATA FROM MASTER</literal> may vary from system to system, a good
+ rule of thumb for how long it takes is 1 second per 1MB of data.
+ This is a rough estimate, but you should find it fairly accurate
+ if both master and slave are equivalent to 700MHz Pentium CPUs in
performance and are connected through a 100Mbps network.
</para>
@@ -1756,8 +1756,8 @@
<literal>slave_transaction_retries</literal>: If the
replication slave SQL thread fails to execute a transaction
because of an <literal>InnoDB</literal> deadlock or exceeded
- <literal>InnoDB</literal>'s <literal>innodb_lock_wait_timeout</literal> or
- NDBCluster's
+ <literal>InnoDB</literal>'s
+ <literal>innodb_lock_wait_timeout</literal> or NDBCluster's
<literal>TransactionDeadlockDetectionTimeout</literal> or
<literal>TransactionInactiveTimeout</literal>, it
automatically retries
Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.0/sql-syntax.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -14164,9 +14164,10 @@
checks for secondary indexes in <literal>InnoDB</literal>
tables are performed. If set to <literal>0</literal>,
uniqueness checks are not done for index entries inserted
- into <literal>InnoDB</literal>'s insert buffer. If you know for certain that
- your data does not contain uniqueness violations, you can
- set this to 0 to speed up large table imports to <literal>InnoDB</literal>.
+ into <literal>InnoDB</literal>'s insert buffer. If you know
+ for certain that your data does not contain uniqueness
+ violations, you can set this to 0 to speed up large table
+ imports to <literal>InnoDB</literal>.
</para>
</listitem>
@@ -16500,8 +16501,9 @@
Starting with MySQL/InnoDB 5.0.3, the format of
<literal>InnoDB</literal> tables is reported as
<literal>Redundant</literal> or
- <literal>Compact</literal>. Prior to 5.0.3, <literal>InnoDB</literal> tables
- are always in the <literal>Redundant</literal> format.
+ <literal>Compact</literal>. Prior to 5.0.3,
+ <literal>InnoDB</literal> tables are always in the
+ <literal>Redundant</literal> format.
</para>
</listitem>
Modified: trunk/refman-5.1/apis.xml
===================================================================
--- trunk/refman-5.1/apis.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.1/apis.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -359,9 +359,10 @@
<listitem>
<para>
- We have to change <literal>InnoDB</literal> not to be so verbose when using the
- embedded version. If your database does not contain <literal>InnoDB</literal>
- tables, to suppress related messages you can add the
+ We have to change <literal>InnoDB</literal> not to be so
+ verbose when using the embedded version. If your database
+ does not contain <literal>InnoDB</literal> tables, to
+ suppress related messages you can add the
<option>--skip-innodb</option> option to the options file
under the group <literal>[libmysqd_server]</literal>, or
when initializing the server with
Modified: trunk/refman-5.1/charset.xml
===================================================================
--- trunk/refman-5.1/charset.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.1/charset.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -2711,8 +2711,8 @@
<literal>latin1</literal> is the default character set. The
<literal>latin1_swedish_ci</literal> collation is the
default that probably is used by the majority of MySQL
- customers. Although it is frequently said that it is based on
- the Swedish/Finnish collation rules, there are Swedes and
+ customers. Although it is frequently said that it is based
+ on the Swedish/Finnish collation rules, there are Swedes and
Finns who disagree with this statement.
</para>
Modified: trunk/refman-5.1/connector-j.xml
===================================================================
--- trunk/refman-5.1/connector-j.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.1/connector-j.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -2741,9 +2741,9 @@
<para>
The earliest the locks these statements hold can be released
- (whether they be <literal>MyISAM</literal> table-level locks or row-level locks
- in some other storage engine such as <literal>InnoDB</literal>) is when the
- statement completes.
+ (whether they be <literal>MyISAM</literal> table-level locks
+ or row-level locks in some other storage engine such as
+ <literal>InnoDB</literal>) is when the statement completes.
</para>
<para>
@@ -4573,9 +4573,9 @@
Because MySQL does not have row identifiers, MySQL
Connector/J can only update result sets that have come
from queries on tables that have at least one primary key,
- the query must select every primary key and the
- query can only span one table (that is, no joins). This is
- outlined in the JDBC specification.
+ the query must select every primary key and the query can
+ only span one table (that is, no joins). This is outlined
+ in the JDBC specification.
</para>
</answer>
Modified: trunk/refman-5.1/connector-odbc.xml
===================================================================
--- trunk/refman-5.1/connector-odbc.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.1/connector-odbc.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -4455,8 +4455,8 @@
</para>
<para>
- <emphasis role="bold">To import or link a table or tables from MySQL to
- Access, follow the instructions:</emphasis>
+ <emphasis role="bold">To import or link a table or tables from
+ MySQL to Access, follow the instructions:</emphasis>
</para>
<orderedlist>
Modified: trunk/refman-5.1/custom-engine.xml
===================================================================
--- trunk/refman-5.1/custom-engine.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.1/custom-engine.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -12342,7 +12342,8 @@
is the size needed to store current_position. ref is just a byte
array that the server will maintain. If you are using offsets to
mark rows, then current_position should be the offset. If it is
- a primary key like in <literal>BDB</literal>, then it needs to be a primary key.
+ a primary key like in <literal>BDB</literal>, then it needs to
+ be a primary key.
</para>
<para>
Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.1/database-administration.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -350,11 +350,12 @@
</para>
<para>
- This option enables support for the <literal>InnoDB</literal> storage engine.
- MySQL-Max servers always include <literal>InnoDB</literal> support. From MySQL
- 4.0 onward, <literal>InnoDB</literal> is included by default in all binary
- distributions, so you do not need a MySQL-Max server merely
- to obtain <literal>InnoDB</literal> support.
+ This option enables support for the
+ <literal>InnoDB</literal> storage engine. MySQL-Max servers
+ always include <literal>InnoDB</literal> support. From MySQL
+ 4.0 onward, <literal>InnoDB</literal> is included by default
+ in all binary distributions, so you do not need a MySQL-Max
+ server merely to obtain <literal>InnoDB</literal> support.
</para>
</listitem>
@@ -419,8 +420,9 @@
</para>
<para>
- MySQL-Max servers include the <literal>BerkeleyDB</literal> (<literal>BDB</literal>) storage engine
- whenever possible, but not all platforms support <literal>BDB</literal>.
+ MySQL-Max servers include the <literal>BerkeleyDB</literal>
+ (<literal>BDB</literal>) storage engine whenever possible, but
+ not all platforms support <literal>BDB</literal>.
</para>
<para>
@@ -2392,7 +2394,8 @@
shut down. The default is 35 seconds. After the delay
expires, the IM assumes that the instance is hanging and
attempts to <literal>kill -9</literal> it. If you use
- <literal>InnoDB</literal> with large tables, you should increase this value.
+ <literal>InnoDB</literal> with large tables, you should
+ increase this value.
</para>
</listitem>
@@ -5166,17 +5169,17 @@
</para>
<para>
-When you use a startup option to set a variable that takes a numeric value,
- the value can be given with a suffix of
- <literal>K</literal>, <literal>M</literal>, or
- <literal>G</literal> (either uppercase or lowercase) to indicate
- a multiplier of 1024, 1024<superscript>2</superscript> or
- 1024<superscript>3</superscript>. For example, when used to set
- <literal>key_buffer_size</literal>, the suffixes indicate
- units of kilobytes, megabytes, or gigabygtes.
- Thus,
- the following command starts the server with a key buffer size
- of 16 megabytes:
+ When you use a startup option to set a variable that takes a
+ numeric value, the value can be given with a suffix of
+ <literal>K</literal>, <literal>M</literal>, or
+ <literal>G</literal> (either uppercase or lowercase) to
+ indicate a multiplier of 1024,
+ 1024<superscript>2</superscript> or
+ 1024<superscript>3</superscript>. For example, when used to
+ set <literal>key_buffer_size</literal>, the suffixes indicate
+ units of kilobytes, megabytes, or gigabygtes. Thus, the
+ following command starts the server with a key buffer size of
+ 16 megabytes:
</para>
<programlisting>
@@ -6167,18 +6170,16 @@
</row>
<row>
<entry>1</entry>
- <entry>(Default) Enables concurrent insert for
-<literal>MyISAM</literal> tables that don't have
- holes</entry>
+ <entry>(Default) Enables concurrent insert for <literal>MyISAM</literal> tables
+ that don't have holes</entry>
</row>
<row>
<entry>2</entry>
- <entry>Enables concurrent inserts for all
-<literal>MyISAM</literal> tables. If table has a hole
- and is in use by another thread the new row will
- be inserted at end of table. If table is not in
- use then MySQL will do a normal read lock and
- insert the new row into the hole.</entry>
+ <entry>Enables concurrent inserts for all <literal>MyISAM</literal> tables. If
+ table has a hole and is in use by another thread
+ the new row will be inserted at end of table. If
+ table is not in use then MySQL will do a normal
+ read lock and insert the new row into the hole.</entry>
</row>
</tbody>
</tgroup>
@@ -7025,9 +7026,10 @@
</para>
<para>
- It is possible to create multiple <literal>MyISAM</literal> key caches. The
- size limit of 4GB applies to each cache individually, not
- as a group. See <xref linkend="myisam-key-cache"/>.
+ It is possible to create multiple
+ <literal>MyISAM</literal> key caches. The size limit of
+ 4GB applies to each cache individually, not as a group.
+ See <xref linkend="myisam-key-cache"/>.
</para>
</listitem>
@@ -11407,8 +11409,9 @@
<para>
Each storage engine performs any actions necessary for tables
- that it manages. For example, <literal>MyISAM</literal> flushes any pending index
- writes for a table. <literal>InnoDB</literal> flushes its buffer pool to disk
+ that it manages. For example, <literal>MyISAM</literal>
+ flushes any pending index writes for a table.
+ <literal>InnoDB</literal> flushes its buffer pool to disk
unless <literal>innodb_fast_shutdown</literal> is 2), writes
the current LSN to the tablespace, and terminates its own
internal threads.
Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.1/innodb.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -195,10 +195,10 @@
because of write operations having been reordered. If data
integrity is important to you, you should perform some
<quote>pull-the-plug</quote> tests before using anything in
- production. On Mac OS X 10.3 and later, <literal>InnoDB</literal> uses a special
- <literal>fcntl()</literal> file flush method. Under Linux, it is
- advisable to <emphasis role="bold">disable the write-back
- cache</emphasis>.
+ production. On Mac OS X 10.3 and later, <literal>InnoDB</literal>
+ uses a special <literal>fcntl()</literal> file flush method. Under
+ Linux, it is advisable to <emphasis role="bold">disable the
+ write-back cache</emphasis>.
</para>
<para>
@@ -877,10 +877,11 @@
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. If
- you set it to 2 (not available on Netware), <literal>InnoDB</literal> will just
- flush its logs and then shut down cold, as if MySQL had
- crashed; no committed transaction will be lost, but a crash
- recovery will be done at next startup.
+ you set it to 2 (not available on Netware),
+ <literal>InnoDB</literal> will just flush its logs and then
+ shut down cold, as if MySQL had crashed; no committed
+ transaction will be lost, but a crash recovery will be done at
+ next startup.
</para>
</listitem>
@@ -957,20 +958,21 @@
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
+ <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.
+ 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.
</para>
</listitem>
@@ -1025,8 +1027,9 @@
transaction may wait for a lock before being rolled back.
<literal>InnoDB</literal> automatically detects transaction
deadlocks in its own lock table and rolls back the
- transaction. <literal>InnoDB</literal> notices locks set using the <literal>LOCK
- TABLES</literal> statement. The default is 50 seconds.
+ transaction. <literal>InnoDB</literal> notices locks set using
+ the <literal>LOCK TABLES</literal> statement. The default is
+ 50 seconds.
</para>
<para>
@@ -1085,9 +1088,10 @@
you execute the same <literal>SELECT</literal> within the same
transaction, you see a new row in the result set returned by
the query. This also means, that if new items are added to the
- database, <literal>InnoDB</literal> does not guarantee serializability; however,
- conflict serializability is still guaranteed. Therefore, if
- this option is used <literal>InnoDB</literal> guarantees at most isolation level
+ database, <literal>InnoDB</literal> does not guarantee
+ serializability; however, conflict serializability is still
+ guaranteed. Therefore, if this option is used
+ <literal>InnoDB</literal> guarantees at most isolation level
<literal>READ COMMITTED</literal>.
</para>
@@ -1289,8 +1293,8 @@
</para>
<para>
- The <literal>InnoDB</literal> transaction system maintains a list of transactions
- that have delete-marked index records by
+ The <literal>InnoDB</literal> transaction system maintains a
+ list of transactions that have delete-marked index records by
<literal>UPDATE</literal> or <literal>DELETE</literal>
operations. Let the length of this list be
<replaceable>purge_lag</replaceable>. When
@@ -1398,13 +1402,13 @@
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 is 1, which
- means that <literal>LOCK TABLES</literal> causes <literal>InnoDB</literal> to
- lock a table internally. 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.
+ means that <literal>LOCK TABLES</literal> causes
+ <literal>InnoDB</literal> to lock a table internally. 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.
</para>
</listitem>
@@ -1541,9 +1545,10 @@
<para>
You can add the option <literal>innodb_file_per_table</literal> to
- <filename>my.cnf</filename>, and make <literal>InnoDB</literal> to store each table
- into its own <filename>.ibd</filename> file in a database
- directory of MySQL. See <xref linkend="multiple-tablespaces"/>.
+ <filename>my.cnf</filename>, and make <literal>InnoDB</literal> to
+ store each table into its own <filename>.ibd</filename> file in a
+ database directory of MySQL. See
+ <xref linkend="multiple-tablespaces"/>.
</para>
<section id="error-creating-innodb">
@@ -2048,12 +2053,12 @@
<listitem>
<para>
<literal>SET NULL</literal>: Delete or update the row from
- the parent table and set the foreign key column or columns in the
- child table to <literal>NULL</literal>. This is only valid
- if the foreign key columns do not have the <literal>NOT
- NULL</literal> qualifier specified. Both <literal>ON DELETE
- SET NULL</literal> and <literal>ON UPDATE SET NULL</literal>
- clauses are supported.
+ the parent table and set the foreign key column or columns
+ in the child table to <literal>NULL</literal>. This is only
+ valid if the foreign key columns do not have the
+ <literal>NOT NULL</literal> qualifier specified. Both
+ <literal>ON DELETE SET NULL</literal> and <literal>ON UPDATE
+ SET NULL</literal> clauses are supported.
</para>
</listitem>
@@ -2099,11 +2104,11 @@
<para>
<literal>InnoDB</literal> supports the same options when the
candidate key in the parent table is updated. With
- <literal>CASCADE</literal>, the foreign key column or columns in the
- child table are set to the new values of the candidate key in the
- parent table. In the same way, the updates cascade if updated
- columns in the child table reference foreign keys in another
- table.
+ <literal>CASCADE</literal>, the foreign key column or columns in
+ the child table are set to the new values of the candidate key
+ in the parent table. In the same way, the updates cascade if
+ updated columns in the child table reference foreign keys in
+ another table.
</para>
<para>
@@ -2193,10 +2198,10 @@
constraints row-by-row. According to the SQL standard, the
default behavior should be deferred checking, that is,
constraints are only checked after the <emphasis>entire SQL
- statement</emphasis> has been processed. Until <literal>InnoDB</literal> implements
- deferred constraint checking, some things will be impossible,
- such as deleting a record that refers to itself via a foreign
- key.
+ statement</emphasis> has been processed. Until
+ <literal>InnoDB</literal> implements deferred constraint
+ checking, some things will be impossible, such as deleting a
+ record that refers to itself via a foreign key.
</para>
<para>
@@ -4259,14 +4264,14 @@
<literal>innodb_table_locks=1</literal> and
<literal>AUTOCOMMIT=0</literal>, and the MySQL layer above
<literal>InnoDB</literal> knows about row-level locks.
- Otherwise, <literal>InnoDB</literal>'s automatic deadlock detection cannot
- detect deadlocks where such table locks are involved. Also,
- since the higher MySQL layer does not know about row-level
- locks, it is possible to get a table lock on a table where
- another user currently has row-level locks. However, this
- does not endager transaction integrity, as discussed in
- <xref linkend="innodb-deadlock-detection"/>. See also
- <xref linkend="innodb-restrictions"/>.
+ Otherwise, <literal>InnoDB</literal>'s automatic deadlock
+ detection cannot detect deadlocks where such table locks are
+ involved. Also, since the higher MySQL layer does not know
+ about row-level locks, it is possible to get a table lock on
+ a table where another user currently has row-level locks.
+ However, this does not endager transaction integrity, as
+ discussed in <xref linkend="innodb-deadlock-detection"/>.
+ See also <xref linkend="innodb-restrictions"/>.
</para>
</listitem>
@@ -4491,12 +4496,12 @@
<para>
If nothing else helps, serialize your transactions with
table-level locks. The correct way to use <literal>LOCK
- TABLES</literal> with transactional tables, like <literal>InnoDB</literal>, is
- to set <literal>AUTOCOMMIT = 0</literal> and not to call
- <literal>UNLOCK TABLES</literal> until you commit the
- transaction explicitly. For example, if you need to write to
- table <literal>t1</literal> and read from table
- <literal>t2</literal>, you can do this:
+ TABLES</literal> with transactional tables, like
+ <literal>InnoDB</literal>, is to set <literal>AUTOCOMMIT =
+ 0</literal> and not to call <literal>UNLOCK TABLES</literal>
+ until you commit the transaction explicitly. For example, if
+ you need to write to table <literal>t1</literal> and read
+ from table <literal>t2</literal>, you can do this:
</para>
<programlisting>
@@ -4530,8 +4535,8 @@
<listitem>
<para>
In applications using the <literal>LOCK TABLES</literal>
- command, MySQL does not set <literal>InnoDB</literal> table locks if
- <literal>AUTOCOMMIT=1</literal>.
+ command, MySQL does not set <literal>InnoDB</literal> table
+ locks if <literal>AUTOCOMMIT=1</literal>.
</para>
</listitem>
@@ -4617,8 +4622,8 @@
<para>
When using <literal>row_format=compact</literal> (the default
- <literal>InnoDB</literal> record format in MySQL &current-series;) and
- variable-length character sets, such as
+ <literal>InnoDB</literal> record format in MySQL
+ &current-series;) and variable-length character sets, such as
<literal>utf8</literal> or <literal>sjis</literal>,
<literal>CHAR(<replaceable>N</replaceable>)</literal> will
occupy a variable amount of space, at least
@@ -4642,15 +4647,16 @@
<listitem>
<para>
- When using the <literal>InnoDB</literal> storage engine on Solaris 10 for x86_64
- architecture (AMD Opteron), it is important to mount any
- filesystems used for storing <literal>InnoDB</literal>-related files using the
+ When using the <literal>InnoDB</literal> storage engine on
+ Solaris 10 for x86_64 architecture (AMD Opteron), it is
+ important to mount any filesystems used for storing
+ <literal>InnoDB</literal>-related files using the
<literal>forcedirectio</literal> option. (The default on
Solaris 10/x86_64 is <emphasis>not</emphasis> to use this
filesystem mounting option.) Failing to use
<literal>forcedirectio</literal> will cause a serious
- degradation of <literal>InnoDB</literal>'s speed and performance on this
- platform.
+ degradation of <literal>InnoDB</literal>'s speed and
+ performance on this platform.
</para>
<para>
@@ -5754,9 +5760,10 @@
<para>
A symptom of fragmentation is that a table takes more space than
it <quote>should</quote> take. How much that is exactly, is
- difficult to determine. All <literal>InnoDB</literal> data and indexes are stored
- in B-trees, and their fill factor may vary from 50% to 100%.
- Another symptom of fragmentation is that a table scan such as:
+ difficult to determine. All <literal>InnoDB</literal> data and
+ indexes are stored in B-trees, and their fill factor may vary
+ from 50% to 100%. Another symptom of fragmentation is that a
+ table scan such as:
</para>
<programlisting>
@@ -7001,9 +7008,9 @@
course of a transaction. Unfortunately, <literal>LOCK
TABLES</literal> in MySQL performs an implicit
<literal>COMMIT</literal> and <literal>UNLOCK
- TABLES</literal>. An <literal>InnoDB</literal> variant of <literal>LOCK
- TABLES</literal> has been planned that can be executed in the
- middle of a transaction.
+ TABLES</literal>. An <literal>InnoDB</literal> variant of
+ <literal>LOCK TABLES</literal> has been planned that can be
+ executed in the middle of a transaction.
</para>
</listitem>
Modified: trunk/refman-5.1/installing.xml
===================================================================
--- trunk/refman-5.1/installing.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.1/installing.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -13538,11 +13538,12 @@
<para>
When using Solaris 10 for x86_64, you should mount any
- filesystems on which you intend to store <literal>InnoDB</literal> files with the
+ filesystems on which you intend to store
+ <literal>InnoDB</literal> files with the
<literal>forcedirectio</literal> option. (By default mounting is
done without this option.) Failing to do so will cause a
- significant drop in performance when using the <literal>InnoDB</literal> storage
- engine on this platform.
+ significant drop in performance when using the
+ <literal>InnoDB</literal> storage engine on this platform.
</para>
<para>
@@ -15669,8 +15670,8 @@
<command>configure</command> command needs to build both a
static and a dynamic library in
<filename><replaceable>src_directory</replaceable>/bdb/build_unix/</filename>,
- but it does not with MySQL's own <literal>BDB</literal> version. The workaround
- is as follows.
+ but it does not with MySQL's own <literal>BDB</literal>
+ version. The workaround is as follows.
</para>
<orderedlist>
@@ -15987,8 +15988,8 @@
<command>configure</command> command needs to build both a
static and a dynamic library in
<filename><replaceable>src_directory</replaceable>/bdb/build_unix/</filename>,
- but it does not with MySQL's own <literal>BDB</literal> version. The workaround
- is as follows.
+ but it does not with MySQL's own <literal>BDB</literal>
+ version. The workaround is as follows.
</para>
<orderedlist>
Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.1/ndbcluster.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -1153,9 +1153,9 @@
CLuster storage engine in order to have them replicated in
the cluster. If you are importing tables from an existing
database using the output of <command>mysqldump</command>,
- you can open the SQL script or scripts in a text editor and add this
- option to any table creation statements, or replace any
- existing <literal>ENGINE</literal> (or
+ you can open the SQL script or scripts in a text editor and
+ add this option to any table creation statements, or replace
+ any existing <literal>ENGINE</literal> (or
<literal>TYPE</literal>) option with one of these. For
example, suppose that you have the sample
<literal>world</literal> database on another MySQL server
@@ -3107,11 +3107,10 @@
<para>
Records are kept for each transaction updating cluster
- data, both in the transaction coordinator and in the
- nodes where the actual updates are performed. These
- records contain state information needed in order to find
- UNDO records for rollback, lock queues, and other
- purposes.
+ data, both in the transaction coordinator and in the nodes
+ where the actual updates are performed. These records
+ contain state information needed in order to find UNDO
+ records for rollback, lock queues, and other purposes.
</para>
<para>
@@ -3474,9 +3473,9 @@
<para>
If the checkpointing is slow and there are so many writes
to the database that the log files are full and the log
- tail cannot be cut without jeopardizing recovery, then
- all updating transactions will be aborted with internal
- error code 410, or <literal>Out of log file space
+ tail cannot be cut without jeopardizing recovery, then all
+ updating transactions will be aborted with internal error
+ code 410, or <literal>Out of log file space
temporarily</literal>. This condition will prevail until a
checkpoint has completed and the log tail can be moved
forward.
@@ -4211,8 +4210,8 @@
<para>
Controls the number of index memory pages that can be
- written to disk during the local checkpoint phase of a node
- restart.
+ written to disk during the local checkpoint phase of a
+ node restart.
</para>
<para>
@@ -4741,9 +4740,9 @@
<para>
The speed at which queries are performed can vary by more
than 40% depending upon how this parameter is set. In
- future releases, MySQL Server will make educated
- guesses on how to set parameters relating to batch size,
- based on the query type.
+ future releases, MySQL Server will make educated guesses
+ on how to set parameters relating to batch size, based on
+ the query type.
</para>
<para>
@@ -8009,13 +8008,13 @@
<para>
<literal>NDB</literal> does not support repeatable reads,
- which can cause problems with the restoration process. Although
- the backup process is <quote>hot</quote>, restoring a MySQL
- Cluster from backup is not a 100% <quote>hot</quote> process.
- This is due to the fact that, for the duration of the restore
- process, running transactions get non-repeatable reads from
- the restored data. This means that the state of the data is
- inconsistent while the restore is in progress.
+ which can cause problems with the restoration process.
+ Although the backup process is <quote>hot</quote>, restoring a
+ MySQL Cluster from backup is not a 100% <quote>hot</quote>
+ process. This is due to the fact that, for the duration of the
+ restore process, running transactions get non-repeatable reads
+ from the restored data. This means that the state of the data
+ is inconsistent while the restore is in progress.
</para>
<remark role="todo">
@@ -10332,15 +10331,15 @@
<para>
In this section, we provide a listing of known limitations in
MySQL Cluster releases in the &current-series;.x series when
- compared to features available when using the <literal>MyISAM</literal> and <literal>InnoDB</literal>
- storage engines. Currently there are no plans to address these in
- coming releases of MySQL &current-series;; however, we will
- attempt to supply fixes for these issues in subsequent release
- series. If you check the <quote>Cluster</quote> category in the
- MySQL bugs database at <ulink url="http://bugs.mysql.com"/>, you
- can find known bugs which (if marked
- <quote>&current-series;</quote>) we intend to correct in upcoming
- releases of MySQL &current-series;.
+ compared to features available when using the
+ <literal>MyISAM</literal> and <literal>InnoDB</literal> storage
+ engines. Currently there are no plans to address these in coming
+ releases of MySQL &current-series;; however, we will attempt to
+ supply fixes for these issues in subsequent release series. If you
+ check the <quote>Cluster</quote> category in the MySQL bugs
+ database at <ulink url="http://bugs.mysql.com"/>, you can find
+ known bugs which (if marked <quote>&current-series;</quote>) we
+ intend to correct in upcoming releases of MySQL &current-series;.
</para>
<para>
@@ -11097,14 +11096,15 @@
slow transaction can cause the slave to lag behind the master.
This means that if the master fails, it is possible that the
slave might not have recorded the last few transactions. If a
- transaction-safe engine such as <literal>InnoDB</literal> is being used, then a
- transaction will either be complete on the slave or not
- applied at all, but replication does not guarantee that all
- data on the master and the slave will be consistent at all
- times. In MySQL Cluster, all data nodes are kept in synch, and
- a transaction committed by any one data node is committed for
- all data nodes. In the event of a data node failure, all
- remaining data nodes will remain in a consistent state.
+ transaction-safe engine such as <literal>InnoDB</literal> is
+ being used, then a transaction will either be complete on the
+ slave or not applied at all, but replication does not
+ guarantee that all data on the master and the slave will be
+ consistent at all times. In MySQL Cluster, all data nodes are
+ kept in synch, and a transaction committed by any one data
+ node is committed for all data nodes. In the event of a data
+ node failure, all remaining data nodes will remain in a
+ consistent state.
</para>
<para>
Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.1/optimization.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -6657,21 +6657,21 @@
<listitem>
<para>
In MySQL/InnoDB, <literal>InnoDB</literal> tables use a more
- compact storage format. In earlier versions of MySQL, <literal>InnoDB</literal>
- records contain some redundant information, such as the
- number of columns and the length of each column, even for
- fixed-size columns. By default, tables are created in the
- compact format (<literal>ROW_FORMAT=COMPACT</literal>). If
- you wish to downgrade to older versions of MySQL/InnoDB, you
- can request the old format with
- <literal>ROW_FORMAT=REDUNDANT</literal>.
+ compact storage format. In earlier versions of MySQL,
+ <literal>InnoDB</literal> records contain some redundant
+ information, such as the number of columns and the length of
+ each column, even for fixed-size columns. By default, tables
+ are created in the compact format
+ (<literal>ROW_FORMAT=COMPACT</literal>). If you wish to
+ downgrade to older versions of MySQL/InnoDB, you can request
+ the old format with <literal>ROW_FORMAT=REDUNDANT</literal>.
</para>
<para>
- The compact <literal>InnoDB</literal> format also changes the way how
- <literal>CHAR</literal> columns containing UTF-8 data are
- stored. In the <literal>ROW_FORMAT=REDUNDANT</literal>
- format, a UTF-8
+ The compact <literal>InnoDB</literal> format also changes
+ the way how <literal>CHAR</literal> columns containing UTF-8
+ data are stored. In the
+ <literal>ROW_FORMAT=REDUNDANT</literal> format, a UTF-8
<literal>CHAR(<replaceable>n</replaceable>)</literal>
occupies 3*<replaceable>n</replaceable> bytes, given that
the maximum length of a UTF-8 encoded character is 3 bytes.
@@ -9904,8 +9904,8 @@
<para>
Symlinking can be accomplished manually from the command
line using <literal>ln -s</literal> if
- <command>mysqld</command> is not running. Alternatively, you
- can instruct a running MySQL server to perform the
+ <command>mysqld</command> is not running. Alternatively,
+ you can instruct a running MySQL server to perform the
symlinking by using the <literal>DATA DIRECTORY</literal>
and <literal>INDEX DIRECTORY</literal> options to
<literal>CREATE TABLE</literal>. See
Modified: trunk/refman-5.1/pluggable-storage.xml
===================================================================
--- trunk/refman-5.1/pluggable-storage.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.1/pluggable-storage.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -270,8 +270,9 @@
<listitem>
<para>
<literal>BDB</literal> - an alternative transaction engine to
- <literal>InnoDB</literal> that supports <literal>COMMIT</literal>, <literal>ROLLBACK</literal>, and other transactional
- features.
+ <literal>InnoDB</literal> that supports
+ <literal>COMMIT</literal>, <literal>ROLLBACK</literal>, and
+ other transactional features.
</para>
</listitem>
@@ -287,9 +288,8 @@
<para>
<literal>Merge</literal> - allows a MySQL DBA or developer to
logically group together a series of identical
-<literal>MyISAM</literal> tables
- and reference them as one object. Good for VLDB environments
- like data warehousing.
+ <literal>MyISAM</literal> tables and reference them as one
+ object. Good for VLDB environments like data warehousing.
</para>
</listitem>
Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.1/replication.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -71,11 +71,11 @@
<xref linkend="ndbcluster"/>.) The master server writes updates to
its binary log files, and maintains an index of the files to keep
track of log rotation. These logs serve as records of updates to
- be sent to any slave servers. When a slave connects to the
- master, it informs the master of the position up to which the
- slave read in the logs at the last successful update. The slave
- receives any updates that have taken place since that time, and
- then blocks and waits for the master to notify it of new updates.
+ be sent to any slave servers. When a slave connects to the master,
+ it informs the master of the position up to which the slave read
+ in the logs at the last successful update. The slave receives any
+ updates that have taken place since that time, and then blocks and
+ waits for the master to notify it of new updates.
</para>
<para>
@@ -207,11 +207,11 @@
Due to these limitations, we recommend that at this point you use
<literal>LOAD DATA FROM MASTER</literal> only if the dataset on
the master is relatively small, or if a prolonged read lock on the
- master is acceptable. Although the actual speed of <literal>LOAD DATA
- FROM MASTER</literal> may vary from system to system, a good rule
- of thumb for how long it takes is 1 second per 1MB of data. This
- is a rough estimate, but you should find it fairly accurate if
- both master and slave are equivalent to 700MHz Pentium CPUs in
+ master is acceptable. Although the actual speed of <literal>LOAD
+ DATA FROM MASTER</literal> may vary from system to system, a good
+ rule of thumb for how long it takes is 1 second per 1MB of data.
+ This is a rough estimate, but you should find it fairly accurate
+ if both master and slave are equivalent to 700MHz Pentium CPUs in
performance and are connected through a 100Mbps network.
</para>
@@ -1956,8 +1956,8 @@
<literal>slave_transaction_retries</literal>: If the
replication slave SQL thread fails to execute a transaction
because of an <literal>InnoDB</literal> deadlock or exceeded
- <literal>InnoDB</literal>'s <literal>innodb_lock_wait_timeout</literal> or
- NDBCluster's
+ <literal>InnoDB</literal>'s
+ <literal>innodb_lock_wait_timeout</literal> or NDBCluster's
<literal>TransactionDeadlockDetectionTimeout</literal> or
<literal>TransactionInactiveTimeout</literal>, it
automatically retries
@@ -4354,9 +4354,10 @@
<listitem>
<para>
- For <literal>InnoDB</literal>: An <literal>INSERT</literal> statement that uses
- <literal>auto_increment</literal> will block other
- non-conflicting <literal>INSERT</literal> statements.
+ For <literal>InnoDB</literal>: An <literal>INSERT</literal>
+ statement that uses <literal>auto_increment</literal> will
+ block other non-conflicting <literal>INSERT</literal>
+ statements.
</para>
</listitem>
Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.1/sql-syntax.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -14642,9 +14642,10 @@
checks for secondary indexes in <literal>InnoDB</literal>
tables are performed. If set to <literal>0</literal>,
uniqueness checks are not done for index entries inserted
- into <literal>InnoDB</literal>'s insert buffer. If you know for certain that
- your data does not contain uniqueness violations, you can
- set this to 0 to speed up large table imports to <literal>InnoDB</literal>.
+ into <literal>InnoDB</literal>'s insert buffer. If you know
+ for certain that your data does not contain uniqueness
+ violations, you can set this to 0 to speed up large table
+ imports to <literal>InnoDB</literal>.
</para>
</listitem>
Modified: trunk/refman-5.1/storage-engines.xml
===================================================================
--- trunk/refman-5.1/storage-engines.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-5.1/storage-engines.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -2629,8 +2629,9 @@
</para>
<para>
- Turn off system buffering of <literal>BDB</literal> database files to avoid
- double caching. This option was added in MySQL 5.1.4.
+ Turn off system buffering of <literal>BDB</literal> database
+ files to avoid double caching. This option was added in
+ MySQL 5.1.4.
</para>
</listitem>
@@ -2667,8 +2668,9 @@
</para>
<para>
- Turn off system buffering of <literal>BDB</literal> log files to avoid double
- caching. This option was added in MySQL 5.1.4.
+ Turn off system buffering of <literal>BDB</literal> log
+ files to avoid double caching. This option was added in
+ MySQL 5.1.4.
</para>
</listitem>
Modified: trunk/refman-common/news-4.0.xml
===================================================================
--- trunk/refman-common/news-4.0.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-common/news-4.0.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -940,8 +940,9 @@
InnoDB if one runs <literal>INSERT ... SELECT ...</literal>
(binlog not enabled), or a multi-table
<literal>UPDATE</literal> or <literal>DELETE</literal>, and
- only the read tables are InnoDB type, the rest are <literal>MyISAM</literal>;
- this also fixes bug #7879 for InnoDB type tables. (Bug #7879)
+ only the read tables are InnoDB type, the rest are
+ <literal>MyISAM</literal>; this also fixes bug #7879 for
+ InnoDB type tables. (Bug #7879)
</para>
</listitem>
@@ -1502,10 +1503,10 @@
<listitem>
<para>
- Fixed that if a write to a <literal>MyISAM</literal> table fails because of a
- full disk or an exceeded disk quota, it prints a message to
- the error log every 10 minutes, and waits until disk becomes
- free. (Bug #3248)
+ Fixed that if a write to a <literal>MyISAM</literal> table
+ fails because of a full disk or an exceeded disk quota, it
+ prints a message to the error log every 10 minutes, and waits
+ until disk becomes free. (Bug #3248)
</para>
</listitem>
@@ -4941,8 +4942,8 @@
On a slave, <literal>LOAD DATA INFILE</literal> which had no
<literal>IGNORE</literal> or <literal>REPLACE</literal> clause
on the master, was replicated with <literal>IGNORE</literal>.
- Although this is not a problem if the master and slave data are
- identical (a <literal>LOAD</literal> that produces no
+ Although this is not a problem if the master and slave data
+ are identical (a <literal>LOAD</literal> that produces no
duplicate conflicts on the master produces none on the slave
anyway), which is true in normal operation, it is better for
debugging not to silently add the <literal>IGNORE</literal>.
Modified: trunk/refman-common/news-4.1.xml
===================================================================
--- trunk/refman-common/news-4.1.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-common/news-4.1.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -4585,9 +4585,9 @@
<para>
<literal>InnoDB</literal>: If one used <literal>LOCK
TABLES</literal>, created an InnoDB temp table, and did a
- multi-table update where a <literal>MyISAM</literal> table was the update table
- and the temp table was a read table, then InnoDB asserted in
- <filename>row0sel.c</filename> because
+ multi-table update where a <literal>MyISAM</literal> table was
+ the update table and the temp table was a read table, then
+ InnoDB asserted in <filename>row0sel.c</filename> because
<literal>n_mysql_tables_in_use</literal> was 0. Also, we
remove the assertion altogether and just print an error to the
<filename>.err</filename> log if this important consistency
@@ -5483,8 +5483,8 @@
InnoDB if one runs <literal>INSERT ... SELECT ...</literal>
(binlog not enabled), or a multi-table
<literal>UPDATE</literal> or <literal>DELETE</literal>, and
- only the read tables are InnoDB type, the rest are <literal>MyISAM</literal>.
- (Bug #7879)
+ only the read tables are InnoDB type, the rest are
+ <literal>MyISAM</literal>. (Bug #7879)
</para>
</listitem>
@@ -5959,9 +5959,10 @@
<para>
Added <option>--order-by-primary</option> to
<command>mysqldump</command>, to sort each table's data in a
- dump file. This may be useful when dumping a <literal>MyISAM</literal> table
- which will be loaded into an InnoDB table. Dumping a <literal>MyISAM</literal>
- table with this option is considerably slower than without.
+ dump file. This may be useful when dumping a
+ <literal>MyISAM</literal> table which will be loaded into an
+ InnoDB table. Dumping a <literal>MyISAM</literal> table with
+ this option is considerably slower than without.
</para>
</listitem>
Modified: trunk/refman-common/news-5.0.xml
===================================================================
--- trunk/refman-common/news-5.0.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-common/news-5.0.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -7352,8 +7352,9 @@
<listitem>
<para>
The variable <literal>concurrent_insert</literal> now takes 3
- values. Setting this to 2 changes <literal>MyISAM</literal> to do concurrent
- inserts to end of table if table is in use by another thread.
+ values. Setting this to 2 changes <literal>MyISAM</literal> to
+ do concurrent inserts to end of table if table is in use by
+ another thread.
</para>
</listitem>
@@ -8153,8 +8154,7 @@
<para>
The server died with signal 11 if a non-existent location was
specified for the location of the binary log. Now the server
- exits after printing an appropriate error message. (Bug
- #9542)
+ exits after printing an appropriate error message. (Bug #9542)
</para>
</listitem>
@@ -10870,10 +10870,10 @@
<listitem>
<para>
- Fixed that if a write to a <literal>MyISAM</literal> table fails because of a
- full disk or an exceeded disk quota, it prints a message to
- the error log every 10 minutes, and waits until disk becomes
- free. (Bug #3248)
+ Fixed that if a write to a <literal>MyISAM</literal> table
+ fails because of a full disk or an exceeded disk quota, it
+ prints a message to the error log every 10 minutes, and waits
+ until disk becomes free. (Bug #3248)
</para>
</listitem>
Modified: trunk/refman-common/news-5.1.xml
===================================================================
--- trunk/refman-common/news-5.1.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-common/news-5.1.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -472,15 +472,15 @@
<emphasis role="bold">Plugin API</emphasis>: MySQL 5.1 adds
support for a very flexible plugin API that enables loading
and unloading of various components at runtime, without
- restarting the server. Although the work on this is not finished
- yet, <emphasis>plugin full-text parsers</emphasis> are a first
- step in this direction. This allows users to implement their
- own input filter on the indexed text, enabling full-text
- search capability on arbitrary data such as PDF files or other
- document formats. A pre-parser full-text plugin performs the
- actual parsing and extraction of the text and hands it over to
- the built-in MySQL full-text search. (Author: Sergey
- Vojtovich)
+ restarting the server. Although the work on this is not
+ finished yet, <emphasis>plugin full-text parsers</emphasis>
+ are a first step in this direction. This allows users to
+ implement their own input filter on the indexed text, enabling
+ full-text search capability on arbitrary data such as PDF
+ files or other document formats. A pre-parser full-text plugin
+ performs the actual parsing and extraction of the text and
+ hands it over to the built-in MySQL full-text search. (Author:
+ Sergey Vojtovich)
</para>
<para>
Modified: trunk/refman-common/news-innodb.xml
===================================================================
--- trunk/refman-common/news-innodb.xml 2006-01-08 01:30:40 UTC (rev 719)
+++ trunk/refman-common/news-innodb.xml 2006-01-08 01:33:03 UTC (rev 720)
@@ -920,10 +920,10 @@
table is referenced by a <literal>FOREIGN KEY</literal>. The
MySQL manual states that <literal>REPLACE</literal> must
resolve a duplicate-key error semantically with
- <literal>DELETE</literal> + <literal>INSERT</literal>, and
- not by an <literal>UPDATE</literal>. In versions &lt; 4.0.18
- and &lt; 4.1.2, MySQL could resolve a duplicate key conflict
- in <literal>REPLACE</literal> by doing an
+ <literal>DELETE</literal> + <literal>INSERT</literal>, and not
+ by an <literal>UPDATE</literal>. In versions &lt; 4.0.18 and
+ &lt; 4.1.2, MySQL could resolve a duplicate key conflict in
+ <literal>REPLACE</literal> by doing an
<literal>UPDATE</literal> on the existing row, and
<literal>FOREIGN KEY</literal> checks could behave in a
semantically wrong way. (Bug #2418)

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.