List:Commits« Previous MessageNext Message »
From:john.russell Date:April 6 2011 5:43pm
Subject:svn commit - mysqldoc@oter02: r25767 - trunk/refman-5.6
View as plain text  
Author: jdrussel
Date: 2011-04-06 19:43:29 +0200 (Wed, 06 Apr 2011)
New Revision: 25767

Log:
Taking out redundant links to the InnoDB section (role="se") from inside that section.
Don't need that to be the default way to refer to InnoDB, just once per section
where the reader might be unfamiliar with InnoDB.


Modified:
   trunk/refman-5.6/se-innodb-core.xml


Modified: trunk/refman-5.6/se-innodb-core.xml
===================================================================
--- trunk/refman-5.6/se-innodb-core.xml	2011-04-06 17:35:12 UTC (rev 25766)
+++ trunk/refman-5.6/se-innodb-core.xml	2011-04-06 17:43:29 UTC (rev 25767)
Changed blocks: 16, Lines Added: 57, Lines Deleted: 64; 12233 bytes

@@ -1218,7 +1218,7 @@
         <option role="mysqld" condition="innodb">--skip-innodb</option>
         option to disable the <literal>InnoDB</literal> storage engine.
         In this case, the server will not start if the default storage
-        engine is set to <literal role="se">InnoDB</literal>. Use
+        engine is set to <literal>InnoDB</literal>. Use
         <option role="mysqld">--default-storage-engine</option> to set
         the default to some other engine if necessary.
       </para>

@@ -3464,8 +3464,8 @@
             directory, edit <filename>my.cnf</filename> to change the
             log file configuration, and start the MySQL server again.
             <command>mysqld</command> sees that no
-            <literal role="se">InnoDB</literal> log files exist at
-            startup and creates new ones.
+            <literal>InnoDB</literal> log files exist at startup and
+            creates new ones.
           </para>
         </listitem>
 

@@ -3583,8 +3583,7 @@
 
 <!-- JDR: opportunity to integrate better, reuse text or link back and forth, with MEB documentation -->
 
-      <title>Backing Up and Recovering an <literal role="se">InnoDB</literal>
-        Database</title>
+      <title>Backing Up and Recovering an <literal>InnoDB</literal> Database</title>
 
       <indexterm>
         <primary>InnoDB</primary>

@@ -3608,20 +3607,19 @@
 
       <para>
         <command>MySQL Enterprise Backup</command> enables you to back
-        up a running MySQL database, including
-        <literal role="se">InnoDB</literal> and
-        <literal role="se">MyISAM</literal> tables, with minimal
+        up a running MySQL database, including <literal>InnoDB</literal>
+        and <literal role="se">MyISAM</literal> tables, with minimal
         disruption to operations while producing a consistent snapshot
         of the database. When <command>MySQL Enterprise Backup</command>
-        is copying <literal role="se">InnoDB</literal> tables, reads and
-        writes to both <literal role="se">InnoDB</literal> and
+        is copying <literal>InnoDB</literal> tables, reads and writes to
+        both <literal>InnoDB</literal> and
         <literal role="se">MyISAM</literal> tables can continue. During
-        the copying of <literal role="se">MyISAM</literal> tables, reads
-        (but not writes) to those tables are permitted. In addition,
+        the copying of <literal>MyISAM</literal> tables, reads (but not
+        writes) to those tables are permitted. In addition,
         <command>MySQL Enterprise Backup</command> supports creating
         compressed backup files, and performing backups of subsets of
-        <literal role="se">InnoDB</literal> tables. In conjunction with
-        MySQL’s binary log, users can perform point-in-time recovery.
+        <literal>InnoDB</literal> tables. In conjunction with MySQL’s
+        binary log, users can perform point-in-time recovery.
         <command>MySQL Enterprise Backup</command> is part of the MySQL
         Enterprise subscription. For a more complete description of
         <command>MySQL Enterprise Backup</command>, see

@@ -3637,8 +3635,8 @@
       <para>
         If you can shut down your MySQL server, you can make a binary
         backup that consists of all files used by
-        <literal role="se">InnoDB</literal> to manage its tables. Use
-        the following procedure:
+        <literal>InnoDB</literal> to manage its tables. Use the
+        following procedure:
       </para>
 
       <orderedlist>

@@ -3652,7 +3650,7 @@
 
         <listitem>
           <para>
-            Copy all <literal role="se">InnoDB</literal> data files
+            Copy all <literal>InnoDB</literal> data files
             (<filename>ibdata</filename> files and
             <filename>.ibd</filename> files) into a safe place.
           </para>

@@ -3661,13 +3659,13 @@
         <listitem>
           <para>
             Copy all the <filename>.frm</filename> files for
-            <literal role="se">InnoDB</literal> tables to a safe place.
+            <literal>InnoDB</literal> tables to a safe place.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Copy all <literal role="se">InnoDB</literal> log files
+            Copy all <literal>InnoDB</literal> log files
             (<filename>ib_logfile</filename> files) to a safe place.
           </para>
         </listitem>

@@ -3700,10 +3698,9 @@
       </para>
 
       <para>
-        Replication works with <literal role="se">InnoDB</literal>
-        tables, so you can use MySQL replication capabilities to keep a
-        copy of your database at database sites requiring high
-        availability.
+        Replication works with <literal>InnoDB</literal> tables, so you
+        can use MySQL replication capabilities to keep a copy of your
+        database at database sites requiring high availability.
       </para>
 
       <bridgehead>

@@ -3711,24 +3708,22 @@
       </bridgehead>
 
       <para>
-        To be able to recover your <literal role="se">InnoDB</literal>
-        database to the present from the time at which the binary backup
-        was made, you must run your MySQL server with binary logging
-        turned on. To achieve point-in-time recovery after restoring a
-        backup, you can apply changes from the binary log that occurred
-        after the backup was made. See
-        <xref linkend="point-in-time-recovery"/>.
+        To be able to recover your <literal>InnoDB</literal> database to
+        the present from the time at which the binary backup was made,
+        you must run your MySQL server with binary logging turned on. To
+        achieve point-in-time recovery after restoring a backup, you can
+        apply changes from the binary log that occurred after the backup
+        was made. See <xref linkend="point-in-time-recovery"/>.
       </para>
 
       <para>
         To recover from a crash of your MySQL server, the only
-        requirement is to restart it.
-        <literal role="se">InnoDB</literal> automatically checks the
-        logs and performs a roll-forward of the database to the present.
-        <literal role="se">InnoDB</literal> automatically rolls back
-        uncommitted transactions that were present at the time of the
-        crash. During recovery, <command>mysqld</command> displays
-        output something like this:
+        requirement is to restart it. <literal>InnoDB</literal>
+        automatically checks the logs and performs a roll-forward of the
+        database to the present. <literal>InnoDB</literal> automatically
+        rolls back uncommitted transactions that were present at the
+        time of the crash. During recovery, <command>mysqld</command>
+        displays output something like this:
       </para>
 
 <programlisting>

@@ -5625,7 +5620,7 @@
           Record locks for nonmatching rows are released after MySQL has
           evaluated the <literal>WHERE</literal> condition. For
           <literal>UPDATE</literal> statements,
-          <literal role="se">InnoDB</literal> does a
+          <literal>InnoDB</literal> does a
           <quote>semi-consistent</quote> read, such that it returns the
           latest committed version to MySQL so that MySQL can determine
           whether the row matches the <literal>WHERE</literal> condition

@@ -6687,19 +6682,18 @@
         <note>
           <para>
             Changing the page size is not a supported operation and
-            there is no guarantee that
-            <literal role="se">InnoDB</literal> will function normally
-            with a page size other than 16KB. Problems compiling or
-            running InnoDB may occur. In particular,
+            there is no guarantee that <literal>InnoDB</literal> will
+            function normally with a page size other than 16KB. Problems
+            compiling or running InnoDB may occur. In particular,
             <literal>ROW_FORMAT=COMPRESSED</literal> in the Barracuda
             file format assumes that the page size is at most 16KB and
             uses 14-bit pointers.
           </para>
 
           <para>
-            A version of <literal role="se">InnoDB</literal> built for
-            one page size cannot use data files or log files from a
-            version built for a different page size.
+            A version of <literal>InnoDB</literal> built for one page
+            size cannot use data files or log files from a version built
+            for a different page size.
           </para>
         </note>
 

@@ -9813,8 +9807,8 @@
 
             <listitem>
               <para>
-                Other <literal role="se">InnoDB</literal> options
-                (including <option role="mysqld">--innodb</option> and
+                Other <literal>InnoDB</literal> options (including
+                <option role="mysqld">--innodb</option> and
                 <option role="mysqld" condition="innodb">--skip-innodb</option>)
                 will not be recognized and should not be used.
               </para>

@@ -9823,7 +9817,7 @@
             <listitem>
               <para>
                 The server will not start if the default storage engine
-                is set to <literal role="se">InnoDB</literal>. Use
+                is set to <literal>InnoDB</literal>. Use
                 <option role="mysqld">--default-storage-engine</option>
                 to set the default to some other engine if necessary.
               </para>

@@ -9831,9 +9825,8 @@
 
             <listitem>
               <para>
-                <literal role="se">InnoDB</literal> will not appear in
-                the output of <literal role="stmt">SHOW
-                ENGINES</literal>.
+                <literal>InnoDB</literal> will not appear in the output
+                of <literal role="stmt">SHOW ENGINES</literal>.
               </para>
             </listitem>
 

@@ -9871,8 +9864,7 @@
             or
             <option role="mysqld" condition="innodb">--skip-innodb</option>.
             In this case, the server will not start if the default
-            storage engine is set to
-            <literal role="se">InnoDB</literal>. Use
+            storage engine is set to <literal>InnoDB</literal>. Use
             <option role="mysqld">--default-storage-engine</option> to
             set the default to some other engine if necessary.
           </para>

@@ -10148,17 +10140,18 @@
           <para condition="dynamic:optvar:item" role="5.6:mysqld:innodb_buffer_pool_instances"/>
 
           <para>
-            The number of regions that the
-            <literal role="se">InnoDB</literal> buffer pool is divided
-            into. For systems with buffer pools in the multi-gigabyte
-            range, dividing the buffer pool into separate instances can
-            improve concurrency, by reducing contention as different
-            threads read and write to cached pages. Each page that is
-            stored in or read from the buffer pool is assigned to one of
-            the buffer pool instances randomly, using a hashing
-            function. Each buffer pool manages its own free lists, flush
-            lists, LRUs, and all other data structures connected to a
-            buffer pool, and is protected by its own buffer pool mutex.
+            The number of regions that the <literal>InnoDB</literal>
+            <link linkend="glos_buffer_pool">buffer pool</link> is
+            divided into. For systems with buffer pools in the
+            multi-gigabyte range, dividing the buffer pool into separate
+            instances can improve concurrency, by reducing contention as
+            different threads read and write to cached pages. Each page
+            that is stored in or read from the buffer pool is assigned
+            to one of the buffer pool instances randomly, using a
+            hashing function. Each buffer pool manages its own free
+            lists, flush lists, LRUs, and all other data structures
+            connected to a buffer pool, and is protected by its own
+            buffer pool mutex.
           </para>
 
           <para>


Thread
svn commit - mysqldoc@oter02: r25767 - trunk/refman-5.6john.russell6 Apr