svn commit - mysqldoc@docsrva: r24783 - trunk/dynamic-docs/glossary

[john.russell]

Author: jrussell
Date: 2011-01-12 17:26:19 +0100 (Wed, 12 Jan 2011)
New Revision: 24783

Log:
Improved wording and cross-referencing for a few entries.
Improved the distinction between "built-in" and "plugin",
taking a 5.5-centric viewpoint.


Modified:
   trunk/dynamic-docs/glossary/innodb.xml


Modified: trunk/dynamic-docs/glossary/innodb.xml
===================================================================
--- trunk/dynamic-docs/glossary/innodb.xml	2011-01-12 16:05:14 UTC (rev 24782)
+++ trunk/dynamic-docs/glossary/innodb.xml	2011-01-12 16:26:19 UTC (rev 24783)
Changed blocks: 7, Lines Added: 41, Lines Deleted: 22; 5193 bytes

@@ -512,7 +512,12 @@
         a memory area might be smaller than necessary; access to a
         single required resource might prevent multiple CPU cores from
         running simultaneously; or waiting for disk I/O to complete
-        might prevent the CPU from running at full capacity.
+        might prevent the CPU from running at full capacity. Removing
+        bottlenecks tends to improve
+        <emphasis role="bold">concurrency</emphasis>. For example, the
+        ability to have multiple InnoDB <emphasis role="bold">buffer
+        pool</emphasis> instances reduces contention when multiple
+        sessions read from and write to the buffer pool simultaneously.
       </para>
 
     </def>

@@ -552,16 +557,16 @@
     <def>
 
       <para>
-        The memory area that holds cached InnoDB data, read from both
-        tables and indexes. For efficiency of high-volume read
-        operations, the buffer pool is divided into
+        The memory area that holds cached InnoDB data for both tables
+        and indexes. For efficiency of high-volume read operations, the
+        buffer pool is divided into
         <emphasis role="bold">pages</emphasis> that can potentially hold
         multiple rows. For efficiency of cache management, the buffer
-        pool is implemented as a linked list of pages, so that data that
-        is rarely used can be aged out of the cache, using a variation
-        of the <emphasis role="bold">LRU</emphasis> algorithm. On
-        systems with large memory, you can improve concurrency by
-        dividing the buffer pool into multiple instances.
+        pool is implemented as a linked list of pages; data that is
+        rarely used is aged out of the cache, using a variation of the
+        <emphasis role="bold">LRU</emphasis> algorithm. On systems with
+        large memory, you can improve concurrency by dividing the buffer
+        pool into multiple instances.
       </para>
 
     </def>

@@ -580,9 +585,9 @@
         change table data. These statements can be replayed to bring
         slave servers up to date in a replication scenario, or to bring
         a database up to date after restoring table data from a backup.
-        The binary logging feature can be turned on and off, although we
-        recommend always enabling it if you use replication or perform
-        backups.
+        The binary logging feature can be turned on and off, although
+        Oracle recommends always enabling it if you use replication or
+        perform backups.
       </para>
       <para>
         You can examine the contents of the binary log, or replay those

@@ -605,6 +610,7 @@
 
     </def>
     <gseealso glosid="binlog" />
+    <gseealso glosid="mysql_enterprise_backup" />
 
   </glossent>
 

@@ -616,7 +622,7 @@
       <para>
         An informal name for the <emphasis role="bold">binary
         log</emphasis> file. For example, you might see this
-        abbreviation used in certain messages or forum discussions.
+        abbreviation used in e-mail messages or forum discussions.
       </para>
 
     </def>

@@ -637,8 +643,14 @@
         base as the built-in InnoDB storage engine (known as InnoDB
         1.1).
       </para>
+      <para>
+        This distinction is important mainly in MySQL 5.1, where a
+        feature or bug fix might apply to the InnoDB Plugin but not the
+        built-in InnoDB, or vice versa.
+      </para>
 
     </def>
+    <gseealso glosid="innodb" />
     <gseealso glosid="plugin" />
 
   </glossent>

@@ -4425,18 +4437,25 @@
     <def>
 
       <para>
-        While the InnoDB storage engine is included with the MySQL
-        database, it is also separately installable as a plugin. The
-        InnoDB Plugin offers performance and functional enhancements
-        over the built-in InnoDB storage engine in MySQL. The plugin can
-        replace the built-in InnoDB storage engine, and can be upgraded
-        independently of the full database server. The flexibility to
-        upgrade can help to roll out performance improvements and new
-        features with less migration and testing effort than switching
-        to a whole new database release.
+        In MySQL 5.1 and earlier, a separately installable form of the
+        InnoDB storage engine that includes features and performance
+        enhancements not included in the
+        <emphasis role="bold">built-in</emphasis> InnoDB for those
+        releases.
       </para>
+      <para>
+        For MySQL 5.5 and higher, the MySQL distribution includes the
+        very latest InnoDB features and performance enhancements, known
+        as InnoDB 1.1, and there is no longer a separate InnoDB Plugin.
+      </para>
+      <para>
+        This distinction is important mainly in MySQL 5.1, where a
+        feature or bug fix might apply to the InnoDB Plugin but not the
+        built-in InnoDB, or vice versa.
+      </para>
 
     </def>
+    <gseealso glosid="innodb" />
     <gseealso glosid="built_in" />
 
   </glossent>