Author: paul
Date: 2006-01-12 19:18:31 +0100 (Thu, 12 Jan 2006)
New Revision: 776
Log:
r6111@frost: paul | 2006-01-12 11:03:46 -0600
General revisions.
Modified:
trunk/
trunk/refman-5.1/pluggable-storage.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6094
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2101
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6111
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2101
Modified: trunk/refman-5.1/pluggable-storage.xml
===================================================================
--- trunk/refman-5.1/pluggable-storage.xml 2006-01-12 18:17:32 UTC (rev 775)
+++ trunk/refman-5.1/pluggable-storage.xml 2006-01-12 18:18:31 UTC (rev 776)
@@ -20,7 +20,7 @@
<para>
With MySQL 5.1, MySQL AB has introduced a new pluggable storage
engine architecture that allows storage engines to be loaded into
- a running MySQL server.
+ and unloaded from a running MySQL server.
</para>
<para>
@@ -43,14 +43,15 @@
the need to manage any specific application coding requirements.
The MySQL server architecture isolates the application programmer
and DBA from all of the low-level implementation details at the
- storage level providing a consistent and easy application model
- and API. So while there are different capabilities across
- different storage engines, the application is shielded from these.
+ storage level, providing a consistent and easy application model
+ and API. Thus, although there are different capabilities across
+ different storage engines, the application is shielded from these
+ differences.
</para>
<para>
- Graphically depicted, the MySQL pluggable storage engine
- architecture looks like the following:
+ The MySQL pluggable storage engine architecture has the structure
+ shown in the following figure:
</para>
<figure>
@@ -78,8 +79,8 @@
<para>
This efficient and modular architecture provides huge benefits for
those wishing to specifically target a particular application need
- – such as data warehousing, transaction processing, high
- availability situations, etc. – while enjoying the advantage of
+ — such as data warehousing, transaction processing, or high
+ availability situations — while enjoying the advantage of
utilizing a set of interfaces and services that are independent of
any one storage engine.
</para>
@@ -93,7 +94,7 @@
new needs, no significant coding or process changes are required
to make things work. The MySQL server architecture shields the
application from the underlying complexity of the storage engine
- by presenting a consistent and easy to use API that applies across
+ by presenting a consistent and easy-to-use API that applies across
storage engines.
</para>
@@ -120,42 +121,42 @@
<para>
From a technical perspective, what are some of the unique
supporting infrastructure components that are in a storage engine?
- Some of the key differentiations include:
+ Some of the key feature differentiations include:
</para>
<itemizedlist>
<listitem>
<para>
- <literal>Concurrency</literal> – some applications have more
- granular lock requirements (such as row-level locks) than
- others. Choosing the right locking strategy can reduce
- overhead and therefore help with overall performance. This
- area also includes support for capabilities like multi-version
- concurrency control or “snapshot” read.
+ <emphasis>Concurrency</emphasis> — some applications
+ have more granular lock requirements (such as row-level locks)
+ than others. Choosing the right locking strategy can reduce
+ overhead and therefore improve overall performance. This area
+ also includes support for capabilities such as multi-version
+ concurrency control or <quote>snapshot</quote> read.
</para>
</listitem>
<listitem>
<para>
- <literal>Transaction Support</literal> – not every
+ <emphasis>Transaction Support</emphasis> — Not every
application needs transactions, but for those that do, there
- are very well defined requirements like ACID compliance and
+ are very well defined requirements such as ACID compliance and
more.
</para>
</listitem>
<listitem>
<para>
- <literal>Referential Integrity</literal> – the need to have
- the server enforce relational database referential integrity
- through DDL defined foreign keys.
+ <emphasis>Referential Integrity</emphasis> — The need to
+ have the server enforce relational database referential
+ integrity through DDL defined foreign keys.
</para>
</listitem>
<listitem>
<para>
- <literal>Physical Storage</literal> – this involves
+ <emphasis>Physical Storage</emphasis> — This involves
everything from the overall page size for tables and indexes
as well as the format used for storing data to physical disk.
</para>
@@ -163,28 +164,28 @@
<listitem>
<para>
- <literal>Index Support</literal> – different application
- scenarios tend to benefit from different index strategies, and
- so each storage engine generally has its own indexing methods,
- although some (like B-tree indexes) are common to nearly all
- engines.
+ <emphasis>Index Support</emphasis> — Different
+ application scenarios tend to benefit from different index
+ strategies. Each storage engine generally has its own indexing
+ methods, although some (such as B-tree indexes) are common to
+ nearly all engines.
</para>
</listitem>
<listitem>
<para>
- <literal>Memory Caches</literal> – different applications
- respond better to some memory caching strategies than others,
- so while some memory caches are common to all storage engines
- (like those used for user connections, MySQL’s high-speed
- Query Cache, etc.), others are uniquely defined only when a
- particular storage engine is put in play.
+ <emphasis>Memory Caches</emphasis> — Different
+ applications respond better to some memory caching strategies
+ than others, so although some memory caches are common to all
+ storage engines (such as those used for user connections or
+ MySQL's high-speed Query Cache), others are uniquely defined
+ only when a particular storage engine is put in play.
</para>
</listitem>
<listitem>
<para>
- <literal>Performance Aids</literal> – includes things like
+ <emphasis>Performance Aids</emphasis> — This includes
multiple I/O threads for parallel operations, thread
concurrency, database checkpointing, bulk insert handling, and
more.
@@ -193,10 +194,10 @@
<listitem>
<para>
- <literal>Miscellaneous Target Features</literal> – this may
- include things like support for geospatial operations,
- security restrictions for certain data manipulation
- operations, and other like items.
+ <emphasis>Miscellaneous Target Features</emphasis> —
+ This may include support for geospatial operations, security
+ restrictions for certain data manipulation operations, and
+ other similar features.
</para>
</listitem>
@@ -206,11 +207,10 @@
Each set of the pluggable storage engine infrastructure components
are designed to offer a selective set of benefits for a particular
application. Conversely, avoiding a set of component features
- helps steer clear of unnecessary overhead. So it stands to reason
- that understanding a particular application’s set of
- requirements and selecting the proper MySQL storage engine can
- have a dramatic impact on overall system efficiency and
- performance.
+ helps reduce unnecessary overhead. It stands to reason that
+ understanding a particular application's set of requirements and
+ selecting the proper MySQL storage engine can have a dramatic
+ impact on overall system efficiency and performance.
</para>
</section>
@@ -221,13 +221,10 @@
<para>
The various storage engines provided with MySQL are designed with
- different use-cases in mind. In order to use the pluggable storage
+ different use-cases in mind. To use the pluggable storage
architecture effectively, it is good to have an idea of the
- benefits and drawbacks of the various storage engines.
- </para>
-
- <para>
- The following table provides an overview of the storage engines
+ benefits and drawbacks of the various storage engines. The
+ following table provides an overview of some storage engines
provided with MySQL:
</para>
@@ -251,25 +248,26 @@
<listitem>
<para>
- <literal>MyISAM</literal> - the default MySQL pluggable
+ <literal>MyISAM</literal> — The default MySQL pluggable
storage engine and the one that is used the most in Web, data
warehousing, and other application environments. Note that a
MySQL server's default storage engine can easily be changed by
- altering the STORAGE_ENGINE configuration variable.
+ setting the <literal>storage_engine</literal> configuration
+ variable.
</para>
</listitem>
<listitem>
<para>
- <literal>InnoDB</literal> - used for transaction processing
- applications, and sports a number of features including ACID
- transaction support.
+ <literal>InnoDB</literal> — Used for transaction
+ processing applications, and sports a number of features
+ including ACID transaction support and foreign keys.
</para>
</listitem>
<listitem>
<para>
- <literal>BDB</literal> - an alternative transaction engine to
+ <literal>BDB</literal> — An alternative to
<literal>InnoDB</literal> that supports
<literal>COMMIT</literal>, <literal>ROLLBACK</literal>, and
other transactional features.
@@ -278,33 +276,34 @@
<listitem>
<para>
- <literal>Memory</literal> - stores all data in RAM for
- extremely fast access in environments that require quick look
- ups of reference and other like data.
+ <literal>Memory</literal> — Stores all data in RAM for
+ extremely fast access in environments that require quick
+ lookups of reference and other like data.
</para>
</listitem>
<listitem>
<para>
- <literal>Merge</literal> - allows a MySQL DBA or developer to
- logically group together a series of identical
+ <literal>Merge</literal> — Allows a MySQL DBA or
+ developer to logically group a series of identical
<literal>MyISAM</literal> tables and reference them as one
- object. Good for VLDB environments like data warehousing.
+ object. Good for VLDB environments such as data warehousing.
</para>
</listitem>
<listitem>
<para>
- <literal>Archive</literal> - provides the perfect solution for
- storing and retrieving large amounts of seldom-referenced
- historical, archived, or security audit information.
+ <literal>Archive</literal> — Provides the perfect
+ solution for storing and retrieving large amounts of
+ seldom-referenced historical, archived, or security audit
+ information.
</para>
</listitem>
<listitem>
<para>
- <literal>Federated</literal> - offers the ability to link
- together separate MySQL servers to create one logical database
+ <literal>Federated</literal> — Offers the ability to
+ link separate MySQL servers to create one logical database
from many physical servers. Very good for distributed or data
mart environments.
</para>
@@ -312,8 +311,8 @@
<listitem>
<para>
- <literal>NDB</literal> - the Clustered database engine of
- MySQL that is particularly suited for applications with high
+ <literal>NDB</literal> — The Clustered database engine
+ that is particularly suited for applications with high
performance lookup needs that also require the highest
possible degree of uptime and availability.
</para>
@@ -321,10 +320,11 @@
<listitem>
<para>
- <literal>Other</literal> - other storage engines include CSV
- (references comma-separated files as database tables),
- Blackhole (for temporarily disabling application input to the
- database) and an Example engine that helps jump start the
+ <literal>Other</literal> — Other storage engines include
+ <literal>CSV</literal> (references comma-separated files as
+ database tables), <literal>Blackhole</literal> (for
+ temporarily disabling application input to the database), and
+ an <literal>Example</literal> engine that helps jump start the
process of creating custom pluggable storage engines.
</para>
</listitem>
@@ -355,13 +355,11 @@
<para>
To specify a storage engine when creating a table, use the
- <literal>ENGINE</literal> parameter:
+ <literal>ENGINE</literal> table option:
</para>
<programlisting>
-CREATE TABLE engineTest(
-id INT
-) ENGINE = MyISAM;
+CREATE TABLE engineTest (id INT) ENGINE = MyISAM;
</programlisting>
<para>
@@ -370,7 +368,7 @@
</para>
<programlisting>
-ALTER TABLE <replaceable>engineTest</replaceable> ENGINE = <replaceable>ARCHIVE</replaceable>;
+ALTER TABLE engineTest ENGINE = ARCHIVE;
</programlisting>
</section>
@@ -380,30 +378,30 @@
<title>&title-pluggable-storage-transactions;</title>
<para>
- Transactions are supported by the following storage engines:
+ The following storage engines support transactions:
</para>
<itemizedlist>
<listitem>
<para>
- <literal>InnoDB</literal> - Supports transactions through
- MVCC, allows for <literal>COMMIT</literal>,
+ <literal>InnoDB</literal> — Supports transactions
+ through MVCC, allows for <literal>COMMIT</literal>,
<literal>ROLLBACK</literal>, and savepoints.
</para>
</listitem>
<listitem>
<para>
- <literal>NDB</literal> - Supports transactions, allows for
- <literal>COMMIT</literal> and <literal>ROLLBACK</literal>.
+ <literal>NDB</literal> — Supports transactions, allows
+ for <literal>COMMIT</literal> and <literal>ROLLBACK</literal>.
</para>
</listitem>
<listitem>
<para>
- <literal>BDB</literal> - Supports transactions, allows for
- <literal>COMMIT</literal> and <literal>ROLLBACK</literal>.
+ <literal>BDB</literal> — Supports transactions, allows
+ for <literal>COMMIT</literal> and <literal>ROLLBACK</literal>.
</para>
</listitem>
@@ -417,19 +415,22 @@
<para>
Before a storage engine can be used, the storage engine plugin
- must be loaded into mysql using the <literal>INSTALL
- PLUGIN</literal> statement. For example, to load the example
- engine you would first load the ha_example.so module:
+ shared library must be loaded into MySQL using the
+ <literal>INSTALL PLUGIN</literal> statement. For example, if the
+ <literal>EXAMPLE</literal> engine plugin is named
+ <literal>ha_example</literal> and the shared library is named
+ <filename>ha_example.so</filename>, you load it with the following
+ statement:
</para>
<programlisting>
-INSTALL PLUGIN <replaceable>ha_example</replaceable> SONAME '<replaceable>ha_example.so</replaceable>';
+INSTALL PLUGIN ha_example SONAME 'ha_example.so';
</programlisting>
<para>
- The <filename>.so</filename> file must be located in the MySQL
- server library directory (typically
- <filename>installdir/lib</filename>).
+ The shared library must be located in the MySQL server plugin
+ directory, the location of which is given by the
+ <literal>plugin_dir</literal> system variable.
</para>
</section>
@@ -444,15 +445,14 @@
</para>
<programlisting>
-UNINSTALL PLUGIN <replaceable>ha_example</replaceable>;
+UNINSTALL PLUGIN ha_example;
</programlisting>
<para>
- If you unplug a storage engine that is being used by existing
- tables, those tables will not be accessible, but will still be
- present on disk (where applicable). Ensure that there are no
- tables using a storage engine before you unplug the storage
- engine.
+ If you unplug a storage engine that is needed by existing tables,
+ those tables become accessible, but will still be present on disk
+ (where applicable). Ensure that there are no tables using a
+ storage engine before you unplug the storage engine.
</para>
</section>
@@ -462,10 +462,10 @@
<title>&title-pluggable-storage-security;</title>
<para>
- In order to install a pluggable storage engine, the plugin file
- must be located in the appropriate MySQL library directory, and
- the user issuing the <literal>INSTALL PLUGIN</literal> statement
- must have <literal>INSERT</literal> privileges on the
+ To install a pluggable storage engine, the plugin file must be
+ located in the MySQL plugin directory, and the user issuing the
+ <literal>INSTALL PLUGIN</literal> statement must have
+ <literal>INSERT</literal> privileges for the
<literal>mysql.plugin</literal> table.
</para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r776 - in trunk: . refman-5.1 | paul | 12 Jan |
