svn commit - mysqldoc@docsrva: r16633 - trunk/dynamic-docs/changelog

[jon.stephens]

Author: jstephens
Date: 2009-09-16 17:45:13 +0200 (Wed, 16 Sep 2009)
New Revision: 16633

Log:

Documented fixes for Replication bugs:

	Bug #44830, Bug #45999



Modified:
   trunk/dynamic-docs/changelog/mysqld-1.xml


Modified: trunk/dynamic-docs/changelog/mysqld-1.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-1.xml	2009-09-16 15:27:46 UTC (rev 16632)
+++ trunk/dynamic-docs/changelog/mysqld-1.xml	2009-09-16 15:45:13 UTC (rev 16633)
Changed blocks: 2, Lines Added: 57, Lines Deleted: 1; 2152 bytes

@@ -9,6 +9,62 @@
   <logentry entrytype="bug">
 
     <tags>
+      <highlight type="replication"/>
+      <manual type="START SLAVE"/>
+    </tags>
+
+    <bugs>
+      <fixes bugid="44830"/>
+    </bugs>
+
+    <versions>
+      <version ver="5.4.4"/>
+    </versions>
+
+    <message>
+
+      <para>
+        <literal role="stmt">START SLAVE</literal> succeeded even if the
+        IO thread did not connect to the master.
+      </para>
+
+    </message>
+
+  </logentry>
+
+  <logentry entrytype="bug">
+
+    <tags>
+      <highlight type="replication"/>
+      <manual type="AUTO_INCREMENT"/>
+    </tags>
+
+    <bugs>
+      <fixes bugid="45999"/>
+    </bugs>
+
+    <versions></versions>
+
+    <message>
+
+      <para>
+        When using row-based replication, importing a dump made with
+        mysqldump and replicating a row with an AUTO_INCREMENT column
+        set to 0, with NO_AUTO_VALUE_ON_ZERO active on the master, the
+        row was inserted successfully on the master; however any setting
+        for NO_AUTO_VALUE_ON_ZERO was ignored on the slave. When the
+        AUTO_INCREMENT column was incremented, this caused replication
+        to fail on the slave due to a duplicate key error. In some cases
+        it could also cause the slave to crash.
+      </para>
+
+    </message>
+
+  </logentry>
+
+  <logentry entrytype="bug">
+
+    <tags>
       <highlight type="partitioning"/>
       <manual type="ALTER TABLE ... REORGANIZE PARTITION"/>
     </tags>

@@ -29,7 +85,7 @@
         When reorganizing partitions, not all affected subpartitions
         were removed prior to renaming. One way in which the issue was
         visible was that attempting to reorganize two partitions into a
-        single partition having the same name as one of the originasl
+        single partition having the same name as one of the original
         partitions could lead to a crash of the server.
       </para>