List:Commits« Previous MessageNext Message »
From:jon.stephens Date:April 29 2011 8:30am
Subject:svn commit - mysqldoc@oter02: r26084 - in trunk: dynamic-docs/changelog refman-5.1
View as plain text  
Author: js221926
Date: 2011-04-29 10:30:05 +0200 (Fri, 29 Apr 2011)
New Revision: 26084

Log:

Cluster Replication BUG#11756082 / BUG#47952 
  - changelog entry
  - update Known Issues
  - add Dev History item



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 07:48:15 UTC (rev 26083)
+++ trunk/dynamic-docs/changelog/mysqld-2.xml	2011-04-29 08:30:05 UTC (rev 26084)
Changed blocks: 1, Lines Added: 31, Lines Deleted: 0; 1213 bytes

@@ -9,6 +9,37 @@
   <logentry entrytype="bug">
 
     <tags>
+      <highlight type="clusterreplication"/>
+      <manual type="known issues"/>
+      <manual type="binary log"/>
+      <manual type="unique keys"/>
+    </tags>
+
+    <bugs>
+      <fixes bugid="47952"/>
+      <fixes bugid="11756082"/>
+    </bugs>
+
+    <versions></versions>
+
+    <message>
+
+      <para>
+        Operations that updated unique keys of
+        <literal role="se">NDB</literal> tables could cause duplicate
+        key errors when trying to execute the binary log. (Previously,
+        row events in the binary log were ordered according to the
+        partitioning of the base table, which could differ in order
+        within the epoch for that in which they were executed.
+      </para>
+
+    </message>
+
+  </logentry>
+
+  <logentry entrytype="bug">
+
+    <tags>
       <highlight type="cluster"/>
       <manual type="errors"/>
       <manual type="START BACKUP"/>


Modified: trunk/refman-5.1/mysql-cluster-overview.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-overview.xml	2011-04-29 07:48:15 UTC (rev 26083)
+++ trunk/refman-5.1/mysql-cluster-overview.xml	2011-04-29 08:30:05 UTC (rev 26084)
Changed blocks: 2, Lines Added: 38, Lines Deleted: 0; 1976 bytes

@@ -2333,6 +2333,25 @@
           </formalpara>
         </listitem>
 
+        <listitem>
+          <formalpara>
+
+            <title>Unique key updates in replication</title>
+
+            <para>
+              It is possible in MySQL Cluster NDB 7.1.14 and later to
+              employ operations that update unique keys when replicating
+              <literal role="se">NDB</literal> tables. Previously this
+              could lead to duplicate key errors when trying to execute
+              the binary log (due to the fact that row events in the
+              binary log were ordered according to the partitioning of
+              the base table, and could differ in order within the epoch
+              for that in which they were executed).
+            </para>
+
+          </formalpara>
+        </listitem>
+
       </itemizedlist>
 
       <para>

@@ -3394,6 +3413,25 @@
           </formalpara>
         </listitem>
 
+        <listitem>
+          <formalpara>
+
+            <title>Unique key updates in replication</title>
+
+            <para>
+              It is possible in MySQL Cluster NDB 7.0.25 and later to
+              employ operations that update unique keys when replicating
+              <literal role="se">NDB</literal> tables. Previously this
+              could lead to duplicate key errors when trying to execute
+              the binary log (due to the fact that row events in the
+              binary log were ordered according to the partitioning of
+              the base table, and could differ in order within the epoch
+              for that in which they were executed).
+            </para>
+
+          </formalpara>
+        </listitem>
+
       </itemizedlist>
 
       <para>


Modified: trunk/refman-5.1/mysql-cluster-replication-core.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-replication-core.xml	2011-04-29 07:48:15 UTC (rev 26083)
+++ trunk/refman-5.1/mysql-cluster-replication-core.xml	2011-04-29 08:30:05 UTC (rev 26084)
Changed blocks: 3, Lines Added: 31, Lines Deleted: 24; 3961 bytes

@@ -638,22 +638,23 @@
               <secondary>and unique keys</secondary>
             </indexterm>
 
-            Operations that update values of unique key columns of
-            <literal role="se">NDB</literal> tables can result in
-            duplicate-key errors when replicated. This is because row
-            events in the binary log are ordered according to the
-            partitioning of the base table, which means that they may
+            Prior to MySQL Cluster NDB 7.0.25 and MySQL Cluster NDB
+            7.1.4, operations that updated values of unique key columns
+            of <literal role="se">NDB</literal> tables could result in
+            duplicate-key errors when replicated. This was due to the
+            ordering of row events in the binary log according to the
+            partitioning of the base table, which meant that they could
             appear in a different order from that in which they were
-            originally executed.
+            originally executed. (Bug #11756082)
           </para>
 
         </formalpara>
 
         <para>
-          Consider an <literal role="se">NDB</literal> table
-          <literal>t</literal> which is created and populated on the
-          master (and replicated to a slave MySQL Cluster) as shown
-          here:
+          In previous releases, this caused problems with
+          <literal role="se">NDB</literal> tables such as
+          <literal>t</literal>, is created and populated on the master
+          (and replicated to a slave MySQL Cluster) as shown here:
         </para>
 
 <programlisting>

@@ -668,11 +669,11 @@
 </programlisting>
 
         <para>
-          The following <literal role="stmt">UPDATE</literal> statement
-          succeeds on the master; on the master, 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:
+          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:
         </para>
 
 <programlisting>

@@ -680,16 +681,22 @@
 </programlisting>
 
         <para>
-          However, the same statement can fail with a constraint
-          violation or duplicate key error on the slave, because the
-          ordering of the row updates is determined on a per-partition
-          basis, rather than for the table as a whole. (Recall that in
-          MySQL 5.1.6 and later&mdash;including all MySQL Cluster NDB
-          6.x and 7.x releases&mdash;every
-          <literal role="se">NDB</literal> table is implicitly
-          partitioned by key when it is created&mdash;see
-          <xref linkend="partitioning-key"/>, for more information).
+          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.
         </para>
+
+        <note>
+          <para>
+            In MySQL 5.1.6 and later, every
+            <literal role="se">NDB</literal> table is implicitly
+            partitioned by key when it is created. This also applies to
+            all MySQL Cluster NDB 6.x and MySQL Cluster NDB 7.x
+            releases. See <xref linkend="partitioning-key"/>, for more
+            information.
+          </para>
+        </note>
       </listitem>
 
       <listitem>


Thread
svn commit - mysqldoc@oter02: r26084 - in trunk: dynamic-docs/changelog refman-5.1jon.stephens29 Apr