svn commit - mysqldoc@oter02: r26085 - in trunk: dynamic-docs/changelog refman-5.1

[jon.stephens]

Author: js221926
Date: 2011-04-29 10:54:49 +0200 (Fri, 29 Apr 2011)
New Revision: 26085

Log:

Cluster replication / unique keys -- BUG#11756082 / BUG#47952 (Thanks, Jonas!)



Modified:
   trunk/dynamic-docs/changelog/mysqld-2.xml
   trunk/refman-5.1/mysql-cluster-overview.xml
   trunk/refman-5.1/mysql-cluster-replication-core.xml


Modified: trunk/dynamic-docs/changelog/mysqld-2.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-2.xml	2011-04-29 08:30:05 UTC (rev 26084)
+++ trunk/dynamic-docs/changelog/mysqld-2.xml	2011-04-29 08:54:49 UTC (rev 26085)
Changed blocks: 1, Lines Added: 18, Lines Deleted: 0; 1204 bytes

@@ -33,6 +33,24 @@
         within the epoch for that in which they were executed.
       </para>
 
+      <para>
+        To keep this from happening, unique keys are now updated in
+        deferred mode, meaning that all table rows are updated before
+        any unique indexes are updated. Thus, the order of the row
+        updates is no longer important.
+      </para>
+
+      <para>
+        You should be aware that deferring unique keys in this way is
+        currently supported only by <literal role="se">NDB</literal>,
+        and thus only for replication between NDB tables on both the
+        master and the slave. You cannot replicate updates of unique
+        keys successfully when replicating from
+        <literal role="se">NDB</literal> to a different storage engine
+        such as <literal role="se">MyISAM</literal> or
+        <literal role="se">InnoDB</literal>.
+      </para>
+
     </message>
 
   </logentry>


Modified: trunk/refman-5.1/mysql-cluster-overview.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-overview.xml	2011-04-29 08:30:05 UTC (rev 26084)
+++ trunk/refman-5.1/mysql-cluster-overview.xml	2011-04-29 08:54:49 UTC (rev 26085)
Changed blocks: 2, Lines Added: 16, Lines Deleted: 0; 986 bytes

@@ -2350,6 +2350,14 @@
             </para>
 
           </formalpara>
+
+          <important>
+            <para>
+              Master and slave tables must both be using the
+              <literal role="se">NDB</literal> storage engine for this
+              to work.
+            </para>
+          </important>
         </listitem>
 
       </itemizedlist>

@@ -3430,6 +3438,14 @@
             </para>
 
           </formalpara>
+
+          <important>
+            <para>
+              Master and slave tables must both be using the
+              <literal role="se">NDB</literal> storage engine for this
+              to work.
+            </para>
+          </important>
         </listitem>
 
       </itemizedlist>


Modified: trunk/refman-5.1/mysql-cluster-replication-core.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-replication-core.xml	2011-04-29 08:30:05 UTC (rev 26084)
+++ trunk/refman-5.1/mysql-cluster-replication-core.xml	2011-04-29 08:54:49 UTC (rev 26085)
Changed blocks: 3, Lines Added: 29, Lines Deleted: 10; 2862 bytes

@@ -651,10 +651,29 @@
         </formalpara>
 
         <para>
-          In previous releases, this caused problems with
-          <literal role="se">NDB</literal> tables such as
+          In MySQL Cluster NDB 7.0.25, MySQL Cluster NDB 7.1.14, and
+          later, this issue is solved for replication between
+          <literal role="se">NDB</literal> tables by deferring updates
+          of unique keys until after table row updates have been
+          performed.
+        </para>
+
+        <para>
+          Deferring unique keys in this way is currently supported only
+          by <literal role="se">NDB</literal>. Thus, updates of unique
+          keys when replicating from <literal role="se">NDB</literal> to
+          a different storage engine such as
+          <literal role="se">MyISAM</literal> or
+          <literal role="se">InnoDB</literal> are still not supported.
+        </para>
+
+        <para>
+          The problem encountered when replicating without deferred
+          application of unique key updates can be illustrated using
+          <literal role="se">NDB</literal> table such as
           <literal>t</literal>, is created and populated on the master
-          (and replicated to a slave MySQL Cluster) as shown here:
+          (and replicated to a slave that does not support deferred
+          unique key updates) as shown here:
         </para>
 
 <programlisting>

@@ -669,11 +688,11 @@
 </programlisting>
 
         <para>
-          Prior to MySQL Cluster NDB 7.0.25 and MySQL Cluster NDB 7.1.14
-          the following <literal role="stmt">UPDATE</literal> statement
-          succeeded on the master, since the rows affected are processed
-          in the order determined by the <literal>ORDER BY</literal>
-          clause and the ordering is done over the entire table:
+          The following <literal role="stmt">UPDATE</literal> statement
+          on <literal>t</literal> succeeded on the master, since the
+          rows affected are processed in the order determined by the
+          <literal>ORDER BY</literal> option, performed over the entire
+          table:
         </para>
 
 <programlisting>

@@ -683,8 +702,8 @@
         <para>
           However, the same statement failed with a constraint violation
           or duplicate key error on the slave, because the ordering of
-          the row updates was done for each partition, rather than for
-          the table as a whole.
+          the row updates was done for one partition at a time, rather
+          than for the table as a whole.
         </para>
 
         <note>