From: Date: May 5 2007 8:36am
Subject: svn commit - mysqldoc@docsrva: r6345 - trunk/refman-5.1
List-Archive: http://lists.mysql.com/commits/26162
Message-Id: <200705050636.l456acMp000880@docsrva.mysql.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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.
+
+
+
+ NDB Cluster (Cluster Replication / Disk
+ Data): An issue with replication of Disk Data tables could in
+ some cases lead to node failure. (Bug #28161)
+
+
@@ -6040,179 +6048,13 @@
- Cluster Replication: It was
- possible for API nodes to begin interacting with the cluster
- subscription manager before they were fully connected to the
- cluster. (Bug #27651)
+ Cluster Replication /
+ Disk Data: An issue with
+ replication of Disk Data tables could in some cases lead to
+ node failure. (Bug #28161)
-
-
- Cluster Replication: Under
- very high loads, checkpoints could be read or written with
- checkpoint indexes out of order. (Bug #27651)
-
-
-
-
-
- Disk Data: 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)
-
-
-
-
-
- Disk Data: 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)
-
-
-
-
-
- An INSERT followed a delete
- DELETE on the same NDB
- table caused a memory leak. (Bug #27756)
-
-
-
- (This bug was introduced by the fix for Bug #20612.)
-
-
-
-
-
- Cluster APIs: An issue with
- the way in which the
- NdbDictionary::Dictionary::listEvents()
- method freed resources could sometimes lead to memory
- corruption. (Bug #27663)
-
-
-
-
-
- Cluster Replication: Trying
- to replicate a large number of frequent updates with a
- relatively small relay log
- (max-relay-log-size set to 1M or less)
- could cause the slave to crash. (Bug #27529)
-
-
-
-
-
- Under certain rare circumstances, DROP
- TABLE or TRUNCATE of an
- NDB table could cause a node failure or
- forced cluster shutdown. (Bug #27581)
-
-
-
-
-
- Memory usage of a mysqld process grew
- even while idle. (Bug #27560)
-
-
-
-
-
- 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)
-
-
-
-
-
- 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)
-
-
-
-
-
- mysqld could crash shortly after a data
- node failure following certain DML operations. (Bug #27169)
-
-
-
-
-
- Disk Data: DROP
- INDEX on a Disk Data table did not always move
- data from memory into the tablespace. (Bug #25877)
-
-
-
-
-
- It was not possible to set
- LockPagesInMainMemory equal to
- 0. (Bug #27291)
-
-
-
-
-
- A race condition could sometimes occur if the node acting as
- master failed while node IDs were still being allocated
- during startup. (Bug #27286)
-
-
-
-
-
- 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)
-
-
-
-
-
- A delete operation using a scan following by an insert using
- a scan could cause a data node to fail. (Bug #27203)
-
-
-
-
-
- The same failed request from an API node could be handled by
- the cluster multiple times, resulting in reduced
- performance. (Bug #27087)
-
-
-
-
-
- mysqld processes would sometimes crash
- under high load. (Bug #26825)
-
-
-
- This improves on and replaces the fix for this bug that was
- made in MySQL 5.1.15-ndb-6.1.5.
-
-
-
-
-
- The failure of a data node while restarting could cause
- other data nodes to hang or crash. (Bug #27003)
-
-
-