List:Commits« Previous MessageNext Message »
From:paul Date:January 12 2006 6:18pm
Subject:svn commit - mysqldoc@docsrva: r776 - in trunk: . refman-5.1
View as plain text  
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
+      &mdash; such as data warehousing, transaction processing, or high
+      availability situations &mdash; 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> &mdash; 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> &mdash; 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> &mdash; 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> &mdash; 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> &mdash; 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> &mdash; 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> &mdash; 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> &mdash;
+          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> &mdash; 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> &mdash; 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> &mdash; 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> &mdash; 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> &mdash; 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> &mdash; 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> &mdash; 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> &mdash; 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> &mdash; 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> &mdash; 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> &mdash; 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> &mdash; 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.1paul12 Jan