MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:jon.stephens Date:January 5 2011 5:47am
Subject:svn commit - mysqldoc@docsrva: r24641 - in trunk: dynamic-docs/changelog dynamic-docs/command-optvars refman-5.1 refman-5.5 refman-5.6 refman-6.0
View as plain text  
Author: jstephens
Date: 2011-01-05 06:47:25 +0100 (Wed, 05 Jan 2011)
New Revision: 24641

Log:

Documentation for fix of Replication BUG#57275:

  Added changelog entry

  Documented new binlog_stmt_cache_size and max_binlog_stmt_cache_size system variables

  Documented new Binlog_stmt_cache_use and Binlog_stmt_cache_disk_use status variables

  Updated descriptions of binlog_cache_size and max_binlog_cache_size system variables

  Updated descriptions of Binlog_cache_use and Binlog_cache_disk_use status variables

  Various minor wording and formatting fixes/harmonisations, some related, some not




Modified:
   trunk/dynamic-docs/changelog/mysqld-2.xml
   trunk/dynamic-docs/command-optvars/mysqld.xml
   trunk/refman-5.1/replication-options-core.xml
   trunk/refman-5.5/dba-mysqld-server-core.xml
   trunk/refman-5.5/replication-options-core.xml
   trunk/refman-5.6/dba-mysqld-server-core.xml
   trunk/refman-5.6/replication-options-core.xml
   trunk/refman-6.0/dba-mysqld-server-core.xml


Modified: trunk/dynamic-docs/changelog/mysqld-2.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-2.xml	2011-01-05 05:16:32 UTC (rev 24640)
+++ trunk/dynamic-docs/changelog/mysqld-2.xml	2011-01-05 05:47:25 UTC (rev 24641)
Changed blocks: 1, Lines Added: 73, Lines Deleted: 0; 3309 bytes

@@ -10,6 +10,79 @@
 
     <tags>
       <highlight type="replication"/>
+      <manual type="binlog_cache_size"/>
+      <manual type="max_binlog_cache_size"/>
+      <manual type="binlog_stmt_cache_size"/>
+      <manual type="max_binlog_stmt_cache_size"/>
+      <manual type="Binlog_cache_use"/>
+      <manual type="Binlog_cache_disk_use"/>
+      <manual type="Binlog_stmt_cache_use"/>
+      <manual type="Binlog_stmt_cache_disk_use"/>
+    </tags>
+
+    <bugs>
+      <fixes bugid="57275"/>
+      <seealsobug wlid="2687"/>
+    </bugs>
+
+    <versions>
+      <version ver="5.5.9"/>
+      <version ver="5.6.1"/>
+    </versions>
+
+    <message>
+
+      <para>
+        Due to changes made in MySQL 5.5.3, settings made in the
+        <literal role="sysvar">binlog_cache_size</literal> and
+        <literal role="sysvar">max_binlog_cache_size</literal> server
+        system variables affected both the binary log statement cache
+        (also introduced in that version) and the binary log
+        transactional cache (formerly known simply as the binary log
+        cache). This meant that the resources used as a result of
+        setting either or both of these variables were double the amount
+        expected. To rectify this problem, these variables now affect
+        only the transactional cache. The fix for this issue also
+        introduces two new system variables
+        <literal role="sysvar">binlog_stmt_cache_size</literal> and
+        <literal role="sysvar">max_binlog_stmt_cache_size</literal>,
+        which affect only the binary log statement cache.
+      </para>
+
+      <para>
+        In addition, the
+        <literal role="statvar">Binlog_cache_use</literal> status
+        variable was incremented whenever either cache was used, and
+        <literal role="statvar">Binlog_cache_disk_use</literal> was
+        incremented whenever the disk space from either cache was used,
+        which caused problems with performance tuning of the statement
+        and transactional caches, because it was not possible to
+        determine which of these was being exceeeded when attempting to
+        troubleshoot excessive disk seeks and related problems. This
+        issue is solved by changing the behavior of these two status
+        variables such that they are incremented only in response to
+        usage of the binary log transactional cache, as well as by
+        introducing two new status variables
+        <literal role="statvar">Binlog_stmt_cache_use</literal> and
+        <literal role="statvar">Binlog_stmt_cache_disk_use</literal>,
+        which are incremented only by usage of the binary log statement
+        cache.
+      </para>
+
+      <para>
+        For more information, see
+        <xref linkend="replication-sysvars-binlog"/>, and
+        <xref linkend="server-status-variables"/>.
+      </para>
+
+    </message>
+
+  </logentry>
+
+  <logentry entrytype="bug">
+
+    <tags>
+      <highlight type="replication"/>
       <manual type="AUTO_INCREMENT"/>
       <manual type="NO_AUTO_VALUE_ON_ZERO"/>
     </tags>


Modified: trunk/dynamic-docs/command-optvars/mysqld.xml
===================================================================
--- trunk/dynamic-docs/command-optvars/mysqld.xml	2011-01-05 05:16:32 UTC (rev 24640)
+++ trunk/dynamic-docs/command-optvars/mysqld.xml	2011-01-05 05:47:25 UTC (rev 24641)
Changed blocks: 7, Lines Added: 128, Lines Deleted: 4; 5013 bytes

@@ -103,7 +103,7 @@
 
     <shortdescription>
       The number of transactions that used a temporary file instead of
-      the temporary binary log cache
+      the binary log cache
     </shortdescription>
 
     <seealso xref="binlog_cache_size"/>

@@ -127,6 +127,34 @@
 
   </mysqloption>
 
+  <mysqloption section="binlog" id="Binlog_stmt_cache_disk_use">
+
+    <xrefto id="statvar_Binlog_stmt_cache_disk_use"/>
+
+    <name>Binlog_stmt_cache_disk_use</name>
+
+    <shortdescription>
+      The number of nontransactional statements that used a temporary
+      file instead of the binary log statement cache
+    </shortdescription>
+
+    <seealso xref="binlog_stmt_cache_size"/>
+
+    <types>
+      <vartype isdynamic="no" class="status" scope="global"/>
+    </types>
+
+    <values vartype="numeric" platform="all"/>
+
+    <versions>
+      <manual version="5.5"/>
+      <introduced version="5.5.9"/>
+      <manual version="5.6"/>
+      <introduced version="5.6.1"/>
+    </versions>
+
+  </mysqloption>
+
   <mysqloption section="replication" id="have_row_based_replication">
 
     <xrefto id="sysvar_have_row_based_replication"/>

@@ -183,6 +211,34 @@
 
   </mysqloption>
 
+  <mysqloption section="binlog" id="Binlog_stmt_cache_use">
+
+    <xrefto id="statvar_Binlog_stmt_cache_use"/>
+
+    <name>Binlog_stmt_cache_use</name>
+
+    <shortdescription>
+      The number of statements that used the temporary binary log
+      statement cache
+    </shortdescription>
+
+    <seealso xref="Binlog_stmt_cache_disk_use"/>
+
+    <types>
+      <vartype isdynamic="no" class="status" scope="global"/>
+    </types>
+
+    <values vartype="numeric" platform="all"/>
+
+    <versions>
+      <manual version="5.5"/>
+      <introduced version="5.5.9"/>
+      <manual version="5.6"/>
+      <introduced version="5.6.1"/>
+    </versions>
+
+  </mysqloption>
+
   <mysqloption section="server" id="Bytes_received">
 
     <xrefto id="statvar_Bytes_received"/>

@@ -8904,6 +8960,44 @@
 
   </mysqloption>
 
+  <mysqloption section="binlog" id="binlog_stmt_cache_size">
+
+    <xrefto id="sysvar_binlog_stmt_cache_size"/>
+
+    <name>binlog_stmt_cache_size</name>
+
+    <shortdescription>
+      The size of the cache to hold nontransactional statements for the
+      binary log during a transaction
+    </shortdescription>
+
+    <types>
+      <optype class="cmdline" format="--binlog_stmt_cache_size=#" setvar="binlog_stmt_cache_size"/>
+      <optype class="mycnf"/>
+      <vartype class="system" scope="global" isdynamic="yes"/>
+    </types>
+
+    <values vartype="numeric" platform="all" bitsize="32">
+      <value minimum="4096"/>
+      <value maximum="4294967295"/>
+      <value default="32768"/>
+    </values>
+
+    <values vartype="numeric" platform="all" bitsize="64">
+      <value minimum="4096"/>
+      <value maximum="18446744073709547520"/>
+      <value default="32768"/>
+    </values>
+
+    <versions>
+      <manual version="5.5"/>
+      <introduced version="5.5.9"/>
+      <manual version="5.6"/>
+      <introduced version="5.6.1"/>
+    </versions>
+
+  </mysqloption>
+
   <mysqloption section="binlog" subsection="replication" id="binlog-format">
 
     <xrefto id="option_mysqld_binlog-format"/>

@@ -15823,7 +15917,7 @@
 
     <shortdescription>
       Can be used to restrict the total size used to cache a
-      multi-transaction query
+      multi-statement transaction
     </shortdescription>
 
     <types>

@@ -15899,6 +15993,36 @@
 
   </mysqloption>
 
+  <mysqloption section="binlog" id="max_binlog_stmt_cache_size">
+
+    <xrefto id="sysvar_max_binlog_stmt_cache_size"/>
+
+    <name>max_binlog_stmt_cache_size</name>
+
+    <shortdescription>
+      Can be used to restrict the total size used to cache all
+      nontransactional statements during a transaction
+    </shortdescription>
+
+    <types>
+      <optype class="cmdline" format="--max_binlog_stmt_cache_size=#" setvar="max_binlog_stmt_cache_size"/>
+      <optype class="mycnf"/>
+      <vartype isdynamic="yes" class="system" scope="global"/>
+    </types>
+
+    <values vartype="numeric" platform="all">
+      <value default="18446744073709547520" maximum="18446744073709547520" minimum="4096"/>
+    </values>
+
+    <versions>
+      <manual version="5.5"/>
+      <introduced version="5.5.9"/>
+      <manual version="5.6"/>
+      <introduced version="5.6.1"/>
+    </versions>
+
+  </mysqloption>
+
   <mysqloption section="server" id="max_connect_errors">
 
     <xrefto id="sysvar_max_connect_errors"/>

@@ -27582,8 +27706,8 @@
     <name>Innodb_truncated_status_writes</name>
 
     <shortdescription>
-      The number of times output from the <literal>SHOW ENGINE INNODB
-      STATUS</literal> command is truncate
+      The number of times output from the SHOW ENGINE INNODB STATUS
+      command has been truncated
     </shortdescription>
 
     <types>


Modified: trunk/refman-5.1/replication-options-core.xml
===================================================================
--- trunk/refman-5.1/replication-options-core.xml	2011-01-05 05:16:32 UTC (rev 24640)
+++ trunk/refman-5.1/replication-options-core.xml	2011-01-05 05:47:25 UTC (rev 24641)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 0; 821 bytes

@@ -1539,12 +1539,14 @@
           and you issue the following statements on the master, the
           <literal role="stmt">UPDATE</literal> statement is
           <emphasis>not</emphasis> replicated:
+        </para>
 
 <programlisting>
 USE prices;
 UPDATE sales.january SET amount=amount+1000;
 </programlisting>
 
+        <para>
           The main reason for this <quote>check just the default
           database</quote> behavior is that it is difficult from the
           statement alone to know whether it should be replicated (for


Modified: trunk/refman-5.5/dba-mysqld-server-core.xml
===================================================================
--- trunk/refman-5.5/dba-mysqld-server-core.xml	2011-01-05 05:16:32 UTC (rev 24640)
+++ trunk/refman-5.5/dba-mysqld-server-core.xml	2011-01-05 05:47:25 UTC (rev 24641)
Changed blocks: 2, Lines Added: 38, Lines Deleted: 5; 2447 bytes

@@ -11895,11 +11895,21 @@
         </para>
 
         <para>
-          The number of transactions that used the temporary binary log
-          cache but that exceeded the value of
+          The number of transactions that used the binary log cache but
+          that exceeded the value of
           <literal role="sysvar">binlog_cache_size</literal> and used a
-          temporary file to store statements from the transaction.
+          temporary file to store changes from the transaction.
         </para>
+
+        <para>
+          In MySQL versions 5.5.3 through 5.5.8, this variable also
+          included the number of nontransactional statements that caused
+          the binary log transaction cache to be written to disk.
+          Beginning with MySQL 5.5.9, the number of such
+          nontransactional statements is tracked separately in the
+          <literal role="statvar">Binlog_stmt_cache_disk_use</literal>
+          status variable.
+        </para>
       </listitem>
 
       <listitem>

@@ -11908,12 +11918,35 @@
         </para>
 
         <para>
-          The number of transactions that used the temporary binary log
-          cache.
+          The number of transactions that used the binary log cache.
         </para>
       </listitem>
 
       <listitem>
+        <para id="statvar_Binlog_stmt_cache_disk_use">
+          <literal role="statvar">Binlog_stmt_cache_disk_use</literal>
+        </para>
+
+        <para>
+          The number of nontransaction statements that used the binary
+          log statement cache but that exceeded the value of
+          <literal role="sysvar">binlog_stmt_cache_size</literal> and
+          used a temporary file to store those statements.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para id="statvar_Binlog_stmt_cache_use">
+          <literal role="statvar">Binlog_stmt_cache_use</literal>
+        </para>
+
+        <para>
+          The number of nontransactional statements that used the binary
+          log statement cache.
+        </para>
+      </listitem>
+
+      <listitem>
         <para id="statvar_Bytes_received">
           <literal role="statvar">Bytes_received</literal>
         </para>


Modified: trunk/refman-5.5/replication-options-core.xml
===================================================================
--- trunk/refman-5.5/replication-options-core.xml	2011-01-05 05:16:32 UTC (rev 24640)
+++ trunk/refman-5.5/replication-options-core.xml	2011-01-05 05:47:25 UTC (rev 24641)
Changed blocks: 5, Lines Added: 140, Lines Deleted: 14; 9086 bytes

@@ -2806,12 +2806,14 @@
           started with
           <option role="mysqld">--binlog-ignore-db=sales</option> and
           you issue the following statements:
+        </para>
 
 <programlisting>
 USE prices;
 UPDATE sales.january SET amount=amount+1000;
 </programlisting>
 
+        <para>
           The <literal role="stmt">UPDATE</literal> statement
           <emphasis>is</emphasis> logged in such a case because
           <option role="mysqld">--binlog-ignore-db</option> applies only

@@ -2824,9 +2826,8 @@
           are <emphasis>not</emphasis> written to the binary log, which
           means that no changes to the <literal>sales.january</literal>
           table are logged; in this instance,
-          <option
-                role="mysqld">--binlog-ignore-db=sales</option>
-          causes <emphasis>all</emphasis> changes made to tables in the
+          <option role="mysqld">--binlog-ignore-db=sales</option> causes
+          <emphasis>all</emphasis> changes made to tables in the
           master&apos;s copy of the <literal>sales</literal> database to
           be ignored for purposes of binary logging.
         </para>

@@ -2946,18 +2947,36 @@
         <para condition="dynamic:optvar:item" role="5.5:mysqld:binlog_cache_size"/>
 
         <para>
-          The size of the cache to hold the SQL statements for the
-          binary log during a transaction. A binary log cache is
-          allocated for each client if the server supports any
-          transactional storage engines and if the server has the binary
-          log enabled (<option role="mysqld">--log-bin</option> option).
-          If you often use large, multiple-statement transactions, you
-          can increase this cache size to get more performance. The
+          The size of the cache to hold changes to the binary log during
+          a transaction. A binary log cache is allocated for each client
+          if the server supports any transactional storage engines and
+          if the server has the binary log enabled
+          (<option role="mysqld">--log-bin</option> option). If you
+          often use large transactions, you can increase this cache size
+          to get better performance. The
           <literal role="statvar">Binlog_cache_use</literal> and
           <literal role="statvar">Binlog_cache_disk_use</literal> status
           variables can be useful for tuning the size of this variable.
           See <xref linkend="binary-log"/>.
         </para>
+
+        <para>
+          In MySQL 5.5.3, a separate binary log cache (the binary log
+          statement cache) was introduced for nontransactional
+          statements and in MySQL 5.5.3 through 5.5.8, this variable
+          sets.the size for both caches. This means that, in these MySQL
+          versions, the total memory used for these caches is double the
+          value set for <literal>binlog_cache_size</literal>.
+        </para>
+
+        <para>
+          Begining with MySQL 5.5.9,
+          <literal>binlog_cache_size</literal> sets the size for the
+          transaction cache only, and the size of the statement cache is
+          governed by the
+          <literal role="sysvar">binlog_stmt_cache_size</literal> system
+          variable.
+        </para>
       </listitem>
 
       <listitem>

@@ -3182,14 +3201,76 @@
         <para condition="dynamic:optvar:item" role="5.5:mysqld:max_binlog_cache_size"/>
 
         <para>
-          If a multiple-statement transaction requires more than this
-          many bytes of memory, the server generates a
-          <errortext>Multi-statement transaction required more than
-          'max_binlog_cache_size' bytes of storage</errortext> error.
+          If a transaction requires more than this many bytes of memory,
+          the server generates a <errortext>Multi-statement transaction
+          required more than 'max_binlog_cache_size' bytes of
+          storage</errortext> error. The minimum value is 4096. The
+          maximum and default values are 4GB on 32-bit platforms and
+          16PB (petabytes) on 64-bit platforms.
+        </para>
+
+        <para>
+          In MySQL 5.5.3, a separate binary log cache (the binary log
+          statement cache) was introduced for nontransactional
+          statements and in MySQL 5.5.3 through 5.5.8, this variable
+          sets.the upper limit for both caches. This means that, in
+          these MySQL versions, the effective maximum for these caches
+          is double the value set for
+          <literal>max_binlog_cache_size</literal>.
+        </para>
+
+        <para>
+          Begining with MySQL 5.5.9,
+          <literal>max_binlog_cache_size</literal> sets the size for the
+          transaction cache only, and the upper limit for the statement
+          cache is governed by the
+          <literal role="sysvar">max_binlog_stmt_cache_size</literal>
+          system variable.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para id="sysvar_max_binlog_stmt_cache_size">
+          <indexterm>
+            <primary>max_binlog_stmt_cache_size system variable</primary>
+          </indexterm>
+
+          <indexterm>
+            <primary>system variable</primary>
+            <secondary>max_binlog_stmt_cache_size</secondary>
+          </indexterm>
+
+          <literal role="sysvar">max_binlog_stmt_cache_size</literal>
+        </para>
+
+        <para condition="dynamic:optvar:item" role="5.5:mysqld:max_binlog_stmt_cache_size"/>
+
+        <para>
+          If nontransaction statements within a transaction require more
+          than this many bytes of memory, the server generates an error.
           The minimum value is 4096. The maximum and default values are
           4GB on 32-bit platforms and 16PB (petabytes) on 64-bit
           platforms.
         </para>
+
+        <para>
+          In MySQL 5.5.3, a separate binary log cache (the binary log
+          statement cache) was introduced for nontransactional
+          statements and in MySQL 5.5.3 through 5.5.8, this variable
+          sets.the upper limit for both caches. This means that, in
+          these MySQL versions, the effective maximum for these caches
+          is double the value set for
+          <literal role="sysvar">max_binlog_cache_size</literal>.
+        </para>
+
+        <para>
+          Begining with MySQL 5.5.9,
+          <literal>max_binlog_stmt_cache_size</literal> sets the size
+          for the transaction cache only, and the upper limit for the
+          transaction cache is governed exclusively by the
+          <literal role="sysvar">max_binlog_cache_size</literal> system
+          variable.
+        </para>
       </listitem>
 
       <listitem>

@@ -3231,6 +3312,51 @@
       </listitem>
 
       <listitem>
+        <para id="sysvar_binlog_stmt_cache_size">
+          <indexterm>
+            <primary>binlog_stmt_cache_size system variable</primary>
+          </indexterm>
+
+          <indexterm>
+            <primary>system variable</primary>
+            <secondary>binlog_stmt_cache_size</secondary>
+          </indexterm>
+
+          <literal role="sysvar">binlog_stmt_cache_size</literal>
+        </para>
+
+        <para condition="dynamic:optvar:item" role="5.5:mysqld:binlog_stmt_cache_size"/>
+
+        <para>
+          Beginning with MySQL 5.5.9, this variable determines the size
+          of the cache for the binary log to hold nontransactional
+          statements issued during a transaction. In MySQL 5.5.3 and
+          later, separate binary log transaction and statement caches
+          are allocated for each client if the server supports any
+          transactional storage engines and if the server has the binary
+          log enabled (<option role="mysqld">--log-bin</option> option).
+          If you often use large nontransactional statements during
+          transactions, you can increase this cache size to get more
+          performance. The
+          <literal role="statvar">Binlog_stmt_cache_use</literal> and
+          <literal role="statvar">Binlog_stmt_cache_disk_use</literal>
+          status variables can be useful for tuning the size of this
+          variable. See <xref linkend="binary-log"/>.
+        </para>
+
+        <para>
+          In MySQL 5.5.3 through 5.5.8, the size for both caches is set
+          using <literal role="sysvar">binlog_cache_size</literal>. This
+          means that, in these MySQL versions, the total memory used for
+          these caches is double the value set for
+          <literal role="sysvar">binlog_cache_size</literal>. Begining
+          with MySQL 5.5.9,
+          <literal role="sysvar">binlog_cache_size</literal> sets the
+          size for the transaction cache only.
+        </para>
+      </listitem>
+
+      <listitem>
         <para id="sysvar_sync_binlog">
           <indexterm>
             <primary>sync_binlog system variable</primary>


Modified: trunk/refman-5.6/dba-mysqld-server-core.xml
===================================================================
--- trunk/refman-5.6/dba-mysqld-server-core.xml	2011-01-05 05:16:32 UTC (rev 24640)
+++ trunk/refman-5.6/dba-mysqld-server-core.xml	2011-01-05 05:47:25 UTC (rev 24641)
Changed blocks: 3, Lines Added: 34, Lines Deleted: 3; 2465 bytes

@@ -11699,6 +11699,14 @@
           <literal role="sysvar">binlog_cache_size</literal> and used a
           temporary file to store statements from the transaction.
         </para>
+
+        <para>
+          The number of nontransactional statements that caused the
+          binary log transaction cache to be written to disk is tracked
+          separately in the
+          <literal role="statvar">Binlog_stmt_cache_disk_use</literal>
+          status variable.
+        </para>
       </listitem>
 
       <listitem>

@@ -11707,12 +11715,35 @@
         </para>
 
         <para>
-          The number of transactions that used the temporary binary log
-          cache.
+          The number of transactions that used the binary log cache.
         </para>
       </listitem>
 
       <listitem>
+        <para id="statvar_Binlog_stmt_cache_disk_use">
+          <literal role="statvar">Binlog_stmt_cache_disk_use</literal>
+        </para>
+
+        <para>
+          The number of nontransaction statements that used the binary
+          log statement cache but that exceeded the value of
+          <literal role="sysvar">binlog_stmt_cache_size</literal> and
+          used a temporary file to store those statements.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para id="statvar_Binlog_stmt_cache_use">
+          <literal role="statvar">Binlog_stmt_cache_use</literal>
+        </para>
+
+        <para>
+          The number of nontransactional statements that used the binary
+          log statement cache.
+        </para>
+      </listitem>
+
+      <listitem>
         <para id="statvar_Bytes_received">
           <literal role="statvar">Bytes_received</literal>
         </para>

@@ -13145,7 +13176,7 @@
         <para>
           Whether semisynchronous replication currently is operational
           on the master. The value is <literal>ON</literal> if the
-          plugin has been enabled and a commit acknowledgment has not
+          plugin has been enabled and a commit acknowledgment has
           occurred. It is <literal>OFF</literal> if the plugin is not
           enabled or the master has fallen back to asynchronous
           replication due to commit acknowledgment timeout.


Modified: trunk/refman-5.6/replication-options-core.xml
===================================================================
--- trunk/refman-5.6/replication-options-core.xml	2011-01-05 05:16:32 UTC (rev 24640)
+++ trunk/refman-5.6/replication-options-core.xml	2011-01-05 05:47:25 UTC (rev 24641)
Changed blocks: 7, Lines Added: 103, Lines Deleted: 17; 7758 bytes

@@ -1218,12 +1218,14 @@
           and you issue the following statements on the master, the
           <literal role="stmt">UPDATE</literal> statement is
           <emphasis>not</emphasis> replicated:
+        </para>
 
 <programlisting>
 USE prices;
 UPDATE sales.january SET amount=amount+1000;
 </programlisting>
 
+        <para>
           The main reason for this <quote>check just the default
           database</quote> behavior is that it is difficult from the
           statement alone to know whether it should be replicated (for

@@ -2971,9 +2973,8 @@
           are <emphasis>not</emphasis> written to the binary log, which
           means that no changes to the <literal>sales.january</literal>
           table are logged; in this instance,
-          <option
-                role="mysqld">--binlog-ignore-db=sales</option>
-          causes <emphasis>all</emphasis> changes made to tables in the
+          <option role="mysqld">--binlog-ignore-db=sales</option> causes
+          <emphasis>all</emphasis> changes made to tables in the
           master&apos;s copy of the <literal>sales</literal> database to
           be ignored for purposes of binary logging.
         </para>

@@ -3093,18 +3094,26 @@
         <para condition="dynamic:optvar:item" role="5.6:mysqld:binlog_cache_size"/>
 
         <para>
-          The size of the cache to hold the SQL statements for the
-          binary log during a transaction. A binary log cache is
-          allocated for each client if the server supports any
-          transactional storage engines and if the server has the binary
-          log enabled (<option role="mysqld">--log-bin</option> option).
-          If you often use large, multiple-statement transactions, you
-          can increase this cache size to get more performance. The
+          The size of the cache to hold changes to the binary log during
+          a transaction. A binary log cache is allocated for each client
+          if the server supports any transactional storage engines and
+          if the server has the binary log enabled
+          (<option role="mysqld">--log-bin</option> option). If you
+          often use large transactions, you can increase this cache size
+          to get better performance. The
           <literal role="statvar">Binlog_cache_use</literal> and
           <literal role="statvar">Binlog_cache_disk_use</literal> status
           variables can be useful for tuning the size of this variable.
           See <xref linkend="binary-log"/>.
         </para>
+
+        <para>
+          <literal>binlog_cache_size</literal> sets the size for the
+          transaction cache only; the size of the statement cache is
+          governed by the
+          <literal role="sysvar">binlog_stmt_cache_size</literal> system
+          variable.
+        </para>
       </listitem>
 
       <listitem>

@@ -3136,7 +3145,7 @@
         </para>
 
         <para>
-          Beginning with MySQL 5.5.2, the
+          The
           <literal role="sysvar">binlog_direct_non_transactional_updates</literal>
           variable offers one possible workaround to this issue. By
           default, this variable is disabled. Enabling

@@ -3261,8 +3270,7 @@
 
           <listitem>
             <para>
-              Beginning with MySQL 5.5.3, within a transaction.
-              (Bug#47863)
+              From within a transaction.
             </para>
           </listitem>
 

@@ -3329,14 +3337,54 @@
         <para condition="dynamic:optvar:item" role="5.6:mysqld:max_binlog_cache_size"/>
 
         <para>
-          If a multiple-statement transaction requires more than this
-          many bytes of memory, the server generates a
-          <errortext>Multi-statement transaction required more than
-          'max_binlog_cache_size' bytes of storage</errortext> error.
+          If a transaction requires more than this many bytes of memory,
+          the server generates a <errortext>Multi-statement transaction
+          required more than 'max_binlog_cache_size' bytes of
+          storage</errortext> error. The minimum value is 4096. The
+          maximum and default values are 4GB on 32-bit platforms and
+          16PB (petabytes) on 64-bit platforms.
+        </para>
+
+        <para>
+          <literal>max_binlog_cache_size</literal> sets the size for the
+          transaction cache only; the upper limit for the statement
+          cache is governed by the
+          <literal role="sysvar">max_binlog_stmt_cache_size</literal>
+          system variable.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para id="sysvar_max_binlog_stmt_cache_size">
+          <indexterm>
+            <primary>max_binlog_stmt_cache_size system variable</primary>
+          </indexterm>
+
+          <indexterm>
+            <primary>system variable</primary>
+            <secondary>max_binlog_stmt_cache_size</secondary>
+          </indexterm>
+
+          <literal role="sysvar">max_binlog_stmt_cache_size</literal>
+        </para>
+
+        <para condition="dynamic:optvar:item" role="5.6:mysqld:max_binlog_stmt_cache_size"/>
+
+        <para>
+          If nontransaction statements within a transaction require more
+          than this many bytes of memory, the server generates an error.
           The minimum value is 4096. The maximum and default values are
           4GB on 32-bit platforms and 16PB (petabytes) on 64-bit
           platforms.
         </para>
+
+        <para>
+          <literal>max_binlog_stmt_cache_size</literal> sets the size
+          for the transaction cache only; the upper limit for the
+          transaction cache is governed exclusively by the
+          <literal role="sysvar">max_binlog_cache_size</literal> system
+          variable.
+        </para>
       </listitem>
 
       <listitem>

@@ -3378,6 +3426,44 @@
       </listitem>
 
       <listitem>
+        <para id="sysvar_binlog_stmt_cache_size">
+          <indexterm>
+            <primary>binlog_stmt_cache_size system variable</primary>
+          </indexterm>
+
+          <indexterm>
+            <primary>system variable</primary>
+            <secondary>binlog_stmt_cache_size</secondary>
+          </indexterm>
+
+          <literal role="sysvar">binlog_stmt_cache_size</literal>
+        </para>
+
+        <para condition="dynamic:optvar:item" role="5.6:mysqld:binlog_stmt_cache_size"/>
+
+        <para>
+          This variable determines the size of the cache for the binary
+          log to hold nontransactional statements issued during a
+          transaction. Separate binary log transaction and statement
+          caches are allocated for each client if the server supports
+          any transactional storage engines and if the server has the
+          binary log enabled (<option role="mysqld">--log-bin</option>
+          option). If you often use large nontransactional statements
+          during transactions, you can increase this cache size to get
+          more performance. The
+          <literal role="statvar">Binlog_stmt_cache_use</literal> and
+          <literal role="statvar">Binlog_stmt_cache_disk_use</literal>
+          status variables can be useful for tuning the size of this
+          variable. See <xref linkend="binary-log"/>.
+        </para>
+
+        <para>
+          The <literal role="sysvar">binlog_cache_size</literal> system
+          variable sets the size for the transaction cache.
+        </para>
+      </listitem>
+
+      <listitem>
         <para id="sysvar_sync_binlog">
           <indexterm>
             <primary>sync_binlog system variable</primary>


Modified: trunk/refman-6.0/dba-mysqld-server-core.xml
===================================================================
--- trunk/refman-6.0/dba-mysqld-server-core.xml	2011-01-05 05:16:32 UTC (rev 24640)
+++ trunk/refman-6.0/dba-mysqld-server-core.xml	2011-01-05 05:47:25 UTC (rev 24641)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 792 bytes

@@ -14010,7 +14010,7 @@
         <para>
           Whether semisynchronous replication currently is operational
           on the master. The value is <literal>ON</literal> if the
-          plugin has been enabled and a commit acknowledgment has not
+          plugin has been enabled and a commit acknowledgment has
           occurred. It is <literal>OFF</literal> if the plugin is not
           enabled or the master has fallen back to asynchronous
           replication due to commit acknowledgment timeout.


Thread
svn commit - mysqldoc@docsrva: r24641 - in trunk: dynamic-docs/changelog dynamic-docs/command-optvars refman-5.1 refman-5.5 refman-5.6 refman-6.0jon.stephens5 Jan