svn commit - mysqldoc@docsrva: r6345 - trunk/refman-5.1

[jon]

Author: jstephens
Date: 2007-05-05 08:36:37 +0200 (Sat, 05 May 2007)
New Revision: 6345

Log:

Documented fix for Cluster Bug #28161 (Replication / Disk Data)



Modified:
   trunk/refman-5.1/news-5.1.xml


Modified: trunk/refman-5.1/news-5.1.xml
===================================================================
--- trunk/refman-5.1/news-5.1.xml	2007-05-05 06:28:29 UTC (rev 6344)
+++ trunk/refman-5.1/news-5.1.xml	2007-05-05 06:36:37 UTC (rev 6345)
Changed blocks: 2, Lines Added: 12, Lines Deleted: 170; 6849 bytes

@@ -280,6 +280,14 @@
           The patches for Bug #19370 and Bug #21789 were reverted.
         </para>
       </listitem>
+      
+      <listitem>
+        <para>
+          <literal>NDB Cluster</literal> (Cluster Replication / Disk
+          Data): An issue with replication of Disk Data tables could in
+          some cases lead to node failure. (Bug #28161)
+        </para>
+      </listitem>
 
       <listitem>
         <para>

@@ -6040,179 +6048,13 @@
 
         <listitem>
           <para>
-            <emphasis role="bold">Cluster Replication</emphasis>: It was
-            possible for API nodes to begin interacting with the cluster
-            subscription manager before they were fully connected to the
-            cluster. (Bug #27651)
+            <emphasis role="bold">Cluster Replication</emphasis> /
+            <emphasis role="bold">Disk Data</emphasis>: An issue with
+            replication of Disk Data tables could in some cases lead to
+            node failure. (Bug #28161)
           </para>
         </listitem>
 
-        <listitem>
-          <para>
-            <emphasis role="bold">Cluster Replication</emphasis>: Under
-            very high loads, checkpoints could be read or written with
-            checkpoint indexes out of order. (Bug #27651)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            <emphasis role="bold">Disk Data</emphasis>: When restarting
-            a data node following the creation of a large number (~200)
-            of Disk Data objects, the cluster could not assign a node ID
-            to the restarting node. (Bug #25741)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            <emphasis role="bold">Disk Data</emphasis>: Changes to a
-            Disk Data table made as part of a transaction could not be
-            seen by the client performing the changes until the
-            transaction had been committed. (Bug #27757)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            An <literal>INSERT</literal> followed a delete
-            <literal>DELETE</literal> on the same
<literal>NDB</literal>
-            table caused a memory leak. (Bug #27756)
-          </para>
-
-          <para>
-            (This bug was introduced by the fix for Bug #20612.)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            <emphasis role="bold">Cluster APIs</emphasis>: An issue with
-            the way in which the
-            <literal>NdbDictionary::Dictionary::listEvents()</literal>
-            method freed resources could sometimes lead to memory
-            corruption. (Bug #27663)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            <emphasis role="bold">Cluster Replication</emphasis>: Trying
-            to replicate a large number of frequent updates with a
-            relatively small relay log
-            (<literal>max-relay-log-size</literal> set to 1M or less)
-            could cause the slave to crash. (Bug #27529)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Under certain rare circumstances, <literal>DROP
-            TABLE</literal> or <literal>TRUNCATE</literal> of an
-            <literal>NDB</literal> table could cause a node failure or
-            forced cluster shutdown. (Bug #27581)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Memory usage of a <command>mysqld</command> process grew
-            even while idle. (Bug #27560)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            A data node failing while another data node was restarting
-            could leave the cluster in an inconsistent state. In certain
-            rare cases, this could lead to a race condition and the
-            eventual forced shutdown of the cluster. (Bug #27466)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            A data node failing while another data node was restarting
-            could leave the cluster in an inconsistent state. In certain
-            rare cases, this could lead to a race condition and the
-            eventual forced shutdown of the cluster. (Bug #27466)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            <command>mysqld</command> could crash shortly after a data
-            node failure following certain DML operations. (Bug #27169)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            <emphasis role="bold">Disk Data</emphasis>: <literal>DROP
-            INDEX</literal> on a Disk Data table did not always move
-            data from memory into the tablespace. (Bug #25877)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            It was not possible to set
-            <literal>LockPagesInMainMemory</literal> equal to
-            <literal>0</literal>. (Bug #27291)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            A race condition could sometimes occur if the node acting as
-            master failed while node IDs were still being allocated
-            during startup. (Bug #27286)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            When a data node was taking over as the master node, a race
-            condition could sometimes occur as the node was assuming
-            responsibility for handling of global checkpoints. (Bug
-            #27283)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            A delete operation using a scan following by an insert using
-            a scan could cause a data node to fail. (Bug #27203)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            The same failed request from an API node could be handled by
-            the cluster multiple times, resulting in reduced
-            performance. (Bug #27087)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            <command>mysqld</command> processes would sometimes crash
-            under high load. (Bug #26825)
-          </para>
-
-          <para>
-            This improves on and replaces the fix for this bug that was
-            made in MySQL 5.1.15-ndb-6.1.5.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            The failure of a data node while restarting could cause
-            other data nodes to hang or crash. (Bug #27003)
-          </para>
-        </listitem>
-
       </itemizedlist>
 
     </section>