MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:jon Date:October 15 2008 10:47am
Subject:svn commit - mysqldoc@docsrva: r12065 - trunk/refman-5.1
View as plain text  
Author: jstephens
Date: 2008-10-15 12:47:57 +0200 (Wed, 15 Oct 2008)
New Revision: 12065

Log:

Fixes Docs Bug #39995 (Tackar, Tomas och Jonas!)



Modified:
   trunk/refman-5.1/mysql-cluster-configuration.xml
   trunk/refman-5.1/mysql-cluster-limitations.xml
   trunk/refman-5.1/replication-configuration.xml


Modified: trunk/refman-5.1/mysql-cluster-configuration.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-configuration.xml	2008-10-15 09:43:29 UTC (rev 12064)
+++ trunk/refman-5.1/mysql-cluster-configuration.xml	2008-10-15 10:47:57 UTC (rev 12065)
Changed blocks: 3, Lines Added: 21, Lines Deleted: 7; 2427 bytes

@@ -964,7 +964,8 @@
             Each node in the cluster has a unique identity, which is
             represented by an integer value in the range 1 to 63
             inclusive. This ID is used by all internal cluster messages
-            for addressing the node.
+            for addressing the node, and so must be unique for each
+            MySQL Cluster node, regardless of the type of node.
           </para>
         </listitem>
 

@@ -1331,8 +1332,8 @@
           <para>
             This is the node ID used as the address of the node for all
             cluster internal messages. For data nodes, this is an
-            integer in the range 1 to 49 inclusive. Each node in the
-            cluster must have a unique identity.
+            integer in the range 1 to 48 inclusive. Each node in the
+            cluster must have a unique identifier.
           </para>
         </listitem>
 

@@ -4617,11 +4618,24 @@
           </para>
 
           <para>
-            The <literal>Id</literal> value is used to identify the node
-            in all cluster internal messages. It must be an integer in
-            the range 1 to 63 inclusive, and must be unique among all
-            node IDs within the cluster.
+            The <literal>Id</literal> is an integer value used to
+            identify the node in all cluster internal messages. Prior to
+            MySQL Cluster NDB 6.1.1, the permitted range of values for
+            this parameter was 1 to 63 inclusive. Beginning with MySQL
+            Cluster NDB 6.1.1, the permitted range is 1 to 255
+            inclusive. This value must be unique for each node in the
+            cluster, regardless of the type of node.
           </para>
+
+          <note>
+            <para>
+              Data node IDs must be less than 49, regardless of the
+              MySQL Cluster version used. If you plan to deploy a large
+              number of data nodes, it is a good idea to limit the node
+              IDs for API nodes (and management nodes) to values in the
+              range 49 to 255, inclusive.
+            </para>
+          </note>
         </listitem>
 
         <listitem>


Modified: trunk/refman-5.1/mysql-cluster-limitations.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-limitations.xml	2008-10-15 09:43:29 UTC (rev 12064)
+++ trunk/refman-5.1/mysql-cluster-limitations.xml	2008-10-15 10:47:57 UTC (rev 12065)
Changed blocks: 3, Lines Added: 34, Lines Deleted: 20; 4458 bytes

@@ -522,28 +522,40 @@
 
                           <para>
                             A data node must have a node ID in the range
-                            of 1&dash;49, inclusive. (Management and API
-                            nodes may use any integer in the range of
-                            1&dash;63 inclusive as a node ID.)
+                            of 1 to 48, inclusive. (Previous to MySQL
+                            Cluster NDB 6.1.1, management and API nodes
+                            were restricted to the range 1 to 63
+                            inclusive as a node ID; starting with MySQL
+                            Cluster NDB 6.1.1, management and API nodes
+                            may use node IDs in the range 1 to 255,
+                            inclusive.)
                           </para>
                         </listitem>
 
                         <listitem>
                           <para>
-                            The total maximum number of nodes in a MySQL
-                            Cluster is 63. This number includes all SQL
-                            nodes (MySQL Servers), API nodes
-                            (applications accessing the cluster other
-                            than MySQL servers), data nodes, and
-                            management servers.
+                            Prior to MySQL Cluster NDB 6.1.1, the total
+                            maximum number of nodes in a MySQL Cluster
+                            was 63. Beginning with MySQL Cluster NDB
+                            6.1.1, the total maximum number of nodes in
+                            a MySQL Cluster is 255. In either case, this
+                            number includes all SQL nodes (MySQL
+                            Servers), API nodes (applications accessing
+                            the cluster other than MySQL servers), data
+                            nodes, and management servers.
                           </para>
                         </listitem>
 
                         <listitem>
+                          <remark role="NOTE">
+                            [js] Value of MAX_TABLES in
+                            storage/ndb/include/kernel/ndb_limits.h
+                          </remark>
+
                           <para>
                             The maximum number of metadata objects in
-                            current versions of MySQL Cluster. This
-                            limit is hard-coded.
+                            current versions of MySQL Cluster is 20320.
+                            This limit is hard-coded.
                           </para>
                         </listitem>
 

@@ -1754,10 +1766,10 @@
 
         <listitem>
           <para>
-            In MySQL 5.1, it is no longer necessary, when running
-            multiple management servers, to restart all the cluster's
-            data nodes to enable the management nodes to see one
-            another.
+            In MySQL 5.1 (including all MySQL Cluster NDB 6.x versions),
+            it is no longer necessary, when running multiple management
+            servers, to restart all the cluster&apos;s data nodes to
+            enable the management nodes to see one another.
           </para>
         </listitem>
 

@@ -1845,11 +1857,13 @@
           </formalpara>
 
           <para>
-            Starting with MySQL Cluster NDB 6.1.1, up to 255 API nodes
-            (including MySQL servers acting as cluster SQL nodes) are
-            supported by a single cluster. The total number of data
-            nodes and management nodes beginning with this version is
-            63, of which up to 48 can be data nodes.
+            Starting with MySQL Cluster NDB 6.1.1, the total maximum
+            number of nodes in a MySQL Cluster is 255, including all SQL
+            nodes (MySQL Servers), API nodes (applications accessing the
+            cluster other than MySQL servers), data nodes, and
+            management servers. The total number of data nodes and
+            management nodes beginning with this version is 63, of which
+            up to 48 can be data nodes.
           </para>
 
           <note>


Modified: trunk/refman-5.1/replication-configuration.xml
===================================================================
--- trunk/refman-5.1/replication-configuration.xml	2008-10-15 09:43:29 UTC (rev 12064)
+++ trunk/refman-5.1/replication-configuration.xml	2008-10-15 10:47:57 UTC (rev 12065)
Changed blocks: 1, Lines Added: 4, Lines Deleted: 5; 1152 bytes

@@ -1914,11 +1914,10 @@
         Using row-based logging or replication, rather than
         statement-based logging or replication, can result in major
         changes in the replication environment and in the behavior of
-        applications. This section describes a number of issues and
-        limitations known to exist when using row-based logging or
-        row-based replication. In addition, this section also discusses
-        some best practices for taking advantage of row-based logging
-        (RBL) and row-based replication (RBR).
+        applications. This section discusses a number of issues that may be
+        encountered when using row-based logging or
+        row-based replication, as well as some some best practices for taking
+        advantage of row-based logging (RBL) and row-based replication (RBR).
       </para>
 
       <para>


Thread
svn commit - mysqldoc@docsrva: r12065 - trunk/refman-5.1jon15 Oct