List:Commits« Previous MessageNext Message »
From:paul.dubois Date:May 3 2010 10:40pm
Subject:svn commit - mysqldoc@docsrva: r20401 - in trunk: . refman-6.0
View as plain text  
Author: paul
Date: 2010-05-04 00:40:26 +0200 (Tue, 04 May 2010)
New Revision: 20401

Log:
 r58524@frost:  paul | 2010-05-03 17:38:47 -0500
 Fix validation error


Modified:
   trunk/refman-6.0/replication-notes.xml

Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:38723
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:58522
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
   + 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:38723
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:58524
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546


Modified: trunk/refman-6.0/replication-notes.xml
===================================================================
--- trunk/refman-6.0/replication-notes.xml	2010-05-03 19:40:22 UTC (rev 20400)
+++ trunk/refman-6.0/replication-notes.xml	2010-05-03 22:40:26 UTC (rev 20401)
Changed blocks: 1, Lines Added: 110, Lines Deleted: 107; 11687 bytes

@@ -2659,131 +2659,134 @@
       <indexterm>
         <primary>transactions</primary>
         <secondary>and replication</secondary>
-        <formalpara>
+      </indexterm>
 
-          <title>Mixing transactional and nontransactional statements within the same
-            transaction</title>
+      <formalpara>
 
-          <para>
-            In general, you should avoid transactions that update both
-            transactional and nontransactional tables in a replication
-            environment. You should also avoid using any statement that
-            reads from both transactional and nontransactional tables
-            and writes to any of them.
-          </para>
+        <title>Mixing transactional and nontransactional statements within the same
+          transaction</title>
 
-        </formalpara>
         <para>
-          The semantics of mixing nontransactional and transactional
-          tables in a transaction in the first statement of a
-          transaction changed in MySQL 6.0.10. Previously, if the first
-          statement in a transaction contained nontransactional changes,
-          the statement was written directly to the binary log, in an
-          attempt to mimic the nontransactional behavior of the
-          statement. Beginning with MySQL 6.0.10, any statement
-          appearing after a
-          <literal role="stmt" condition="commit">BEGIN</literal> is
-          always considered part of the transaction and cached. This
-          means that nontransactional changes do not propagate to the
-          slave until the transaction is committed and thus written to
-          the binary log. In addition (also beginning with MySQL
-          5.1.31), if <literal role="sysvar">autocommit</literal> is set
-          to 0, any statement appearing immediately following a
-          <literal role="stmt">COMMIT</literal> is handled in the same
-          way.
+          In general, you should avoid transactions that update both
+          transactional and nontransactional tables in a replication
+          environment. You should also avoid using any statement that
+          reads from both transactional and nontransactional tables and
+          writes to any of them.
         </para>
-        <para>
-          Previously, a statement was considered nontransactional if it
-          changed a nontransactional table. This behavior had the
-          following subtle but nontrivial consequences:
-        </para>
-        <itemizedlist>
 
-          <listitem>
-            <para>
-              A statement containing only nontransactional changes was
-              written immediately to the binary log (sometime referred
-              to as <quote>write-ahead</quote>).
-            </para>
-          </listitem>
+      </formalpara>
 
-          <listitem>
-            <para>
-              A statement containing only transactional changes was
-              always cached while waiting for the transaction to be
-              committed.
-            </para>
-          </listitem>
+      <para>
+        The semantics of mixing nontransactional and transactional
+        tables in a transaction in the first statement of a transaction
+        changed in MySQL 6.0.10. Previously, if the first statement in a
+        transaction contained nontransactional changes, the statement
+        was written directly to the binary log, in an attempt to mimic
+        the nontransactional behavior of the statement. Beginning with
+        MySQL 6.0.10, any statement appearing after a
+        <literal role="stmt" condition="commit">BEGIN</literal> is
+        always considered part of the transaction and cached. This means
+        that nontransactional changes do not propagate to the slave
+        until the transaction is committed and thus written to the
+        binary log. In addition (also beginning with MySQL 5.1.31), if
+        <literal role="sysvar">autocommit</literal> is set to 0, any
+        statement appearing immediately following a
+        <literal role="stmt">COMMIT</literal> is handled in the same
+        way.
+      </para>
 
-          <listitem>
-            <para>
-              A statement containing a mix of transactional and
-              nontransactional changes (that is, a statement updating
-              both transaction and nontransactional tables) could lead
-              to mismatched tables on the master and the slave.
-            </para>
-          </listitem>
+      <para>
+        Previously, a statement was considered nontransactional if it
+        changed a nontransactional table. This behavior had the
+        following subtle but nontrivial consequences:
+      </para>
 
-        </itemizedlist>
-        <para>
-          In situations where transactions mix updates to transactional
-          and nontransactional tables, the order of statements in the
-          binary log is correct, and all needed statements are written
-          to the binary log even in case of a
-          <literal role="stmt" condition="commit">ROLLBACK</literal>.
-          However, when a second connection updates the nontransactional
-          table before the first connection's transaction is complete,
-          statements can be logged out of order because the second
-          connection's update is written immediately after it is
-          performed, regardless of the state of the transaction being
-          performed by the first connection.
-        </para>
-        <formalpara>
+      <itemizedlist>
 
-          <title>Using different storage engines on master and slave</title>
+        <listitem>
+          <para>
+            A statement containing only nontransactional changes was
+            written immediately to the binary log (sometime referred to
+            as <quote>write-ahead</quote>).
+          </para>
+        </listitem>
 
+        <listitem>
           <para>
-            It is possible to replicate transactional tables on the
-            master using nontransactional tables on the slave. For
-            example, you can replicate an <literal>InnoDB</literal>
-            master table as a <literal>MyISAM</literal> slave table.
-            However, if you do this, there are problems if the slave is
-            stopped in the middle of a
-            <literal role="stmt" condition="commit">BEGIN</literal> ...
-            <literal role="stmt">COMMIT</literal> block because the
-            slave restarts at the beginning of the
-            <literal role="stmt" condition="commit">BEGIN</literal>
-            block.
+            A statement containing only transactional changes was always
+            cached while waiting for the transaction to be committed.
           </para>
+        </listitem>
 
-        </formalpara>
+        <listitem>
+          <para>
+            A statement containing a mix of transactional and
+            nontransactional changes (that is, a statement updating both
+            transaction and nontransactional tables) could lead to
+            mismatched tables on the master and the slave.
+          </para>
+        </listitem>
+
+      </itemizedlist>
+
+      <para>
+        In situations where transactions mix updates to transactional
+        and nontransactional tables, the order of statements in the
+        binary log is correct, and all needed statements are written to
+        the binary log even in case of a
+        <literal role="stmt" condition="commit">ROLLBACK</literal>.
+        However, when a second connection updates the nontransactional
+        table before the first connection's transaction is complete,
+        statements can be logged out of order because the second
+        connection's update is written immediately after it is
+        performed, regardless of the state of the transaction being
+        performed by the first connection.
+      </para>
+
+      <formalpara>
+
+        <title>Using different storage engines on master and slave</title>
+
         <para>
-          Beginning with MySQL 6.0.10, it is also safe to replicate
-          transactions from <literal role="se">MyISAM</literal> tables
-          on the master to transactional tables &mdash; such as tables
-          that use the <literal role="se">InnoDB</literal> storage
-          engine &mdash; on the slave. In such cases (beginning with
-          MySQL 6.0.10), an
-          <literal role="sysvar" condition="autocommit">AUTOCOMMIT=1</literal>
-          statement issued on the master is replicated, thus enforcing
-          <literal>AUTOCOMMIT</literal> mode on the slave.
+          It is possible to replicate transactional tables on the master
+          using nontransactional tables on the slave. For example, you
+          can replicate an <literal>InnoDB</literal> master table as a
+          <literal>MyISAM</literal> slave table. However, if you do
+          this, there are problems if the slave is stopped in the middle
+          of a <literal role="stmt" condition="commit">BEGIN</literal>
+          ... <literal role="stmt">COMMIT</literal> block because the
+          slave restarts at the beginning of the
+          <literal role="stmt" condition="commit">BEGIN</literal> block.
         </para>
-        <para>
-          When the storage engine type of the slave is nontransactional,
-          transactions on the master that mix updates of transactional
-          and nontransactional tables should be avoided because they can
-          cause inconsistency of the data between the master's
-          transactional table and the slave's nontransactional table.
-          That is, such transactions can lead to master storage
-          engine-specific behavior with the possible effect of
-          replication going out of synchrony. MySQL does not issue a
-          warning about this currently, so extra care should be taken
-          when replicating transactional tables from the master to
-          nontransactional tables on the slaves.
-        </para>
-      </indexterm>
 
+      </formalpara>
+
       <para>
+        Beginning with MySQL 6.0.10, it is also safe to replicate
+        transactions from <literal role="se">MyISAM</literal> tables on
+        the master to transactional tables &mdash; such as tables that
+        use the <literal role="se">InnoDB</literal> storage engine
+        &mdash; on the slave. In such cases (beginning with MySQL
+        6.0.10), an
+        <literal role="sysvar" condition="autocommit">AUTOCOMMIT=1</literal>
+        statement issued on the master is replicated, thus enforcing
+        <literal>AUTOCOMMIT</literal> mode on the slave.
+      </para>
+
+      <para>
+        When the storage engine type of the slave is nontransactional,
+        transactions on the master that mix updates of transactional and
+        nontransactional tables should be avoided because they can cause
+        inconsistency of the data between the master's transactional
+        table and the slave's nontransactional table. That is, such
+        transactions can lead to master storage engine-specific behavior
+        with the possible effect of replication going out of synchrony.
+        MySQL does not issue a warning about this currently, so extra
+        care should be taken when replicating transactional tables from
+        the master to nontransactional tables on the slaves.
+      </para>
+
+      <para>
         Beginning with MySQL 6.0.14, it is no longer possible to change
         <literal role="sysvar">binlog_format</literal> while a
         transaction is in effect. (Bug#47863)


Thread
svn commit - mysqldoc@docsrva: r20401 - in trunk: . refman-6.0paul.dubois4 May