List:Commits« Previous MessageNext Message »
From:jon.stephens Date:June 27 2011 1:12pm
Subject:svn commit - mysqldoc@oter02: r26618 - in trunk: refman-5.0 refman-5.1
View as plain text  
Author: js221926
Date: 2011-06-27 15:12:20 +0200 (Mon, 27 Jun 2011)
New Revision: 26618

Log:

Added info from Frazer about Cluster and network latency




Modified:
   trunk/refman-5.0/mysql-cluster-configuration-core.xml
   trunk/refman-5.0/mysql-cluster-overview.xml
   trunk/refman-5.1/mysql-cluster-configuration-core.xml
   trunk/refman-5.1/mysql-cluster-overview.xml


Modified: trunk/refman-5.0/mysql-cluster-configuration-core.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster-configuration-core.xml	2011-06-27 12:26:50 UTC (rev 26617)
+++ trunk/refman-5.0/mysql-cluster-configuration-core.xml	2011-06-27 13:12:20 UTC (rev 26618)
Changed blocks: 2, Lines Added: 10, Lines Deleted: 0; 992 bytes

@@ -3166,6 +3166,11 @@
             quickly. This parameter can be changed during an online
             software upgrade, but only in small increments.
           </para>
+
+          <para>
+            See also
+            <xref linkend="mysql-cluster-network-latency-issues"/>.
+          </para>
         </listitem>
 
         <listitem>

@@ -3197,6 +3202,11 @@
             each data node watches the MySQL servers connected to it,
             independently of all other data nodes.
           </para>
+
+          <para>
+            For more information, see
+            <xref linkend="mysql-cluster-network-latency-issues"/>.
+          </para>
         </listitem>
 
         <listitem>


Modified: trunk/refman-5.0/mysql-cluster-overview.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster-overview.xml	2011-06-27 12:26:50 UTC (rev 26617)
+++ trunk/refman-5.0/mysql-cluster-overview.xml	2011-06-27 13:12:20 UTC (rev 26618)
Changed blocks: 2, Lines Added: 91, Lines Deleted: 7; 5612 bytes

@@ -805,9 +805,9 @@
       commodity hardware and has no unusual requirements in this regard,
       other than for large amounts of RAM, due to the fact that all live
       data storage is done in memory. (It is possible to reduce this
-      requirement using Disk Data tables, which were implemented in
-      MySQL 5.1; however, we do not intend to backport this feature to
-      MySQL &current-series;.) Naturally, multiple and faster CPUs will
+      requirement using Disk Data tables, which are implemented in MySQL
+      5.1; however, we do not intend to backport this feature to MySQL
+      &current-series;.) Naturally, multiple and faster CPUs will
       enhance performance. Memory requirements for other MySQL Cluster
       processes are relatively small.
     </para>

@@ -887,13 +887,97 @@
 
     </itemizedlist>
 
+    <formalpara id="mysql-cluster-network-latency-issues">
+
+      <title>Network communication and latency</title>
+
+      <para>
+        MySQL Cluster requires communication between data nodes and API
+        nodes (including SQL nodes), as well as between data nodes and
+        other data nodes, to execute queries and updates. Communication
+        latency between these processes can directly affect the observed
+        performance and latency of user queries. In addition, to
+        maintain consistency and service despite the silent failure of
+        nodes, MySQL Cluster uses heartbeating and timeout mechanisms
+        which treat an extended loss of communication from a node as
+        node failure. This can lead to reduced redundancy. Recall that,
+        to maintain data consistency, a MySQL Cluster shuts down when
+        the last node in a node group fails. Thus, to avoid increasing
+        the risk of a forced shutdown, breaks in communication between
+        nodes should be avoided wherever possible.
+      </para>
+
+    </formalpara>
+
     <para>
-      It is also possible to use the high-speed Scalable Coherent
-      Interface (SCI) with MySQL Cluster, but this is not a requirement.
-      See <xref linkend="mysql-cluster-interconnects"/>, for more about
-      this protocol and its use with MySQL Cluster.
+      The failure of a data or API node results in the abort of all
+      uncommitted transactions involving the failed node. Data node
+      recovery requires synchronization of the failed notde&apos;s data
+      from a surviving data node, and re-establishment of disk-based
+      redo and checkpoint logs, before the data node returns to service.
+      This recovery can take some time, during which the Cluster
+      operates with reduced redundancy.
     </para>
 
+    <para>
+      Heartbeating relies on timely generation of heartbeat signals by
+      all nodes. This may not be possible if the node is overloaded, has
+      insufficient machine CPU due to sharing with other programs, or is
+      experiencing delays due to swapping. If heartbeat generation is
+      sufficiently delayed, other nodes treat the node that is slow to
+      respond as failed.
+    </para>
+
+    <para>
+      This treatment of a slow node as a failed one may or may not be
+      desireable in some circumstances, depending on the impact of the
+      node&apos;s slowed operation on the rest of the cluster. When
+      setting timeout values such as
+      <literal role="ndbparam:ndbd">HeartbeatIntervalDbDb</literal> and
+      <literal role="ndbparam:ndbd">HeartbeatIntervalDbApi</literal> for
+      MySQL Cluster, care must be taken care to achieve quick detection,
+      failover, and return to service, while avoiding potentially
+      expensive false positives.
+    </para>
+
+    <para>
+      Where communication latencies between data nodes are expected to
+      be higher than would be expected in a LAN environment (on the
+      order of 100 &micro;s), timeout parameters must be increased to
+      ensure that any allowed periods of latency periods are well within
+      configured timeouts. Increasing timeouts in this way has a
+      corresponding effect on the worst-case time to detect failure and
+      therefore time to service recovery.
+    </para>
+
+    <para>
+      LAN environments can typically be configured with stable low
+      latency, and such that they can provide redundancy with fast
+      failover. Individual link failures can be recovered from with
+      minimal and controlled latency visible at the TCP level (where
+      MySQL Cluster normally operates). WAN environments may offer a
+      range of latencies, as well as redundancy with slower failover
+      times. Individual link failures may require route changes to
+      propagate before end-to-end connectivity is restored. At the TCP
+      level this can appear as large latencies on individual channels.
+      The worst-case observed TCP latency in these scenarios is related
+      to the worst-case time for the IP layer to reroute around the
+      failures.
+    </para>
+
+    <formalpara>
+
+      <title>SCI support</title>
+
+      <para>
+        It is also possible to use the high-speed Scalable Coherent
+        Interface (SCI) with MySQL Cluster, but this is not a
+        requirement. See <xref linkend="mysql-cluster-interconnects"/>,
+        for more about this protocol and its use with MySQL Cluster.
+      </para>
+
+    </formalpara>
+
   </section>
 
   <section id="mysql-cluster-development">


Modified: trunk/refman-5.1/mysql-cluster-configuration-core.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-configuration-core.xml	2011-06-27 12:26:50 UTC (rev 26617)
+++ trunk/refman-5.1/mysql-cluster-configuration-core.xml	2011-06-27 13:12:20 UTC (rev 26618)
Changed blocks: 2, Lines Added: 10, Lines Deleted: 0; 961 bytes

@@ -4649,6 +4649,11 @@
             changed during an online software upgrade, but only in small
             increments.
           </para>
+
+          <para>
+            See also
+            <xref linkend="mysql-cluster-network-latency-issues"/>.
+          </para>
         </listitem>
 
         <listitem>

@@ -4681,6 +4686,11 @@
             each data node watches the MySQL servers connected to it,
             independently of all other data nodes.
           </para>
+
+          <para>
+            For more information, see
+            <xref linkend="mysql-cluster-network-latency-issues"/>.
+          </para>
         </listitem>
 
         <listitem>


Modified: trunk/refman-5.1/mysql-cluster-overview.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-overview.xml	2011-06-27 12:26:50 UTC (rev 26617)
+++ trunk/refman-5.1/mysql-cluster-overview.xml	2011-06-27 13:12:20 UTC (rev 26618)
Changed blocks: 1, Lines Added: 88, Lines Deleted: 4; 4838 bytes

@@ -1008,13 +1008,97 @@
 
     </itemizedlist>
 
+    <formalpara id="mysql-cluster-network-latency-issues">
+
+      <title>Network communication and latency</title>
+
+      <para>
+        MySQL Cluster requires communication between data nodes and API
+        nodes (including SQL nodes), as well as between data nodes and
+        other data nodes, to execute queries and updates. Communication
+        latency between these processes can directly affect the observed
+        performance and latency of user queries. In addition, to
+        maintain consistency and service despite the silent failure of
+        nodes, MySQL Cluster uses heartbeating and timeout mechanisms
+        which treat an extended loss of communication from a node as
+        node failure. This can lead to reduced redundancy. Recall that,
+        to maintain data consistency, a MySQL Cluster shuts down when
+        the last node in a node group fails. Thus, to avoid increasing
+        the risk of a forced shutdown, breaks in communication between
+        nodes should be avoided wherever possible.
+      </para>
+
+    </formalpara>
+
     <para>
-      It is also possible to use the high-speed Scalable Coherent
-      Interface (SCI) with MySQL Cluster, but this is not a requirement.
-      See <xref linkend="mysql-cluster-interconnects"/>, for more about
-      this protocol and its use with MySQL Cluster.
+      The failure of a data or API node results in the abort of all
+      uncommitted transactions involving the failed node. Data node
+      recovery requires synchronization of the failed notde&apos;s data
+      from a surviving data node, and re-establishment of disk-based
+      redo and checkpoint logs, before the data node returns to service.
+      This recovery can take some time, during which the Cluster
+      operates with reduced redundancy.
     </para>
 
+    <para>
+      Heartbeating relies on timely generation of heartbeat signals by
+      all nodes. This may not be possible if the node is overloaded, has
+      insufficient machine CPU due to sharing with other programs, or is
+      experiencing delays due to swapping. If heartbeat generation is
+      sufficiently delayed, other nodes treat the node that is slow to
+      respond as failed.
+    </para>
+
+    <para>
+      This treatment of a slow node as a failed one may or may not be
+      desireable in some circumstances, depending on the impact of the
+      node&apos;s slowed operation on the rest of the cluster. When
+      setting timeout values such as
+      <literal role="ndbparam:ndbd">HeartbeatIntervalDbDb</literal> and
+      <literal role="ndbparam:ndbd">HeartbeatIntervalDbApi</literal> for
+      MySQL Cluster, care must be taken care to achieve quick detection,
+      failover, and return to service, while avoiding potentially
+      expensive false positives.
+    </para>
+
+    <para>
+      Where communication latencies between data nodes are expected to
+      be higher than would be expected in a LAN environment (on the
+      order of 100 &micro;s), timeout parameters must be increased to
+      ensure that any allowed periods of latency periods are well within
+      configured timeouts. Increasing timeouts in this way has a
+      corresponding effect on the worst-case time to detect failure and
+      therefore time to service recovery.
+    </para>
+
+    <para>
+      LAN environments can typically be configured with stable low
+      latency, and such that they can provide redundancy with fast
+      failover. Individual link failures can be recovered from with
+      minimal and controlled latency visible at the TCP level (where
+      MySQL Cluster normally operates). WAN environments may offer a
+      range of latencies, as well as redundancy with slower failover
+      times. Individual link failures may require route changes to
+      propagate before end-to-end connectivity is restored. At the TCP
+      level this can appear as large latencies on individual channels.
+      The worst-case observed TCP latency in these scenarios is related
+      to the worst-case time for the IP layer to reroute around the
+      failures.
+    </para>
+
+    <formalpara>
+
+      <title>SCI support</title>
+
+      <para>
+        It is also possible to use the high-speed Scalable Coherent
+        Interface (SCI) with MySQL Cluster, but this is not a
+        requirement. See <xref linkend="mysql-cluster-interconnects"/>,
+        for more about this protocol and its use with MySQL Cluster.
+      </para>
+
+    </formalpara>
+
   </section>
 
   <section id="mysql-cluster-development">


Thread
svn commit - mysqldoc@oter02: r26618 - in trunk: refman-5.0 refman-5.1jon.stephens27 Jun