Author: paul
Date: 2006-01-08 02:30:12 +0100 (Sun, 08 Jan 2006)
New Revision: 718
Log:
r5950@frost: paul | 2006-01-07 19:24:22 -0600
Add tags.
Modified:
trunk/
trunk/refman-4.1/connector-j.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/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/connector-j.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/connector-j.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
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5949
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5950
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
Modified: trunk/refman-4.1/connector-j.xml
===================================================================
--- trunk/refman-4.1/connector-j.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/connector-j.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -2742,7 +2742,7 @@
<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 InnoDB) is when the
+ in some other storage engine such as <literal>InnoDB</literal>) is when the
statement completes.
</para>
Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/database-administration.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -9470,7 +9470,7 @@
<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. InnoDB flushes its buffer pool to disk,
+ 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:29:03 UTC (rev 717)
+++ trunk/refman-4.1/innodb.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -270,7 +270,7 @@
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, InnoDB uses a special
+ 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>.
@@ -975,14 +975,14 @@
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,
- InnoDB's crash recovery is not affected and thus crash
+ <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 InnoDB database. Using 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
@@ -1056,7 +1056,7 @@
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, InnoDB
+ 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
@@ -1115,9 +1115,9 @@
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,
- InnoDB does not guarantee serializability instead conflict
+ <literal>InnoDB</literal> does not guarantee serializability instead conflict
serializability is still guaranteed. Therefore, if this option
- is used InnoDB guarantees at most isolation level
+ 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>
@@ -1249,7 +1249,7 @@
</para>
<para>
- The InnoDB transaction system maintains a list of transactions
+ 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
@@ -1350,9 +1350,9 @@
<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 InnoDB internally to take a table
+ TABLES</literal> causes also <literal>InnoDB</literal> internally to take a table
lock. In applications using <literal>AUTOCOMMIT=1</literal>,
- InnoDB's internal table locks can cause deadlocks. You can set
+ <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,7 +1501,7 @@
<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 InnoDB to store each table
+ <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>
@@ -1520,7 +1520,7 @@
<listitem>
<para>
You did not create the <literal>InnoDB</literal> data file
- directory or the InnoDB log directory.
+ directory or the <literal>InnoDB</literal> log directory.
</para>
</listitem>
@@ -2160,13 +2160,13 @@
<para>
<emphasis role="bold">Deviation from SQL standards</emphasis>:
Like MySQL in general, in an SQL statement that inserts,
- deletes, or updates many rows, InnoDB checks
+ deletes, or updates many rows, <literal>InnoDB</literal> checks
<literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
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 role="bold">whole SQL statement</emphasis> has been
- processed. Until InnoDB implements deferred constraint checking,
+ 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>
@@ -2569,7 +2569,7 @@
Using multiple tablespaces can be beneficial to users who want
to move specific tables to separate physical disks or who wish
to restore backups of single tables quickly without interrupting
- the use of the remaining InnoDB tables.
+ the use of the remaining <literal>InnoDB</literal> tables.
</para>
<para>
@@ -4572,7 +4572,7 @@
<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 InnoDB, is
+ 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
@@ -4611,12 +4611,12 @@
<listitem>
<para>
In applications using <literal>AUTOCOMMIT=1</literal> and
- MySQL's <literal>LOCK TABLES</literal> command, InnoDB's
+ 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 InnoDB table
+ and remove the problem. 4.0.24 does not set <literal>InnoDB</literal> table
locks if <literal>AUTOCOMMIT=1</literal>.
</para>
</listitem>
@@ -4722,14 +4722,14 @@
<para>
(Verified using MySQL 4.1, assumed for other MySQL versions,
given that this is a platform architecture issue.) When using
- the InnoDB storage engine on Solaris 10 for x86_64
+ 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 InnoDB-related files using the
+ 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 InnoDB's speed and performance on this
+ degradation of <literal>InnoDB</literal>'s speed and performance on this
platform.
</para>
@@ -5844,7 +5844,7 @@
<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 InnoDB data and indexes are stored
+ 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>
@@ -7121,7 +7121,7 @@
course of a transaction. Unfortunately, <literal>LOCK
TABLES</literal> in MySQL performs an implicit
<literal>COMMIT</literal> and <literal>UNLOCK
- TABLES</literal>. An InnoDB variant of <literal>LOCK
+ 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>
@@ -7316,7 +7316,7 @@
<para>
Older MySQL versions did not allow accessing any table with a
name containing ‘<literal>#</literal>’. The solution
- in older MySQL versions is to use a special InnoDB mechanism
+ 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
Modified: trunk/refman-4.1/installing.xml
===================================================================
--- trunk/refman-4.1/installing.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/installing.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -12877,7 +12877,7 @@
<para>
A new startup option named
<option>innodb_table_locks</option> was added that causes
- <literal>LOCK TABLE</literal> to also acquire InnoDB table
+ <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
@@ -12892,7 +12892,7 @@
<para>
A new startup option named
<option>innodb_table_locks</option> was added that causes
- <literal>LOCK TABLE</literal> to also acquire InnoDB table
+ <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
@@ -15056,7 +15056,7 @@
<para>
When using Solaris 10 for x86_64, you should mount any
- filesystems on which you intend to store InnoDB 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,7 +17192,7 @@
<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 BDB version. The workaround
+ but it does not with MySQL's own <literal>BDB</literal> version. The workaround
is as follows.
</para>
@@ -17515,7 +17515,7 @@
<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 BDB version. The workaround
+ but it does not with MySQL's own <literal>BDB</literal> version. The workaround
is as follows.
</para>
Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/ndbcluster.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -8739,7 +8739,7 @@
<para>
In this section, we provide a listing of known limitations in
MySQL Cluster releases in the ¤t-series;.x series when
- compared to features available when using the <literal>MyISAM</literal> and InnoDB
+ 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 ¤t-series;; however, we will
attempt to supply fixes for these issues in subsequent release
@@ -9240,7 +9240,7 @@
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 InnoDB is being used, then 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
Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/replication.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -1070,7 +1070,7 @@
<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
- InnoDB will resolve this at startup, and consequently deliver
+ <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
@@ -1835,7 +1835,7 @@
<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
- InnoDB's <literal>innodb_lock_wait_timeout</literal> or
+ <literal>InnoDB</literal>'s <literal>innodb_lock_wait_timeout</literal> or
NDBCluster's
<literal>TransactionDeadlockDetectionTimeout</literal> or
<literal>TransactionInactiveTimeout</literal>, it
Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/sql-syntax.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -12884,9 +12884,9 @@
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 InnoDB's insert buffer. If you know for certain that
+ 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 InnoDB.
+ 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>
@@ -15166,7 +15166,7 @@
The row storage format (<literal>Fixed</literal>,
<literal>Dynamic</literal>, <literal>Compressed</literal>,
<literal>Redundant</literal>, <literal>Compact</literal>).
- InnoDB tables are always in the
+ <literal>InnoDB</literal> tables are always in the
<literal>Redundant</literal> format.
</para>
</listitem>
Modified: trunk/refman-4.1/tutorial.xml
===================================================================
--- trunk/refman-4.1/tutorial.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/tutorial.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -3400,7 +3400,7 @@
<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 InnoDB tables. We should
+ 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?
Modified: trunk/refman-5.0/apis.xml
===================================================================
--- trunk/refman-5.0/apis.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/apis.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -359,8 +359,8 @@
<listitem>
<para>
- We have to change InnoDB not to be so verbose when using the
- embedded version. If your database does not contain InnoDB
+ 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
Modified: trunk/refman-5.0/connector-j.xml
===================================================================
--- trunk/refman-5.0/connector-j.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/connector-j.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -2742,7 +2742,7 @@
<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 InnoDB) is when the
+ in some other storage engine such as <literal>InnoDB</literal>) is when the
statement completes.
</para>
Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/database-administration.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -350,11 +350,11 @@
</para>
<para>
- This option enables support for the InnoDB storage engine.
- MySQL-Max servers always include InnoDB support. From MySQL
- 4.0 onward, InnoDB is included by default in all binary
+ 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 InnoDB support.
+ to obtain <literal>InnoDB</literal> support.
</para>
</listitem>
@@ -419,8 +419,8 @@
</para>
<para>
- MySQL-Max servers include the BerkeleyDB (BDB) storage engine
- whenever possible, but not all platforms support BDB.
+ 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>
@@ -434,7 +434,7 @@
<para>
The following table shows on which platforms MySQL-Max binaries
- include support for BDB and NDB Cluster:
+ include support for <literal>BDB</literal> and NDB Cluster:
</para>
<informaltable>
@@ -2408,7 +2408,7 @@
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
- InnoDB with large tables, you should increase this value.
+ <literal>InnoDB</literal> with large tables, you should increase this value.
</para>
</listitem>
@@ -8400,7 +8400,7 @@
<para>
If a replication slave SQL thread fails to execute a
transaction because of an <literal>InnoDB</literal>
- deadlock or exceeded InnoDB's
+ deadlock or exceeded <literal>InnoDB</literal>'s
<literal>innodb_lock_wait_timeout</literal> or
NDBCluster's
<literal>TransactionDeadlockDetectionTimeout</literal> or
@@ -11431,7 +11431,7 @@
<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. InnoDB flushes its buffer pool to disk
+ 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:29:03 UTC (rev 717)
+++ trunk/refman-5.0/innodb.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -195,7 +195,7 @@
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, InnoDB uses a special
+ 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>.
@@ -881,7 +881,7 @@
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), InnoDB will just flush its logs and then shut
+ 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.
@@ -961,14 +961,14 @@
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,
- InnoDB's crash recovery is not affected and thus crash
+ <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 InnoDB database. Using 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
@@ -1029,7 +1029,7 @@
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. InnoDB notices locks set using the <literal>LOCK
+ transaction. <literal>InnoDB</literal> notices locks set using the <literal>LOCK
TABLES</literal> statement. The default is 50 seconds.
</para>
@@ -1092,9 +1092,9 @@
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, InnoDB does not guarantee serializability; however,
+ database, <literal>InnoDB</literal> does not guarantee serializability; however,
conflict serializability is still guaranteed. Therefore, if
- this option is used InnoDB guarantees at most isolation level
+ this option is used <literal>InnoDB</literal> guarantees at most isolation level
<literal>READ COMMITTED</literal>.
</para>
@@ -1297,7 +1297,7 @@
</para>
<para>
- The InnoDB transaction system maintains a list of transactions
+ 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
@@ -1421,9 +1421,9 @@
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 InnoDB to
+ means that <literal>LOCK TABLES</literal> causes <literal>InnoDB</literal> to
lock a table internally. In applications using
- <literal>AUTOCOMMIT=1</literal>, InnoDB's internal table locks
+ <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
@@ -1565,7 +1565,7 @@
<para>
You can add the option <literal>innodb_file_per_table</literal> to
- <filename>my.cnf</filename>, and make InnoDB to store each table
+ <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>
@@ -1584,7 +1584,7 @@
<listitem>
<para>
You did not create the <literal>InnoDB</literal> data file
- directory or the InnoDB log directory.
+ directory or the <literal>InnoDB</literal> log directory.
</para>
</listitem>
@@ -2213,12 +2213,12 @@
<para>
<emphasis role="bold">Deviation from SQL standards</emphasis>:
Like MySQL in general, in an SQL statement that inserts,
- deletes, or updates many rows, InnoDB checks
+ deletes, or updates many rows, <literal>InnoDB</literal> checks
<literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
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 InnoDB implements
+ 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.
@@ -2569,7 +2569,7 @@
Using multiple tablespaces can be beneficial to users who want
to move specific tables to separate physical disks or who wish
to restore backups of single tables quickly without interrupting
- the use of the remaining InnoDB tables.
+ the use of the remaining <literal>InnoDB</literal> tables.
</para>
<para>
@@ -4531,7 +4531,7 @@
<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 InnoDB, is
+ 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
@@ -4570,7 +4570,7 @@
<listitem>
<para>
In applications using the <literal>LOCK TABLES</literal>
- command, MySQL does not set InnoDB table locks if
+ command, MySQL does not set <literal>InnoDB</literal> table locks if
<literal>AUTOCOMMIT=1</literal>.
</para>
</listitem>
@@ -4657,7 +4657,7 @@
<para>
When using <literal>row_format=compact</literal> (the default
- InnoDB record format in MySQL ¤t-series;) and
+ <literal>InnoDB</literal> record format in MySQL ¤t-series;) and
variable-length character sets, such as
<literal>utf8</literal> or <literal>sjis</literal>,
<literal>CHAR(<replaceable>N</replaceable>)</literal> will
@@ -4682,14 +4682,14 @@
<listitem>
<para>
- When using the InnoDB storage engine on Solaris 10 for x86_64
+ 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 InnoDB-related files using the
+ 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 InnoDB's speed and performance on this
+ degradation of <literal>InnoDB</literal>'s speed and performance on this
platform.
</para>
@@ -5794,7 +5794,7 @@
<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 InnoDB data and indexes are stored
+ 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>
@@ -7063,7 +7063,7 @@
course of a transaction. Unfortunately, <literal>LOCK
TABLES</literal> in MySQL performs an implicit
<literal>COMMIT</literal> and <literal>UNLOCK
- TABLES</literal>. An InnoDB variant of <literal>LOCK
+ 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>
@@ -7168,7 +7168,7 @@
<filename>.frm</filename> files around, or if the server crashes
in the middle of a data dictionary operation, the
<filename>.frm</filename> files may end up out of sync with
- InnoDB's internal data dictionary.
+ <literal>InnoDB</literal>'s internal data dictionary.
</para>
<para>
Modified: trunk/refman-5.0/installing.xml
===================================================================
--- trunk/refman-5.0/installing.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/installing.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -12560,7 +12560,7 @@
<para>
A new startup option named
<option>innodb_table_locks</option> was added that causes
- <literal>LOCK TABLE</literal> to also acquire InnoDB table
+ <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
@@ -12575,7 +12575,7 @@
<para>
A new startup option named
<option>innodb_table_locks</option> was added that causes
- <literal>LOCK TABLE</literal> to also acquire InnoDB table
+ <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
@@ -14226,10 +14226,10 @@
<para>
When using Solaris 10 for x86_64, you should mount any
- filesystems on which you intend to store InnoDB 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 InnoDB storage
+ significant drop in performance when using the <literal>InnoDB</literal> storage
engine on this platform.
</para>
@@ -16357,7 +16357,7 @@
<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 BDB version. The workaround
+ but it does not with MySQL's own <literal>BDB</literal> version. The workaround
is as follows.
</para>
@@ -16675,7 +16675,7 @@
<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 BDB version. The workaround
+ but it does not with MySQL's own <literal>BDB</literal> version. The workaround
is as follows.
</para>
Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/ndbcluster.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -8720,7 +8720,7 @@
<para>
In this section, we provide a listing of known limitations in
MySQL Cluster releases in the ¤t-series;.x series when
- compared to features available when using the <literal>MyISAM</literal> and InnoDB
+ 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 ¤t-series;; however, we will
attempt to supply fixes for these issues in subsequent release
@@ -9517,7 +9517,7 @@
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 InnoDB is being used, then 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
Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/optimization.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -6688,7 +6688,7 @@
<para>
Starting with MySQL/InnoDB 5.0.3, <literal>InnoDB</literal>
tables use a more compact storage format. In earlier
- versions of MySQL, InnoDB records contain some redundant
+ 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
@@ -6698,7 +6698,7 @@
</para>
<para>
- The compact InnoDB format also changes the way how
+ 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
Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/replication.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -1756,7 +1756,7 @@
<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
- InnoDB's <literal>innodb_lock_wait_timeout</literal> or
+ <literal>InnoDB</literal>'s <literal>innodb_lock_wait_timeout</literal> or
NDBCluster's
<literal>TransactionDeadlockDetectionTimeout</literal> or
<literal>TransactionInactiveTimeout</literal>, it
Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/sql-syntax.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -14164,9 +14164,9 @@
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 InnoDB's insert buffer. If you know for certain that
+ 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 InnoDB.
+ set this to 0 to speed up large table imports to <literal>InnoDB</literal>.
</para>
</listitem>
@@ -16500,7 +16500,7 @@
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, InnoDB tables
+ <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:29:03 UTC (rev 717)
+++ trunk/refman-5.1/apis.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -359,8 +359,8 @@
<listitem>
<para>
- We have to change InnoDB not to be so verbose when using the
- embedded version. If your database does not contain InnoDB
+ 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
Modified: trunk/refman-5.1/connector-j.xml
===================================================================
--- trunk/refman-5.1/connector-j.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/connector-j.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -2742,7 +2742,7 @@
<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 InnoDB) is when the
+ in some other storage engine such as <literal>InnoDB</literal>) is when the
statement completes.
</para>
Modified: trunk/refman-5.1/custom-engine.xml
===================================================================
--- trunk/refman-5.1/custom-engine.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/custom-engine.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -7169,7 +7169,7 @@
</para>
<para>
- gets foreign key create string from InnoDB
+ gets foreign key create string from <literal>InnoDB</literal>
</para>
<bridgehead>Parameters</bridgehead>
@@ -8729,7 +8729,7 @@
<para>
The methods ha_retrieve_all_cols and ha_retrieve_all_pk are made
- virtual to handle InnoDB specifics. If InnoDB doesn't need the
+ virtual to handle <literal>InnoDB</literal> specifics. If <literal>InnoDB</literal> doesn't need the
extra parameters HA_EXTRA_RETRIEVE_ALL_COLS and
HA_EXTRA_RETRIEVE_PRIMARY_KEY anymore then these methods need
not be virtual anymore.
@@ -10671,7 +10671,7 @@
<bridgehead>Purpose</bridgehead>
<para>
- prepare InnoDB for HANDLER
+ prepare <literal>InnoDB</literal> for <literal>HANDLER</literal>
</para>
<bridgehead>Synopsis</bridgehead>
@@ -12342,7 +12342,7 @@
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 BDB, 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>
@@ -12658,7 +12658,7 @@
</para>
<para>
- This is never called for InnoDB or BDB tables, as these table
+ This is never called for <literal>InnoDB</literal> or <literal>BDB</literal> tables, as these table
types has the HA_NOT_EXACT_COUNT set.
</para>
Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/database-administration.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -350,11 +350,11 @@
</para>
<para>
- This option enables support for the InnoDB storage engine.
- MySQL-Max servers always include InnoDB support. From MySQL
- 4.0 onward, InnoDB is included by default in all binary
+ 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 InnoDB support.
+ to obtain <literal>InnoDB</literal> support.
</para>
</listitem>
@@ -419,8 +419,8 @@
</para>
<para>
- MySQL-Max servers include the BerkeleyDB (BDB) storage engine
- whenever possible, but not all platforms support BDB.
+ 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>
@@ -434,7 +434,7 @@
<para>
The following table shows on which platforms MySQL-Max binaries
- include support for BDB and NDB Cluster:
+ include support for <literal>BDB</literal> and NDB Cluster:
</para>
<informaltable>
@@ -2392,7 +2392,7 @@
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
- InnoDB with large tables, you should increase this value.
+ <literal>InnoDB</literal> with large tables, you should increase this value.
</para>
</listitem>
@@ -8371,7 +8371,7 @@
<para>
If a replication slave SQL thread fails to execute a
transaction because of an <literal>InnoDB</literal>
- deadlock or exceeded InnoDB's
+ deadlock or exceeded <literal>InnoDB</literal>'s
<literal>innodb_lock_wait_timeout</literal> or
NDBCluster's
<literal>TransactionDeadlockDetectionTimeout</literal> or
@@ -11408,7 +11408,7 @@
<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. InnoDB flushes its buffer pool to disk
+ 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:29:03 UTC (rev 717)
+++ trunk/refman-5.1/innodb.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -195,7 +195,7 @@
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, InnoDB uses a special
+ 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>.
@@ -877,7 +877,7 @@
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), InnoDB will just
+ 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.
@@ -957,14 +957,14 @@
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,
- InnoDB's crash recovery is not affected and thus crash
+ <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 InnoDB database. Using 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
@@ -1025,7 +1025,7 @@
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. InnoDB notices locks set using the <literal>LOCK
+ transaction. <literal>InnoDB</literal> notices locks set using the <literal>LOCK
TABLES</literal> statement. The default is 50 seconds.
</para>
@@ -1085,9 +1085,9 @@
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, InnoDB does not guarantee serializability; however,
+ database, <literal>InnoDB</literal> does not guarantee serializability; however,
conflict serializability is still guaranteed. Therefore, if
- this option is used InnoDB guarantees at most isolation level
+ this option is used <literal>InnoDB</literal> guarantees at most isolation level
<literal>READ COMMITTED</literal>.
</para>
@@ -1289,7 +1289,7 @@
</para>
<para>
- The InnoDB transaction system maintains a list of transactions
+ 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
@@ -1398,9 +1398,9 @@
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 InnoDB to
+ means that <literal>LOCK TABLES</literal> causes <literal>InnoDB</literal> to
lock a table internally. In applications using
- <literal>AUTOCOMMIT=1</literal>, InnoDB's internal table locks
+ <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
@@ -1541,7 +1541,7 @@
<para>
You can add the option <literal>innodb_file_per_table</literal> to
- <filename>my.cnf</filename>, and make InnoDB to store each table
+ <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>
@@ -1560,7 +1560,7 @@
<listitem>
<para>
You did not create the <literal>InnoDB</literal> data file
- directory or the InnoDB log directory.
+ directory or the <literal>InnoDB</literal> log directory.
</para>
</listitem>
@@ -2188,12 +2188,12 @@
<para>
<emphasis role="bold">Deviation from SQL standards</emphasis>:
Like MySQL in general, in an SQL statement that inserts,
- deletes, or updates many rows, InnoDB checks
+ deletes, or updates many rows, <literal>InnoDB</literal> checks
<literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
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 InnoDB implements
+ 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.
@@ -2544,7 +2544,7 @@
Using multiple tablespaces can be beneficial to users who want
to move specific tables to separate physical disks or who wish
to restore backups of single tables quickly without interrupting
- the use of the remaining InnoDB tables.
+ the use of the remaining <literal>InnoDB</literal> tables.
</para>
<para>
@@ -4259,7 +4259,7 @@
<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, InnoDB's automatic deadlock detection cannot
+ 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
@@ -4491,7 +4491,7 @@
<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 InnoDB, is
+ 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
@@ -4530,7 +4530,7 @@
<listitem>
<para>
In applications using the <literal>LOCK TABLES</literal>
- command, MySQL does not set InnoDB table locks if
+ command, MySQL does not set <literal>InnoDB</literal> table locks if
<literal>AUTOCOMMIT=1</literal>.
</para>
</listitem>
@@ -4617,7 +4617,7 @@
<para>
When using <literal>row_format=compact</literal> (the default
- InnoDB record format in MySQL ¤t-series;) and
+ <literal>InnoDB</literal> record format in MySQL ¤t-series;) and
variable-length character sets, such as
<literal>utf8</literal> or <literal>sjis</literal>,
<literal>CHAR(<replaceable>N</replaceable>)</literal> will
@@ -4642,14 +4642,14 @@
<listitem>
<para>
- When using the InnoDB storage engine on Solaris 10 for x86_64
+ 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 InnoDB-related files using the
+ 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 InnoDB's speed and performance on this
+ degradation of <literal>InnoDB</literal>'s speed and performance on this
platform.
</para>
@@ -5754,7 +5754,7 @@
<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 InnoDB data and indexes are stored
+ 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>
@@ -7001,7 +7001,7 @@
course of a transaction. Unfortunately, <literal>LOCK
TABLES</literal> in MySQL performs an implicit
<literal>COMMIT</literal> and <literal>UNLOCK
- TABLES</literal>. An InnoDB variant of <literal>LOCK
+ 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>
@@ -7106,7 +7106,7 @@
<filename>.frm</filename> files around, or if the server crashes
in the middle of a data dictionary operation, the
<filename>.frm</filename> files may end up out of sync with
- InnoDB's internal data dictionary.
+ <literal>InnoDB</literal>'s internal data dictionary.
</para>
<para>
Modified: trunk/refman-5.1/installing.xml
===================================================================
--- trunk/refman-5.1/installing.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/installing.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -13538,10 +13538,10 @@
<para>
When using Solaris 10 for x86_64, you should mount any
- filesystems on which you intend to store InnoDB 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 InnoDB storage
+ significant drop in performance when using the <literal>InnoDB</literal> storage
engine on this platform.
</para>
@@ -15669,7 +15669,7 @@
<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 BDB version. The workaround
+ but it does not with MySQL's own <literal>BDB</literal> version. The workaround
is as follows.
</para>
@@ -15987,7 +15987,7 @@
<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 BDB version. The workaround
+ but it does not with MySQL's own <literal>BDB</literal> version. The workaround
is as follows.
</para>
Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/ndbcluster.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -10332,7 +10332,7 @@
<para>
In this section, we provide a listing of known limitations in
MySQL Cluster releases in the ¤t-series;.x series when
- compared to features available when using the <literal>MyISAM</literal> and InnoDB
+ 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 ¤t-series;; however, we will
attempt to supply fixes for these issues in subsequent release
@@ -11097,7 +11097,7 @@
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 InnoDB is being used, then 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
Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/optimization.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -6657,7 +6657,7 @@
<listitem>
<para>
In MySQL/InnoDB, <literal>InnoDB</literal> tables use a more
- compact storage format. In earlier versions of MySQL, InnoDB
+ 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
@@ -6668,7 +6668,7 @@
</para>
<para>
- The compact InnoDB format also changes the way how
+ 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
Modified: trunk/refman-5.1/pluggable-storage.xml
===================================================================
--- trunk/refman-5.1/pluggable-storage.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/pluggable-storage.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -270,7 +270,7 @@
<listitem>
<para>
<literal>BDB</literal> - an alternative transaction engine to
- InnoDB that supports COMMIT, ROLLBACK, and other transactional
+ <literal>InnoDB</literal> that supports <literal>COMMIT</literal>, <literal>ROLLBACK</literal>, and other transactional
features.
</para>
</listitem>
Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/replication.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -1956,7 +1956,7 @@
<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
- InnoDB's <literal>innodb_lock_wait_timeout</literal> or
+ <literal>InnoDB</literal>'s <literal>innodb_lock_wait_timeout</literal> or
NDBCluster's
<literal>TransactionDeadlockDetectionTimeout</literal> or
<literal>TransactionInactiveTimeout</literal>, it
@@ -4354,7 +4354,7 @@
<listitem>
<para>
- For InnoDB: An <literal>INSERT</literal> statement that uses
+ 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>
Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml 2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/sql-syntax.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -14642,9 +14642,9 @@
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 InnoDB's insert buffer. If you know for certain that
+ 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 InnoDB.
+ 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:29:03 UTC (rev 717)
+++ trunk/refman-5.1/storage-engines.xml 2006-01-08 01:30:12 UTC (rev 718)
@@ -2629,7 +2629,7 @@
</para>
<para>
- Turn off system buffering of BDB database files to avoid
+ 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,7 +2667,7 @@
</para>
<para>
- Turn off system buffering of BDB log files to avoid double
+ 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>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r718 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 8 Jan |
