Author: paul
Date: 2006-01-13 04:50:08 +0100 (Fri, 13 Jan 2006)
New Revision: 795
Log:
r6148@frost: paul | 2006-01-12 21:32:36 -0600
General revisions.
Modified:
trunk/
trunk/refman-4.1/storage-engines.xml
trunk/refman-5.0/renamed-nodes.txt
trunk/refman-5.0/storage-engines.xml
trunk/refman-5.1/renamed-nodes.txt
trunk/refman-5.1/storage-engines.xml
trunk/refman-common/titles.en.ent
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6147
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2101
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6148
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2101
Modified: trunk/refman-4.1/storage-engines.xml
===================================================================
--- trunk/refman-4.1/storage-engines.xml 2006-01-13 03:49:54 UTC (rev 794)
+++ trunk/refman-4.1/storage-engines.xml 2006-01-13 03:50:08 UTC (rev 795)
@@ -2884,17 +2884,18 @@
</para>
<para>
- You can start a transaction with the <literal>BEGIN
- WORK</literal> statement to suspend autocommit, or with
- <literal>SET AUTOCOMMIT=0</literal> to disable autocommit
- explicitly.
+ You can start a transaction with the <literal>START
+ TRANSACTION</literal> or <literal>BEGIN</literal> statement
+ to suspend autocommit, or with <literal>SET
+ AUTOCOMMIT=0</literal> to disable autocommit explicitly.
</para>
</listitem>
</itemizedlist>
<para>
- See <xref linkend="commit"/>.
+ For more information about transactions, see
+ <xref linkend="commit"/>.
</para>
<para>
@@ -2914,25 +2915,24 @@
<listitem>
<para>
- MySQL requires a <literal>PRIMARY KEY</literal> in each
- <literal>BDB</literal> table so that each row can be
- uniquely identified. If you don't create one explicitly,
- MySQL creates and maintains a hidden <literal>PRIMARY
- KEY</literal> for you. The hidden key has a length of five
- bytes and is incremented for each insert attempt. This key
- does not appear in the output of <literal>SHOW CREATE
- TABLE</literal> or <literal>DESCRIBE</literal>.
+ MySQL requires a primary key in each <literal>BDB</literal>
+ table so that each row can be uniquely identified. If you
+ don't create one explicitly by declaring a <literal>PRIMARY
+ KEY</literal>, MySQL creates and maintains a hidden primary
+ key for you. The hidden key has a length of five bytes and
+ is incremented for each insert attempt. This key does not
+ appear in the output of <literal>SHOW CREATE TABLE</literal>
+ or <literal>DESCRIBE</literal>.
</para>
</listitem>
<listitem>
<para>
- The <literal>PRIMARY KEY</literal> is faster than any other
- index, because the <literal>PRIMARY KEY</literal> is stored
- together with the row data. The other indexes are stored as
- the key data + the <literal>PRIMARY KEY</literal>, so it's
- important to keep the <literal>PRIMARY KEY</literal> as
- short as possible to save disk space and get better speed.
+ The primary key is faster than any other index, because it
+ is stored together with the row data. The other indexes are
+ stored as the key data plus the primary key, so it's
+ important to keep the primary key as short as possible to
+ save disk space and get better speed.
</para>
<para>
@@ -2945,20 +2945,20 @@
<listitem>
<para>
- If all columns you access in a <literal>BDB</literal> table
- are part of the same index or part of the primary key, MySQL
- can execute the query without having to access the actual
- row. In a <literal>MyISAM</literal> table, this can be done
- only if the columns are part of the same index.
+ If all columns that you access in a <literal>BDB</literal>
+ table are part of the same index or part of the primary key,
+ MySQL can execute the query without having to access the
+ actual row. In a <literal>MyISAM</literal> table, this can
+ be done only if the columns are part of the same index.
</para>
</listitem>
<listitem>
<para>
- Sequential scanning is slower than for
- <literal>MyISAM</literal> tables because the data in
- <literal>BDB</literal> tables is stored in B-trees and not
- in a separate data file.
+ Sequential scanning is slower for <literal>BDB</literal>
+ tables than for <literal>MyISAM</literal> tables because the
+ data in <literal>BDB</literal> tables is stored in B-trees
+ and not in a separate data file.
</para>
</listitem>
@@ -3164,9 +3164,9 @@
<listitem>
<para>
- Each <literal>BDB</literal> table stores in the
+ Each <literal>BDB</literal> table stores in its
<filename>.db</filename> file the path to the file as it was
- created. This was done enable detection of locks in a
+ created. This is done to enable detection of locks in a
multi-user environment that supports symlinks. As a
consequence of this, it is not possible to move
<literal>BDB</literal> table files from one database
@@ -3186,7 +3186,9 @@
files and requires them to be present when
<command>mysqld</command> starts. The <literal>BDB</literal>
logs are the files in the data directory with names of the
- form <filename>log.XXXXXXXXXX</filename> (ten digits).
+ form
+ <filename>log.<replaceable>NNNNNNNNNN</replaceable></filename>
+ (ten digits).
</para>
</listitem>
@@ -3194,7 +3196,9 @@
<para>
If a column that allows <literal>NULL</literal> values has a
unique index, only a single <literal>NULL</literal> value is
- allowed. This differs from other storage engines.
+ allowed. This differs from other storage engines, which
+ allow multiple <literal>NULL</literal> values in unique
+ indexes.
</para>
</listitem>
@@ -3212,23 +3216,24 @@
<para>
If the following error occurs when you start
<command>mysqld</command> after upgrading, it means that the
- new <literal>BDB</literal> version doesn't support the old
- log file format:
+ current version of <literal>BDB</literal> doesn't support
+ the old log file format:
</para>
<programlisting>
-bdb: Ignoring log file: .../log.XXXXXXXXXX:
+bdb: Ignoring log file: .../log.<replaceable>NNNNNNNNNN</replaceable>:
unsupported log version #
</programlisting>
<para>
In this case, you must delete all <literal>BDB</literal>
- logs from your data directory (the files with names that
- have the format <filename>log.XXXXXXXXXX</filename>) and
- restart <command>mysqld</command>. We also recommend that
- you then use <command>mysqldump --opt</command> to dump your
- <literal>BDB</literal> tables, drop the tables, and restore
- them from the dump file.
+ logs from your data directory (the files that have names of
+ the form
+ <filename>log.<replaceable>NNNNNNNNNN</replaceable></filename>)
+ and restart <command>mysqld</command>. We also recommend
+ that you then use <command>mysqldump --opt</command> to dump
+ your <literal>BDB</literal> tables, drop the tables, and
+ restore them from the dump file.
</para>
</listitem>
@@ -3247,10 +3252,10 @@
</programlisting>
<para>
- This is not fatal, but until the problem is fixed, we
- recommend that you not drop <literal>BDB</literal> tables
- except while autocommit mode is enabled. (The fix is not
- trivial.)
+ This is not fatal, but the fix is not trivial. Until the
+ problem is fixed, we recommend that you not drop
+ <literal>BDB</literal> tables except while autocommit mode
+ is enabled.
</para>
</listitem>
@@ -3303,7 +3308,8 @@
creates a table definition file in the database directory. The
file begins with the table name and has an
<filename>.frm</filename> extension. No other files are created.
- No data can be stored into the table or retrieved from it.
+ No data can be stored into the table. Retrievals return an empty
+ result.
</para>
<programlisting>
@@ -3381,17 +3387,18 @@
<filename>.frm</filename> extension. The storage engine creates
other files, all having names beginning with the table name. The
data and metadata files have extensions of
- <filename>.ARZ</filename> and <filename>.ARM</filename>. A
- <filename>.ARN</filename> file may appear during optimization
- operations.
+ <filename>.ARZ</filename> and <filename>.ARM</filename>,
+ respectively. An <filename>.ARN</filename> file may appear during
+ optimization operations.
</para>
<para>
- The <literal>ARCHIVE</literal> engine supports only
- <literal>INSERT</literal> and <literal>SELECT</literal> (no
- deletes, replaces, or updates). It does support <literal>ORDER
- BY</literal> operations, <literal>BLOB</literal> fields, and
- basically all data types except geometry data types (see
+ The <literal>ARCHIVE</literal> engine supports
+ <literal>INSERT</literal> and <literal>SELECT</literal>, but not
+ <literal>DELETE</literal>, <literal>REPLACE</literal>, or
+ <literal>UPDATE</literal>. It does support <literal>ORDER
+ BY</literal> operations, <literal>BLOB</literal> columns, and
+ basically all but spatial data types (see
<xref linkend="mysql-spatial-datatypes"/>). The
<literal>ARCHIVE</literal> engine uses row-level locking.
</para>
@@ -3399,30 +3406,31 @@
<para>
<emphasis role="bold">Storage:</emphasis> Rows are compressed as
they are inserted. The <literal>ARCHIVE</literal> engine uses
- <ulink url="http://www.zlib.net/">zlib</ulink> lossless data
- compression. Use of <literal>OPTIMIZE TABLE</literal> can analyze
- the table and pack it into a smaller format (for a reason to use
- <literal>OPTIMIZE TABLE</literal>, see below). There are several
- types of insertions that are used:
+ <literal>zlib</literal> lossless data compression (see
+ <ulink url="http://www.zlib.net/"/>). You can use
+ <literal>OPTIMIZE TABLE</literal> to analyze the table and pack it
+ into a smaller format (for a reason to use <literal>OPTIMIZE
+ TABLE</literal>, see later in this section).
+ There are several types of insertions that are used:
</para>
<itemizedlist>
<listitem>
<para>
- A straight <literal>INSERT</literal> just pushes rows into a
- compression buffer, and that buffer flushes as it needs. The
+ An <literal>INSERT</literal> statement just pushes rows into a
+ compression buffer, and that buffer flushes as necessary. The
insertion into the buffer is protected by a lock. A
<literal>SELECT</literal> forces a flush to occur, unless the
only insertions that have come in were <literal>INSERT
- DELAYED</literal> (those flush as need be). See
+ DELAYED</literal> (those flush as necessary). See
<xref linkend="insert-delayed"/>.
</para>
</listitem>
<listitem>
<para>
- A bulk insert is only visible after it completes, unless other
+ A bulk insert is visible only after it completes, unless other
inserts occur at the same time, in which case it can be seen
partially. A <literal>SELECT</literal> never causes a flush of
a bulk insert unless a normal insert occurs while it is
@@ -3441,12 +3449,12 @@
<literal>SELECT</literal> is performed as a consistent read. Note
that lots of <literal>SELECT</literal> statements during insertion
can deteriorate the compression, unless only bulk or delayed
- inserts are used. To fix any compression issues that have occurred
- you can always do an <literal>OPTIMIZE TABLE</literal>
- (<literal>REPAIR TABLE</literal> also is supported). The number of
- rows in <literal>ARCHIVE</literal> tables reported by
- <literal>SHOW TABLE STATUS</literal> is always accurate. See
- <xref linkend="repair-table"/>, <xref linkend="optimize-table"/>,
+ inserts are used. To achieve better compression, you can use
+ <literal>OPTIMIZE TABLE</literal> or <literal>REPAIR
+ TABLE</literal>. The number of rows in <literal>ARCHIVE</literal>
+ tables reported by <literal>SHOW TABLE STATUS</literal> is always
+ accurate. See <xref linkend="optimize-table"/>,
+ <xref linkend="repair-table"/>, and
<xref linkend="show-table-status"/>.
</para>
@@ -3507,7 +3515,7 @@
begins with the table name and has a <filename>.CSV</filename>
extension. The data file is a plain text file. When you store data
into the table, the storage engine saves it into the data file in
- CSV format.
+ comma-separated values format.
</para>
<programlisting>
@@ -3567,7 +3575,7 @@
The <literal>BLACKHOLE</literal> storage engine was added in MySQL
4.1.11. This engine acts as a <quote>black hole</quote> that
accepts data but throws it away and does not store it. Retrievals
- always return the empty set:
+ always return an empty result:
</para>
<programlisting>
@@ -3605,20 +3613,19 @@
<para>
The <literal>BLACKHOLE</literal> storage engine supports all kinds
- of indexing.
+ of indexes. That is, you can include index declarations in the
+ table definition.
</para>
<para>
- To enable this storage engine, use the
- <option>--with-blackhole-storage-engine</option> option to
- <command>configure</command> when you build MySQL. The
- <literal>BLACKHOLE</literal> storage engine is available in
- MySQL-supplied server binaries beginning with MySQL 4.1.12; you
- can determine whether or not your version supports this engine by
- viewing the output of <literal>SHOW ENGINES</literal> or
- <literal>SHOW VARIABLES LIKE 'have%'</literal>.
+ You can check whether the <literal>BLACKHOLE</literal> storage
+ engine is available with this statement:
</para>
+<programlisting>
+mysql> <userinput>SHOW VARIABLES LIKE 'have_blackhole_engine';</userinput>
+</programlisting>
+
<para>
Inserts into a <literal>BLACKHOLE</literal> table do not store any
data, but if the binary log is enabled, the SQL statements are
@@ -3643,9 +3650,9 @@
<para>
The master writes to its binary log. The <quote>dummy</quote>
- <literal>mysqld</literal> process acts as a slave, applying the
- desired combination of <literal>replicate-do</literal> and
- <literal>replicate-ignore</literal> rules, and writes a new,
+ <command>mysqld</command> process acts as a slave, applying the
+ desired combination of <literal>replicate-do-*</literal> and
+ <literal>replicate-ignore-*</literal> rules, and writes a new,
filtered binary log of its own. (See
<xref linkend="replication-options"/>.) This filtered log is
provided to the slave.
@@ -3654,7 +3661,7 @@
<para>
The dummy process does not actually store any data, so there is
little processing overhead incurred by running the additional
- <literal>mysqld</literal> process on the replication master host.
+ <command>mysqld</command> process on the replication master host.
This type of setup can be repeated with additional replication
slaves.
</para>
@@ -3668,7 +3675,7 @@
<listitem>
<para>
- Verification of dumpfile syntax.
+ Verification of dump file syntax.
</para>
</listitem>
Modified: trunk/refman-5.0/renamed-nodes.txt
===================================================================
--- trunk/refman-5.0/renamed-nodes.txt 2006-01-13 03:49:54 UTC (rev 794)
+++ trunk/refman-5.0/renamed-nodes.txt 2006-01-13 03:50:08 UTC (rev 795)
@@ -392,3 +392,4 @@
client-side-scripts client-utility-programs
mysqlcc client-utility-programs
innodb-start innodb-parameters
+federated-install federated-storage-engine
Modified: trunk/refman-5.0/storage-engines.xml
===================================================================
--- trunk/refman-5.0/storage-engines.xml 2006-01-13 03:49:54 UTC (rev 794)
+++ trunk/refman-5.0/storage-engines.xml 2006-01-13 03:50:08 UTC (rev 795)
@@ -2864,17 +2864,18 @@
</para>
<para>
- You can start a transaction with the <literal>BEGIN
- WORK</literal> statement to suspend autocommit, or with
- <literal>SET AUTOCOMMIT=0</literal> to disable autocommit
- explicitly.
+ You can start a transaction with the <literal>START
+ TRANSACTION</literal> or <literal>BEGIN</literal> statement
+ to suspend autocommit, or with <literal>SET
+ AUTOCOMMIT=0</literal> to disable autocommit explicitly.
</para>
</listitem>
</itemizedlist>
<para>
- See <xref linkend="commit"/>.
+ For more information about transactions, see
+ <xref linkend="commit"/>.
</para>
<para>
@@ -2894,25 +2895,24 @@
<listitem>
<para>
- MySQL requires a <literal>PRIMARY KEY</literal> in each
- <literal>BDB</literal> table so that each row can be
- uniquely identified. If you don't create one explicitly,
- MySQL creates and maintains a hidden <literal>PRIMARY
- KEY</literal> for you. The hidden key has a length of five
- bytes and is incremented for each insert attempt. This key
- does not appear in the output of <literal>SHOW CREATE
- TABLE</literal> or <literal>DESCRIBE</literal>.
+ MySQL requires a primary key in each <literal>BDB</literal>
+ table so that each row can be uniquely identified. If you
+ don't create one explicitly by declaring a <literal>PRIMARY
+ KEY</literal>, MySQL creates and maintains a hidden primary
+ key for you. The hidden key has a length of five bytes and
+ is incremented for each insert attempt. This key does not
+ appear in the output of <literal>SHOW CREATE TABLE</literal>
+ or <literal>DESCRIBE</literal>.
</para>
</listitem>
<listitem>
<para>
- The <literal>PRIMARY KEY</literal> is faster than any other
- index, because the <literal>PRIMARY KEY</literal> is stored
- together with the row data. The other indexes are stored as
- the key data + the <literal>PRIMARY KEY</literal>, so it's
- important to keep the <literal>PRIMARY KEY</literal> as
- short as possible to save disk space and get better speed.
+ The primary key is faster than any other index, because it
+ is stored together with the row data. The other indexes are
+ stored as the key data plus the primary key, so it's
+ important to keep the primary key as short as possible to
+ save disk space and get better speed.
</para>
<para>
@@ -2925,20 +2925,20 @@
<listitem>
<para>
- If all columns you access in a <literal>BDB</literal> table
- are part of the same index or part of the primary key, MySQL
- can execute the query without having to access the actual
- row. In a <literal>MyISAM</literal> table, this can be done
- only if the columns are part of the same index.
+ If all columns that you access in a <literal>BDB</literal>
+ table are part of the same index or part of the primary key,
+ MySQL can execute the query without having to access the
+ actual row. In a <literal>MyISAM</literal> table, this can
+ be done only if the columns are part of the same index.
</para>
</listitem>
<listitem>
<para>
- Sequential scanning is slower than for
- <literal>MyISAM</literal> tables because the data in
- <literal>BDB</literal> tables is stored in B-trees and not
- in a separate data file.
+ Sequential scanning is slower for <literal>BDB</literal>
+ tables than for <literal>MyISAM</literal> tables because the
+ data in <literal>BDB</literal> tables is stored in B-trees
+ and not in a separate data file.
</para>
</listitem>
@@ -3144,9 +3144,9 @@
<listitem>
<para>
- Each <literal>BDB</literal> table stores in the
+ Each <literal>BDB</literal> table stores in its
<filename>.db</filename> file the path to the file as it was
- created. This was done enable detection of locks in a
+ created. This is done to enable detection of locks in a
multi-user environment that supports symlinks. As a
consequence of this, it is not possible to move
<literal>BDB</literal> table files from one database
@@ -3166,7 +3166,9 @@
files and requires them to be present when
<command>mysqld</command> starts. The <literal>BDB</literal>
logs are the files in the data directory with names of the
- form <filename>log.XXXXXXXXXX</filename> (ten digits).
+ form
+ <filename>log.<replaceable>NNNNNNNNNN</replaceable></filename>
+ (ten digits).
</para>
</listitem>
@@ -3174,7 +3176,9 @@
<para>
If a column that allows <literal>NULL</literal> values has a
unique index, only a single <literal>NULL</literal> value is
- allowed. This differs from other storage engines.
+ allowed. This differs from other storage engines, which
+ allow multiple <literal>NULL</literal> values in unique
+ indexes.
</para>
</listitem>
@@ -3192,23 +3196,24 @@
<para>
If the following error occurs when you start
<command>mysqld</command> after upgrading, it means that the
- new <literal>BDB</literal> version doesn't support the old
- log file format:
+ current version of <literal>BDB</literal> doesn't support
+ the old log file format:
</para>
<programlisting>
-bdb: Ignoring log file: .../log.XXXXXXXXXX:
+bdb: Ignoring log file: .../log.<replaceable>NNNNNNNNNN</replaceable>:
unsupported log version #
</programlisting>
<para>
In this case, you must delete all <literal>BDB</literal>
- logs from your data directory (the files with names that
- have the format <filename>log.XXXXXXXXXX</filename>) and
- restart <command>mysqld</command>. We also recommend that
- you then use <command>mysqldump --opt</command> to dump your
- <literal>BDB</literal> tables, drop the tables, and restore
- them from the dump file.
+ logs from your data directory (the files that have names of
+ the form
+ <filename>log.<replaceable>NNNNNNNNNN</replaceable></filename>)
+ and restart <command>mysqld</command>. We also recommend
+ that you then use <command>mysqldump --opt</command> to dump
+ your <literal>BDB</literal> tables, drop the tables, and
+ restore them from the dump file.
</para>
</listitem>
@@ -3227,10 +3232,10 @@
</programlisting>
<para>
- This is not fatal, but until the problem is fixed, we
- recommend that you not drop <literal>BDB</literal> tables
- except while autocommit mode is enabled. (The fix is not
- trivial.)
+ This is not fatal, but the fix is not trivial. Until the
+ problem is fixed, we recommend that you not drop
+ <literal>BDB</literal> tables except while autocommit mode
+ is enabled.
</para>
</listitem>
@@ -3283,7 +3288,8 @@
creates a table definition file in the database directory. The
file begins with the table name and has an
<filename>.frm</filename> extension. No other files are created.
- No data can be stored into the table or retrieved from it.
+ No data can be stored into the table. Retrievals return an empty
+ result.
</para>
<programlisting>
@@ -3356,18 +3362,6 @@
</itemizedlist>
- <section id="federated-install">
-
- <title>&title-federated-install;</title>
-
- <para>
- To enable this storage engine, use the
- <option>--with-federated-storage-engine</option> option to
- <command>configure</command> when you build MySQL.
- </para>
-
- </section>
-
<section id="federated-description">
<title>&title-federated-description;</title>
@@ -3377,8 +3371,8 @@
creates a table definition file in the database directory. The
file begins with the table name and has an
<filename>.frm</filename> extension. No other files are created,
- because the actual data is in a remote database. This differs
- from the way that storage engines for local tables work.
+ because the actual data is in a remote table. This differs from
+ the way that storage engines for local tables work.
</para>
<para>
@@ -3398,20 +3392,20 @@
With the MySQL <literal>FEDERATED</literal> storage engine,
there are no local data files for a table (for example, there is
no <filename>.MYD</filename> file). Instead, a remote database
- stores the data that normally would be in the table. This
- necessitates the use of the MySQL client API to read, delete,
- update, and insert data. Data retrieval is initiated via a
- <literal>SELECT * FROM
+ stores the data that normally would be in the table. The local
+ server connects to a remote server, and uses the MySQL client
+ API to read, delete, update, and insert data in the remote
+ table. Data retrieval is initiated via a <literal>SELECT * FROM
<replaceable>tbl_name</replaceable></literal> SQL statement. To
read the result, rows are fetched one at a time by using the
<literal>mysql_fetch_row()</literal> C API function, and then
- converted from the columns in the <literal>SELECT</literal>
- result set to the format that the <literal>FEDERATED</literal>
- handler expects.
+ converting the columns in the <literal>SELECT</literal> result
+ set to the format that the <literal>FEDERATED</literal> handler
+ expects.
</para>
<para>
- The basic flow is as follows:
+ The flow of information is as follows:
</para>
<orderedlist>
@@ -3470,36 +3464,35 @@
<para>
The procedure for using <literal>FEDERATED</literal> tables is
very simple. Normally, you have two servers running, either both
- on the same host or on different hosts. (It is also possible for
- a <literal>FEDERATED</literal> table to use another table that
- is managed by the same server, though there is little point in
+ on the same host or on different hosts. (It is possible for a
+ <literal>FEDERATED</literal> table to use another table that is
+ managed by the same server, though there is little point in
doing so.)
</para>
<para>
First, you must have a table on the remote server that you want
- to access with the <literal>FEDERATED</literal> table. Suppose
+ to access by using a <literal>FEDERATED</literal> table. Suppose
that the remote table is in the <literal>federated</literal>
database and is defined like this:
</para>
<programlisting>
CREATE TABLE test_table (
- id int(20) NOT NULL auto_increment,
- name varchar(32) NOT NULL default '',
- other int(20) NOT NULL default '0',
+ id INT(20) NOT NULL AUTO_INCREMENT,
+ name VARCHAR(32) NOT NULL DEFAULT '',
+ other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id),
- KEY name (name),
- KEY other_key (other)
+ INDEX name (name),
+ INDEX other_key (other)
)
ENGINE=MyISAM
DEFAULT CHARSET=latin1;
</programlisting>
<para>
- The <literal>ENGINE</literal> table option could name any
- storage engine; the table need not be a
- <literal>MyISAM</literal> table.
+ The example uses a <literal>MyISAM</literal> table, but the
+ table could use any storage engine.
</para>
<para>
@@ -3509,12 +3502,12 @@
<programlisting>
CREATE TABLE federated_table (
- id int(20) NOT NULL auto_increment,
- name varchar(32) NOT NULL default '',
- other int(20) NOT NULL default '0',
+ id INT(20) NOT NULL AUTO_INCREMENT,
+ name VARCHAR(32) NOT NULL DEFAULT '',
+ other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id),
- KEY name (name),
- KEY other_key (other)
+ INDEX name (name),
+ INDEX other_key (other)
)
ENGINE=FEDERATED
DEFAULT CHARSET=latin1
@@ -3545,9 +3538,10 @@
The remote host information indicates the remote server to which
your local server connects, and the database and table
information indicates which remote table to use as the data
- file. In this example, the remote server is indicated to be
- running as <literal>remote_host</literal> on port 9306, so you
- want to start that server so that it listens to port 9306.
+ source. In this example, the remote server is indicated to be
+ running as <literal>remote_host</literal> on port 9306, so there
+ must be a MySQL server running on the remote host and listening
+ to port 9306.
</para>
<para>
@@ -3561,8 +3555,8 @@
<para>
Only <literal>mysql</literal> is supported as the
- <replaceable>scheme</replaceable> at this point; the password
- and port number are optional.
+ <replaceable>scheme</replaceable> value at this point; the
+ password and port number are optional.
</para>
<para>
@@ -3578,13 +3572,14 @@
<para>
The use of <literal>CONNECTION</literal> for specifying the
connection string is non-optimal and is likely to change in
- future. Keep this in mind when you use
- <literal>FEDERATED</literal> tables, because it means that
- modifications are likely to be required when that happens.
+ future. Keep this in mind for applications that use
+ <literal>FEDERATED</literal> tables. Such applications are
+ likely to need modification if the format for specifying
+ connection information changes.
</para>
<para>
- Because any password used is stored in the connection string as
+ Because any password given in the connection string is stored as
plain text, it can be seen by any user who can use <literal>SHOW
CREATE TABLE</literal> or <literal>SHOW TABLE STATUS</literal>
for the <literal>FEDERATED</literal> table, or query the
@@ -3592,10 +3587,6 @@
<literal>INFORMATION_SCHEMA</literal> database.
</para>
- <para>
- <emphasis role="bold">Additional resources</emphasis>
- </para>
-
</section>
<section id="federated-limitations">
@@ -3603,8 +3594,9 @@
<title>&title-federated-limitations;</title>
<para>
- What the <literal>FEDERATED</literal> storage engine does and
- does not support:
+ The following items indicate features that the
+ <literal>FEDERATED</literal> storage engine does and does not
+ support:
</para>
<itemizedlist>
@@ -3751,17 +3743,18 @@
<filename>.frm</filename> extension. The storage engine creates
other files, all having names beginning with the table name. The
data and metadata files have extensions of
- <filename>.ARZ</filename> and <filename>.ARM</filename>. A
- <filename>.ARN</filename> file may appear during optimization
- operations.
+ <filename>.ARZ</filename> and <filename>.ARM</filename>,
+ respectively. An <filename>.ARN</filename> file may appear during
+ optimization operations.
</para>
<para>
- The <literal>ARCHIVE</literal> engine supports only
- <literal>INSERT</literal> and <literal>SELECT</literal> (no
- deletes, replaces, or updates). It does support <literal>ORDER
- BY</literal> operations, <literal>BLOB</literal> fields, and
- basically all data types except geometry data types (see
+ The <literal>ARCHIVE</literal> engine supports
+ <literal>INSERT</literal> and <literal>SELECT</literal>, but not
+ <literal>DELETE</literal>, <literal>REPLACE</literal>, or
+ <literal>UPDATE</literal>. It does support <literal>ORDER
+ BY</literal> operations, <literal>BLOB</literal> columns, and
+ basically all but spatial data types (see
<xref linkend="mysql-spatial-datatypes"/>). The
<literal>ARCHIVE</literal> engine uses row-level locking.
</para>
@@ -3769,32 +3762,32 @@
<para>
<emphasis role="bold">Storage:</emphasis> Rows are compressed as
they are inserted. The <literal>ARCHIVE</literal> engine uses
- <ulink url="http://www.zlib.net/">zlib</ulink> lossless data
- compression. Use of <literal>OPTIMIZE TABLE</literal> can analyze
- the table and pack it into a smaller format (for a reason to use
- <literal>OPTIMIZE TABLE</literal>, see below). Beginning with
- MySQL 5.0.15, the <literal>ARCHIVE</literal> engine supports
- <literal>CHECK TABLE</literal>. There are several types of
- insertions that are used:
+ <literal>zlib</literal> lossless data compression (see
+ <ulink url="http://www.zlib.net/"/>). You can use
+ <literal>OPTIMIZE TABLE</literal> to analyze the table and pack it
+ into a smaller format (for a reason to use <literal>OPTIMIZE
+ TABLE</literal>, see later in this section). Beginning with MySQL
+ 5.0.15, the engine also supports <literal>CHECK TABLE</literal>.
+ There are several types of insertions that are used:
</para>
<itemizedlist>
<listitem>
<para>
- A straight <literal>INSERT</literal> just pushes rows into a
- compression buffer, and that buffer flushes as it needs. The
+ An <literal>INSERT</literal> statement just pushes rows into a
+ compression buffer, and that buffer flushes as necessary. The
insertion into the buffer is protected by a lock. A
<literal>SELECT</literal> forces a flush to occur, unless the
only insertions that have come in were <literal>INSERT
- DELAYED</literal> (those flush as need be). See
+ DELAYED</literal> (those flush as necessary). See
<xref linkend="insert-delayed"/>.
</para>
</listitem>
<listitem>
<para>
- A bulk insert is only visible after it completes, unless other
+ A bulk insert is visible only after it completes, unless other
inserts occur at the same time, in which case it can be seen
partially. A <literal>SELECT</literal> never causes a flush of
a bulk insert unless a normal insert occurs while it is
@@ -3813,12 +3806,12 @@
<literal>SELECT</literal> is performed as a consistent read. Note
that lots of <literal>SELECT</literal> statements during insertion
can deteriorate the compression, unless only bulk or delayed
- inserts are used. To fix any compression issues that have occurred
- you can always do an <literal>OPTIMIZE TABLE</literal>
- (<literal>REPAIR TABLE</literal> also is supported). The number of
- rows in <literal>ARCHIVE</literal> tables reported by
- <literal>SHOW TABLE STATUS</literal> is always accurate. See
- <xref linkend="repair-table"/>, <xref linkend="optimize-table"/>,
+ inserts are used. To achieve better compression, you can use
+ <literal>OPTIMIZE TABLE</literal> or <literal>REPAIR
+ TABLE</literal>. The number of rows in <literal>ARCHIVE</literal>
+ tables reported by <literal>SHOW TABLE STATUS</literal> is always
+ accurate. See <xref linkend="optimize-table"/>,
+ <xref linkend="repair-table"/>, and
<xref linkend="show-table-status"/>.
</para>
@@ -3889,7 +3882,7 @@
begins with the table name and has a <filename>.CSV</filename>
extension. The data file is a plain text file. When you store data
into the table, the storage engine saves it into the data file in
- CSV format.
+ comma-separated values format.
</para>
<programlisting>
@@ -3948,7 +3941,7 @@
<para>
The <literal>BLACKHOLE</literal> storage engine acts as a
<quote>black hole</quote> that accepts data but throws it away and
- does not store it. Retrievals always return the empty set:
+ does not store it. Retrievals always return an empty result:
</para>
<programlisting>
@@ -3986,7 +3979,8 @@
<para>
The <literal>BLACKHOLE</literal> storage engine supports all kinds
- of indexing.
+ of indexes. That is, you can include index declarations in the
+ table definition.
</para>
<para>
@@ -4022,9 +4016,9 @@
<para>
The master writes to its binary log. The <quote>dummy</quote>
- <literal>mysqld</literal> process acts as a slave, applying the
- desired combination of <literal>replicate-do</literal> and
- <literal>replicate-ignore</literal> rules, and writes a new,
+ <command>mysqld</command> process acts as a slave, applying the
+ desired combination of <literal>replicate-do-*</literal> and
+ <literal>replicate-ignore-*</literal> rules, and writes a new,
filtered binary log of its own. (See
<xref linkend="replication-options"/>.) This filtered log is
provided to the slave.
@@ -4033,7 +4027,7 @@
<para>
The dummy process does not actually store any data, so there is
little processing overhead incurred by running the additional
- <literal>mysqld</literal> process on the replication master host.
+ <command>mysqld</command> process on the replication master host.
This type of setup can be repeated with additional replication
slaves.
</para>
@@ -4047,7 +4041,7 @@
<listitem>
<para>
- Verification of dumpfile syntax.
+ Verification of dump file syntax.
</para>
</listitem>
Modified: trunk/refman-5.1/renamed-nodes.txt
===================================================================
--- trunk/refman-5.1/renamed-nodes.txt 2006-01-13 03:49:54 UTC (rev 794)
+++ trunk/refman-5.1/renamed-nodes.txt 2006-01-13 03:50:08 UTC (rev 795)
@@ -96,3 +96,4 @@
client-side-scripts client-utility-programs
mysqlcc client-utility-programs
innodb-start innodb-parameters
+federated-install federated-storage-engine
Modified: trunk/refman-5.1/storage-engines.xml
===================================================================
--- trunk/refman-5.1/storage-engines.xml 2006-01-13 03:49:54 UTC (rev 794)
+++ trunk/refman-5.1/storage-engines.xml 2006-01-13 03:50:08 UTC (rev 795)
@@ -2866,17 +2866,18 @@
</para>
<para>
- You can start a transaction with the <literal>BEGIN
- WORK</literal> statement to suspend autocommit, or with
- <literal>SET AUTOCOMMIT=0</literal> to disable autocommit
- explicitly.
+ You can start a transaction with the <literal>START
+ TRANSACTION</literal> or <literal>BEGIN</literal> statement
+ to suspend autocommit, or with <literal>SET
+ AUTOCOMMIT=0</literal> to disable autocommit explicitly.
</para>
</listitem>
</itemizedlist>
<para>
- See <xref linkend="commit"/>.
+ For more information about transactions, see
+ <xref linkend="commit"/>.
</para>
<para>
@@ -2896,25 +2897,24 @@
<listitem>
<para>
- MySQL requires a <literal>PRIMARY KEY</literal> in each
- <literal>BDB</literal> table so that each row can be
- uniquely identified. If you don't create one explicitly,
- MySQL creates and maintains a hidden <literal>PRIMARY
- KEY</literal> for you. The hidden key has a length of five
- bytes and is incremented for each insert attempt. This key
- does not appear in the output of <literal>SHOW CREATE
- TABLE</literal> or <literal>DESCRIBE</literal>.
+ MySQL requires a primary key in each <literal>BDB</literal>
+ table so that each row can be uniquely identified. If you
+ don't create one explicitly by declaring a <literal>PRIMARY
+ KEY</literal>, MySQL creates and maintains a hidden primary
+ key for you. The hidden key has a length of five bytes and
+ is incremented for each insert attempt. This key does not
+ appear in the output of <literal>SHOW CREATE TABLE</literal>
+ or <literal>DESCRIBE</literal>.
</para>
</listitem>
<listitem>
<para>
- The <literal>PRIMARY KEY</literal> is faster than any other
- index, because the <literal>PRIMARY KEY</literal> is stored
- together with the row data. The other indexes are stored as
- the key data + the <literal>PRIMARY KEY</literal>, so it's
- important to keep the <literal>PRIMARY KEY</literal> as
- short as possible to save disk space and get better speed.
+ The primary key is faster than any other index, because it
+ is stored together with the row data. The other indexes are
+ stored as the key data plus the primary key, so it's
+ important to keep the primary key as short as possible to
+ save disk space and get better speed.
</para>
<para>
@@ -2927,20 +2927,20 @@
<listitem>
<para>
- If all columns you access in a <literal>BDB</literal> table
- are part of the same index or part of the primary key, MySQL
- can execute the query without having to access the actual
- row. In a <literal>MyISAM</literal> table, this can be done
- only if the columns are part of the same index.
+ If all columns that you access in a <literal>BDB</literal>
+ table are part of the same index or part of the primary key,
+ MySQL can execute the query without having to access the
+ actual row. In a <literal>MyISAM</literal> table, this can
+ be done only if the columns are part of the same index.
</para>
</listitem>
<listitem>
<para>
- Sequential scanning is slower than for
- <literal>MyISAM</literal> tables because the data in
- <literal>BDB</literal> tables is stored in B-trees and not
- in a separate data file.
+ Sequential scanning is slower for <literal>BDB</literal>
+ tables than for <literal>MyISAM</literal> tables because the
+ data in <literal>BDB</literal> tables is stored in B-trees
+ and not in a separate data file.
</para>
</listitem>
@@ -3146,9 +3146,9 @@
<listitem>
<para>
- Each <literal>BDB</literal> table stores in the
+ Each <literal>BDB</literal> table stores in its
<filename>.db</filename> file the path to the file as it was
- created. This was done enable detection of locks in a
+ created. This is done to enable detection of locks in a
multi-user environment that supports symlinks. As a
consequence of this, it is not possible to move
<literal>BDB</literal> table files from one database
@@ -3168,7 +3168,9 @@
files and requires them to be present when
<command>mysqld</command> starts. The <literal>BDB</literal>
logs are the files in the data directory with names of the
- form <filename>log.XXXXXXXXXX</filename> (ten digits).
+ form
+ <filename>log.<replaceable>NNNNNNNNNN</replaceable></filename>
+ (ten digits).
</para>
</listitem>
@@ -3176,7 +3178,9 @@
<para>
If a column that allows <literal>NULL</literal> values has a
unique index, only a single <literal>NULL</literal> value is
- allowed. This differs from other storage engines.
+ allowed. This differs from other storage engines, which
+ allow multiple <literal>NULL</literal> values in unique
+ indexes.
</para>
</listitem>
@@ -3194,23 +3198,24 @@
<para>
If the following error occurs when you start
<command>mysqld</command> after upgrading, it means that the
- new <literal>BDB</literal> version doesn't support the old
- log file format:
+ current version of <literal>BDB</literal> doesn't support
+ the old log file format:
</para>
<programlisting>
-bdb: Ignoring log file: .../log.XXXXXXXXXX:
+bdb: Ignoring log file: .../log.<replaceable>NNNNNNNNNN</replaceable>:
unsupported log version #
</programlisting>
<para>
In this case, you must delete all <literal>BDB</literal>
- logs from your data directory (the files with names that
- have the format <filename>log.XXXXXXXXXX</filename>) and
- restart <command>mysqld</command>. We also recommend that
- you then use <command>mysqldump --opt</command> to dump your
- <literal>BDB</literal> tables, drop the tables, and restore
- them from the dump file.
+ logs from your data directory (the files that have names of
+ the form
+ <filename>log.<replaceable>NNNNNNNNNN</replaceable></filename>)
+ and restart <command>mysqld</command>. We also recommend
+ that you then use <command>mysqldump --opt</command> to dump
+ your <literal>BDB</literal> tables, drop the tables, and
+ restore them from the dump file.
</para>
</listitem>
@@ -3229,10 +3234,10 @@
</programlisting>
<para>
- This is not fatal, but until the problem is fixed, we
- recommend that you not drop <literal>BDB</literal> tables
- except while autocommit mode is enabled. (The fix is not
- trivial.)
+ This is not fatal, but the fix is not trivial. Until the
+ problem is fixed, we recommend that you not drop
+ <literal>BDB</literal> tables except while autocommit mode
+ is enabled.
</para>
</listitem>
@@ -3285,7 +3290,8 @@
creates a table definition file in the database directory. The
file begins with the table name and has an
<filename>.frm</filename> extension. No other files are created.
- No data can be stored into the table or retrieved from it.
+ No data can be stored into the table. Retrievals return an empty
+ result.
</para>
<programlisting>
@@ -3357,18 +3363,6 @@
</itemizedlist>
- <section id="federated-install">
-
- <title>&title-federated-install;</title>
-
- <para>
- To enable this storage engine, use the
- <option>--with-federated-storage-engine</option> option to
- <command>configure</command> when you build MySQL.
- </para>
-
- </section>
-
<section id="federated-description">
<title>&title-federated-description;</title>
@@ -3378,8 +3372,8 @@
creates a table definition file in the database directory. The
file begins with the table name and has an
<filename>.frm</filename> extension. No other files are created,
- because the actual data is in a remote database. This differs
- from the way that storage engines for local tables work.
+ because the actual data is in a remote table. This differs from
+ the way that storage engines for local tables work.
</para>
<para>
@@ -3399,20 +3393,20 @@
With the MySQL <literal>FEDERATED</literal> storage engine,
there are no local data files for a table (for example, there is
no <filename>.MYD</filename> file). Instead, a remote database
- stores the data that normally would be in the table. This
- necessitates the use of the MySQL client API to read, delete,
- update, and insert data. Data retrieval is initiated via a
- <literal>SELECT * FROM
+ stores the data that normally would be in the table. The local
+ server connects to a remote server, and uses the MySQL client
+ API to read, delete, update, and insert data in the remote
+ table. Data retrieval is initiated via a <literal>SELECT * FROM
<replaceable>tbl_name</replaceable></literal> SQL statement. To
read the result, rows are fetched one at a time by using the
<literal>mysql_fetch_row()</literal> C API function, and then
- converted from the columns in the <literal>SELECT</literal>
- result set to the format that the <literal>FEDERATED</literal>
- handler expects.
+ converting the columns in the <literal>SELECT</literal> result
+ set to the format that the <literal>FEDERATED</literal> handler
+ expects.
</para>
<para>
- The basic flow is as follows:
+ The flow of information is as follows:
</para>
<orderedlist>
@@ -3471,36 +3465,35 @@
<para>
The procedure for using <literal>FEDERATED</literal> tables is
very simple. Normally, you have two servers running, either both
- on the same host or on different hosts. (It is also possible for
- a <literal>FEDERATED</literal> table to use another table that
- is managed by the same server, though there is little point in
+ on the same host or on different hosts. (It is possible for a
+ <literal>FEDERATED</literal> table to use another table that is
+ managed by the same server, though there is little point in
doing so.)
</para>
<para>
First, you must have a table on the remote server that you want
- to access with the <literal>FEDERATED</literal> table. Suppose
+ to access by using a <literal>FEDERATED</literal> table. Suppose
that the remote table is in the <literal>federated</literal>
database and is defined like this:
</para>
<programlisting>
CREATE TABLE test_table (
- id int(20) NOT NULL auto_increment,
- name varchar(32) NOT NULL default '',
- other int(20) NOT NULL default '0',
+ id INT(20) NOT NULL AUTO_INCREMENT,
+ name VARCHAR(32) NOT NULL DEFAULT '',
+ other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id),
- KEY name (name),
- KEY other_key (other)
+ INDEX name (name),
+ INDEX other_key (other)
)
ENGINE=MyISAM
DEFAULT CHARSET=latin1;
</programlisting>
<para>
- The <literal>ENGINE</literal> table option could name any
- storage engine; the table need not be a
- <literal>MyISAM</literal> table.
+ The example uses a <literal>MyISAM</literal> table, but the
+ table could use any storage engine.
</para>
<para>
@@ -3510,12 +3503,12 @@
<programlisting>
CREATE TABLE federated_table (
- id int(20) NOT NULL auto_increment,
- name varchar(32) NOT NULL default '',
- other int(20) NOT NULL default '0',
+ id INT(20) NOT NULL AUTO_INCREMENT,
+ name VARCHAR(32) NOT NULL DEFAULT '',
+ other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id),
- KEY name (name),
- KEY other_key (other)
+ INDEX name (name),
+ INDEX other_key (other)
)
ENGINE=FEDERATED
DEFAULT CHARSET=latin1
@@ -3548,9 +3541,10 @@
The remote host information indicates the remote server to which
your local server connects, and the database and table
information indicates which remote table to use as the data
- file. In this example, the remote server is indicated to be
- running as <literal>remote_host</literal> on port 9306, so you
- want to start that server so that it listens to port 9306.
+ source. In this example, the remote server is indicated to be
+ running as <literal>remote_host</literal> on port 9306, so there
+ must be a MySQL server running on the remote host and listening
+ to port 9306.
</para>
<para>
@@ -3564,8 +3558,8 @@
<para>
Only <literal>mysql</literal> is supported as the
- <replaceable>scheme</replaceable> at this point; the password
- and port number are optional.
+ <replaceable>scheme</replaceable> value at this point; the
+ password and port number are optional.
</para>
<para>
@@ -3581,13 +3575,14 @@
<para>
The use of <literal>CONNECTION</literal> for specifying the
connection string is non-optimal and is likely to change in
- future. Keep this in mind when you use
- <literal>FEDERATED</literal> tables, because it means that
- modifications are likely to be required when that happens.
+ future. Keep this in mind for applications that use
+ <literal>FEDERATED</literal> tables. Such applications are
+ likely to need modification if the format for specifying
+ connection information changes.
</para>
<para>
- Because any password used is stored in the connection string as
+ Because any password given in the connection string is stored as
plain text, it can be seen by any user who can use <literal>SHOW
CREATE TABLE</literal> or <literal>SHOW TABLE STATUS</literal>
for the <literal>FEDERATED</literal> table, or query the
@@ -3595,10 +3590,6 @@
<literal>INFORMATION_SCHEMA</literal> database.
</para>
- <para>
- <emphasis role="bold">Additional resources</emphasis>
- </para>
-
</section>
<section id="federated-limitations">
@@ -3606,8 +3597,9 @@
<title>&title-federated-limitations;</title>
<para>
- What the <literal>FEDERATED</literal> storage engine does and
- does not support:
+ The following items indicate features that the
+ <literal>FEDERATED</literal> storage engine does and does not
+ support:
</para>
<itemizedlist>
@@ -3754,17 +3746,18 @@
<filename>.frm</filename> extension. The storage engine creates
other files, all having names beginning with the table name. The
data and metadata files have extensions of
- <filename>.ARZ</filename> and <filename>.ARM</filename>. A
- <filename>.ARN</filename> file may appear during optimization
- operations.
+ <filename>.ARZ</filename> and <filename>.ARM</filename>,
+ respectively. An <filename>.ARN</filename> file may appear during
+ optimization operations.
</para>
<para>
- The <literal>ARCHIVE</literal> engine supports only
- <literal>INSERT</literal> and <literal>SELECT</literal> (no
- deletes, replaces, or updates). It does support <literal>ORDER
- BY</literal> operations, <literal>BLOB</literal> fields, and
- basically all data types except geometry data types (see
+ The <literal>ARCHIVE</literal> engine supports
+ <literal>INSERT</literal> and <literal>SELECT</literal>, but not
+ <literal>DELETE</literal>, <literal>REPLACE</literal>, or
+ <literal>UPDATE</literal>. It does support <literal>ORDER
+ BY</literal> operations, <literal>BLOB</literal> columns, and
+ basically all but spatial data types (see
<xref linkend="mysql-spatial-datatypes"/>). The
<literal>ARCHIVE</literal> engine uses row-level locking.
</para>
@@ -3785,31 +3778,32 @@
<para>
<emphasis role="bold">Storage:</emphasis> Rows are compressed as
they are inserted. The <literal>ARCHIVE</literal> engine uses
- <ulink url="http://www.zlib.net/">zlib</ulink> lossless data
- compression. Use of <literal>OPTIMIZE TABLE</literal> can analyze
- the table and pack it into a smaller format (for a reason to use
- <literal>OPTIMIZE TABLE</literal>, see below). The engine also
- supports <literal>CHECK TABLE</literal>, too. There are several
- types of insertions that are used:
+ <literal>zlib</literal> lossless data compression (see
+ <ulink url="http://www.zlib.net/"/>). You can use
+ <literal>OPTIMIZE TABLE</literal> to analyze the table and pack it
+ into a smaller format (for a reason to use <literal>OPTIMIZE
+ TABLE</literal>, see later in this section). The engine also
+ supports <literal>CHECK TABLE</literal>. There are several types
+ of insertions that are used:
</para>
<itemizedlist>
<listitem>
<para>
- A straight <literal>INSERT</literal> just pushes rows into a
- compression buffer, and that buffer flushes as it needs. The
+ An <literal>INSERT</literal> statement just pushes rows into a
+ compression buffer, and that buffer flushes as necessary. The
insertion into the buffer is protected by a lock. A
<literal>SELECT</literal> forces a flush to occur, unless the
only insertions that have come in were <literal>INSERT
- DELAYED</literal> (those flush as need be). See
+ DELAYED</literal> (those flush as necessary). See
<xref linkend="insert-delayed"/>.
</para>
</listitem>
<listitem>
<para>
- A bulk insert is only visible after it completes, unless other
+ A bulk insert is visible only after it completes, unless other
inserts occur at the same time, in which case it can be seen
partially. A <literal>SELECT</literal> never causes a flush of
a bulk insert unless a normal insert occurs while it is
@@ -3828,12 +3822,12 @@
<literal>SELECT</literal> is performed as a consistent read. Note
that lots of <literal>SELECT</literal> statements during insertion
can deteriorate the compression, unless only bulk or delayed
- inserts are used. To fix any compression issues that have occurred
- you can always do an <literal>OPTIMIZE TABLE</literal>
- (<literal>REPAIR TABLE</literal> also is supported). The number of
- rows in <literal>ARCHIVE</literal> tables reported by
- <literal>SHOW TABLE STATUS</literal> is always accurate. See
- <xref linkend="repair-table"/>, <xref linkend="optimize-table"/>,
+ inserts are used. To achieve better compression, you can use
+ <literal>OPTIMIZE TABLE</literal> or <literal>REPAIR
+ TABLE</literal>. The number of rows in <literal>ARCHIVE</literal>
+ tables reported by <literal>SHOW TABLE STATUS</literal> is always
+ accurate. See <xref linkend="optimize-table"/>,
+ <xref linkend="repair-table"/>, and
<xref linkend="show-table-status"/>.
</para>
@@ -3904,7 +3898,7 @@
begins with the table name and has a <filename>.CSV</filename>
extension. The data file is a plain text file. When you store data
into the table, the storage engine saves it into the data file in
- CSV format.
+ comma-separated values format.
</para>
<programlisting>
@@ -3963,7 +3957,7 @@
<para>
The <literal>BLACKHOLE</literal> storage engine acts as a
<quote>black hole</quote> that accepts data but throws it away and
- does not store it. Retrievals always return the empty set:
+ does not store it. Retrievals always return an empty result:
</para>
<programlisting>
@@ -4001,7 +3995,8 @@
<para>
The <literal>BLACKHOLE</literal> storage engine supports all kinds
- of indexing.
+ of indexes. That is, you can include index declarations in the
+ table definition.
</para>
<para>
@@ -4037,9 +4032,9 @@
<para>
The master writes to its binary log. The <quote>dummy</quote>
- <literal>mysqld</literal> process acts as a slave, applying the
- desired combination of <literal>replicate-do</literal> and
- <literal>replicate-ignore</literal> rules, and writes a new,
+ <command>mysqld</command> process acts as a slave, applying the
+ desired combination of <literal>replicate-do-*</literal> and
+ <literal>replicate-ignore-*</literal> rules, and writes a new,
filtered binary log of its own. (See
<xref linkend="replication-options"/>.) This filtered log is
provided to the slave.
@@ -4048,7 +4043,7 @@
<para>
The dummy process does not actually store any data, so there is
little processing overhead incurred by running the additional
- <literal>mysqld</literal> process on the replication master host.
+ <command>mysqld</command> process on the replication master host.
This type of setup can be repeated with additional replication
slaves.
</para>
@@ -4062,7 +4057,7 @@
<listitem>
<para>
- Verification of dumpfile syntax.
+ Verification of dump file syntax.
</para>
</listitem>
@@ -4087,8 +4082,8 @@
<para>
As of MySQL 5.1.4, the <literal>BLACKHOLE</literal> engine is
- transaction-aware in the sense that committed transactions are
- written to the binary log, but rolled-back transactions are not.
+ transaction-aware, in the sense that committed transactions are
+ written to the binary log and rolled-back transactions are not.
</para>
</section>
Modified: trunk/refman-common/titles.en.ent
===================================================================
--- trunk/refman-common/titles.en.ent 2006-01-13 03:49:54 UTC (rev 794)
+++ trunk/refman-common/titles.en.ent 2006-01-13 03:50:08 UTC (rev 795)
@@ -373,7 +373,6 @@
<!ENTITY title-extensions-to-ansi "MySQL Extensions to Standard SQL">
<!ENTITY title-features "The Main Features of MySQL">
<!ENTITY title-federated-description "Description of the <literal>FEDERATED</literal> Storage Engine">
-<!ENTITY title-federated-install "Installing the <literal>FEDERATED</literal> Storage Engine">
<!ENTITY title-federated-limitations "Limitations of the <literal>FEDERATED</literal> Storage Engine">
<!ENTITY title-federated-storage-engine "The <literal>FEDERATED</literal> Storage Engine">
<!ENTITY title-federated-use "How to use <literal>FEDERATED</literal> Tables">
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r795 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common | paul | 13 Jan |
