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—including all MySQL Cluster NDB
- 6.x and 7.x releases—every
- <literal role="se">NDB</literal> table is implicitly
- partitioned by key when it is created—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.1 | jon.stephens | 29 Apr |
