svn commit - mysqldoc@docsrva: r5797 - in trunk: refman-5.0 refman-5.1

[jon]

Author: jstephens
Date: 2007-04-10 15:16:53 +0200 (Tue, 10 Apr 2007)
New Revision: 5797

Log:

Documented Cluster bugfixes (mailine):

  Disk Data: Bug #24521, Bug #25875
  Replication: Bug #21494, Bug #27529
  APIs: Bug #27081, Bug #27663

Documented WL #3464 (Gap Event For Replication)



Modified:
   trunk/refman-5.0/releasenotes-es-5.0.xml
   trunk/refman-5.1/mysql-cluster.xml
   trunk/refman-5.1/news-5.1.xml


Modified: trunk/refman-5.0/releasenotes-es-5.0.xml
===================================================================
--- trunk/refman-5.0/releasenotes-es-5.0.xml	2007-04-10 13:06:12 UTC (rev 5796)
+++ trunk/refman-5.0/releasenotes-es-5.0.xml	2007-04-10 13:16:53 UTC (rev 5797)
Changed blocks: 1, Lines Added: 10, Lines Deleted: 0; 897 bytes

@@ -126,6 +126,16 @@
       
       <listitem>
         <para>
+          <literal>NDB Cluster</literal> (APIs): Using
+          <literal>NdbBlob::writeData()</literal> to write data in the
+          middle of an existing blob value (that is, updating the value)
+          could overwrite some data past the end of the data to be
+          changed. (Bug #27018)
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
           <literal>NDB Cluster</literal>: Under certain rare
           circumstances, <literal>DROP TABLE</literal> or
           <literal>TRUNCATE</literal> of an
<literal>NDB</literal> table


Modified: trunk/refman-5.1/mysql-cluster.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster.xml	2007-04-10 13:06:12 UTC (rev 5796)
+++ trunk/refman-5.1/mysql-cluster.xml	2007-04-10 13:16:53 UTC (rev 5797)
Changed blocks: 1, Lines Added: 27, Lines Deleted: 16; 3073 bytes

@@ -17127,32 +17127,43 @@
 
         <listitem>
           <para>
-            A MySQL Cluster replication slave <command>mysqld</command>
-            has no way of detecting that the connection from the master
-            has been interrupted, and no buffering of the log takes
-            place. For this reason, if a problem such as the master
-            going down or a network failure occurring, then it is
-            possible for the slave to become inconsistent with the
-            master.
+            Prior to MySQL 5.1.18, a MySQL Cluster replication slave
+            <command>mysqld</command> had no way of detecting that the
+            connection from the master had been interrupted (due to, for
+            instance, the master going down or a network failure). For
+            this reason, it was possible for the slave to become
+            inconsistent with the master.
           </para>
 
           <para>
-            To guard against this possibility, it is advisable to set up
-            multiple replication lines, to monitor the master
+            (If high availability is a requirement for the slave server
+            or cluster, then it is still advisable to set up multiple
+            replication lines, to monitor the master
             <command>mysqld</command> on the primary replication line,
             and to fail over to a secondary line if and as necessary.
-          </para>
-
-          <para>
             For information about implementing this type of setup, see
             <xref linkend="mysql-cluster-replication-two-channels"/>,
-            and <xref linkend="mysql-cluster-replication-failover"/>.
+            and <xref linkend="mysql-cluster-replication-failover"/>.)
           </para>
 
           <para>
-            We are working on an integrated solution to this problem for
-            inclusion in a future MySQL Cluster release. (See the
-            discussion of this issue in Bug #21494.)
+            Beginning with MySQL 5.1.18, the master issues a
+            <quote>gap</quote> event when connecting to the cluster.
+            When the slave encounters a gap in the replication log, it
+            stops with an error message. This message is available in
+            the output of <literal>SHOW SLAVE STATUS</literal>, and
+            indicates that the SQL thread has stopped due to an incident
+            registered in the replication stream, and that manual
+            intervention is required. In order to restart the slave, it
+            is necessary to issue the following commands:
+
+<programlisting>
+SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
+START SLAVE; 
+</programlisting>            
+            
+            The slave then resumes reading the master binlog from the
+            point where the gap was recorded.
           </para>
         </listitem>
 


Modified: trunk/refman-5.1/news-5.1.xml
===================================================================
--- trunk/refman-5.1/news-5.1.xml	2007-04-10 13:06:12 UTC (rev 5796)
+++ trunk/refman-5.1/news-5.1.xml	2007-04-10 13:16:53 UTC (rev 5797)
Changed blocks: 1, Lines Added: 46, Lines Deleted: 0; 2197 bytes

@@ -133,6 +133,52 @@
       
       <listitem>
         <para>
+          <literal>NDB Cluster</literal> (APIs): Using
+          <literal>NdbBlob::writeData()</literal> to write data in the
+          middle of an existing blob value (that is, updating the value)
+          could overwrite some data past the end of the data to be
+          changed. (Bug #27018)
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
+          <literal>NDB Cluster</literal> (Replication): 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>
+          <literal>NDB Cluster</literal> (Replication): An SQL node
+          acting as a replication master server could be a single point
+          of failure; that is, if it failed, the replication slave had
+          no way of knowing this, which could result in a mismatch of
+          data between the master and the slave. (Bug #21494) 
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
+          <literal>NDB Cluster</literal> (Disk Data): <literal>CREATE
+            TABLE ... LIKE
+            <replaceable>disk_data_table</replaceable></literal>
created
+          an in-memory <literal>NDB</literal> table. (Bug #25875)
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
+          <literal>NDB Cluster</literal> (Disk Data): Creating an
+          excessive number of data files for a single tablespace caused
+          data nodes to crash. (Bug #24521)
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
           <literal>NDB Cluster</literal>: Under certain rare
           circumstances, <literal>DROP TABLE</literal> or
           <literal>TRUNCATE</literal> of an
<literal>NDB</literal> table