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‐49, inclusive. (Management and API
- nodes may use any integer in the range of
- 1‐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'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.1 | jon | 15 Oct |
