Author: jstephens
Date: 2006-05-02 14:29:01 +0200 (Tue, 02 May 2006)
New Revision: 1989
Log:
Rewrite of Cluster Nodes & Replicas section (Mikael et al.)
Modified:
trunk/refman-4.1/ndbcluster.xml
trunk/refman-5.0/ndbcluster.xml
trunk/refman-5.1/ndbcluster.xml
Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml 2006-05-02 12:23:39 UTC (rev 1988)
+++ trunk/refman-4.1/ndbcluster.xml 2006-05-02 12:29:01 UTC (rev 1989)
@@ -374,6 +374,10 @@
Jeb Miller, and Hartmut Holzgraefe
</remark>
+ <remark role="note">
+ Revised with feedback from Mikael Ronström and bug reports
+ </remark>
+
<para>
This section discusses the manner in which MySQL Cluster divides
and duplicates data for storage.
@@ -408,17 +412,18 @@
It is common for the terms <quote>node</quote> and
<quote>data node</quote> to be used interchangeably when
referring to an <command>ndbd</command> process; where
- mentioned, management nodes (<command>ndb_mgmd</command>
- processes) and SQL nodes (<command>mysqld</command>
- processes) are specified as such in this discussion.
+ mentioned, management (MGM) nodes
+ (<command>ndb_mgmd</command> processes) and SQL nodes
+ (<command>mysqld</command> processes) are specified as such
+ in this discussion.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">Node Group</emphasis>: A node group
- consists of one or more nodes, and stores a partition, or
- set of <firstterm>replicas</firstterm> (see next item).
+ consists of one or more nodes, and stores partitions, or
+ sets of <firstterm>replicas</firstterm> (see next item).
</para>
<para>
@@ -431,15 +436,15 @@
<para>
<emphasis role="bold">Partition</emphasis>: This is a
portion of the data stored by the cluster. There are as many
- cluster partitions as node groups participating in the
- cluster, and each node group is responible for keeping at
- least one copy of the partition assigned to it (that is, at
- least one replica) available to the cluster.
+ cluster partitions as nodes participating in the
+ cluster. Each node is responible for keeping at least one
+ copy of any partitions assigned to it (that is, at least one
+ replica) available to the cluster.
</para>
<para>
- A partition belongs entirely to a single node group; a node
- group can store several partitions.
+ A replica belongs entirely to a single node; a node can
+ (and usually does) store several replicas.
</para>
</listitem>
@@ -457,11 +462,13 @@
<para>
The following diagram illustrates a MySQL Cluster with four data
- nodes, arranged in two node groups of two nodes each. Note that
- no nodes other than data nodes are shown here, although a
- working cluster requires an <command>ndb_mgm</command> process
- for cluster management and at least one SQL node to access the
- data stored by the cluster.
+ nodes, arranged in two node groups of two nodes each; nodes 1
+ and 2 belong to node group 0, and nodes 3 and 4 belong to node
+ group 1. Note that only data (<command>ndbd</command>) nodes are
+ shown here; although a working cluster requires an
+ <command>ndb_mgm</command> process for cluster management and at
+ least one SQL node to access the data stored by the cluster,
+ these have been omitted in the figure for clarity.
</para>
<mediaobject>
@@ -475,25 +482,56 @@
</mediaobject>
<para>
- The data stored by the cluster is divided into two partitions,
- labeled <emphasis role="bold">A</emphasis> and
- <emphasis role="bold">B</emphasis> in the diagram. Each
- partition is stored — in multiple copies — on a node
- group. The data making up Partition
- <emphasis role="bold">A</emphasis> is stored on Node
- <emphasis role="bold">A-1</emphasis>, and this data is identical
- to that stored by Node <emphasis role="bold">A-2</emphasis>. The
- data stored by Nodes <emphasis role="bold">B-1</emphasis> and
- <emphasis role="bold">B-2</emphasis> is also the same —
- these two nodes store identical copies of the data making up
- Partition <emphasis role="bold">B</emphasis>.
+ The data stored by the cluster is divided into four partitions,
+ numbered 0, 1, 2, and 3. Each partition is stored — in
+ multiple copies — on the same node group. Partitions are
+ stored on alternate node groups:
+ Partition 2 is stored on .
</para>
-
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Partition 0 is stored on node group 0; a <firstterm>primary
+ replica</firstterm> (primary copy) is stored on node 1,
+ and a <firstterm>backup replica</firstterm> (backup copy of
+ the partition) is stored on node 2.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Partition 1 is stored on the other node group (node group
+ 1); this partition's primary replica is on node 3, and its
+ backup replica is on node 4.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Partition 2 is stored on node group 0. However, the placing
+ of its two replicas is reversed from that of Partition 0;
+ for Partition 2, the primary replica is stored on node 2,
+ and the backup on node 1.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Partition 3 is stored on node group 1, and the placement of
+ its two replicas are reversed from those of partition 1.
+ That is, its primary replica is located on node 4, with the
+ backup on node 3.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+
<para>
What this means so far as the continued operation of a MySQL
Cluster is this: so long as each node group participating in the
- cluster has at least one <quote>live</quote> node, the cluster
- has a complete copy of all data and remains viable. This is
+ cluster has at least one node operating, the cluster has a
+ complete copy of all data and remains viable. This is
illustrated in the next diagram.
</para>
@@ -513,16 +551,15 @@
<para>
In this example, where the cluster consists of two node groups
- of two nodes each, any combination of at least one node in Node
- Group <emphasis role="bold">A</emphasis> and at least one node
- in Node Group <emphasis role="bold">B</emphasis> is sufficient
+ of two nodes each, any combination of at least one node in node
+ group 0 and at least one node in node group 1 is sufficient
to keep the cluster <quote>alive</quote> (indicated by arrows in
- the diagram). However, if both nodes from either node group
- fail, the remaining two nodes are not sufficient (shown by
- arrows marked out with an <emphasis role="bold">X</emphasis>);
- in either case, the cluster has lost an entire partition and so
- can no longer provide access to a complete set of all cluster
- data.
+ the diagram). However, if <emphasis>both</emphasis> nodes from
+ <emphasis>either</emphasis> node group fail, the remaining two
+ nodes are not sufficient (shown by the arrows marked out with an
+ <emphasis role="bold">X</emphasis>); in either case, the cluster
+ has lost an entire partition and so can no longer provide access
+ to a complete set of all cluster data.
</para>
<remark role="todo">
@@ -530,11 +567,6 @@
multiple CPUs.
</remark>
- <remark role="todo">
- [js] Add description of memory requirements based on Hartmut's
- example scripts.
- </remark>
-
</section>
</section>
Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml 2006-05-02 12:23:39 UTC (rev 1988)
+++ trunk/refman-5.0/ndbcluster.xml 2006-05-02 12:29:01 UTC (rev 1989)
@@ -374,6 +374,10 @@
Jeb Miller, and Hartmut Holzgraefe
</remark>
+ <remark role="note">
+ Revised with feedback from Mikael Ronström and bug reports
+ </remark>
+
<para>
This section discusses the manner in which MySQL Cluster divides
and duplicates data for storage.
@@ -408,17 +412,18 @@
It is common for the terms <quote>node</quote> and
<quote>data node</quote> to be used interchangeably when
referring to an <command>ndbd</command> process; where
- mentioned, management nodes (<command>ndb_mgmd</command>
- processes) and SQL nodes (<command>mysqld</command>
- processes) are specified as such in this discussion.
+ mentioned, management (MGM) nodes
+ (<command>ndb_mgmd</command> processes) and SQL nodes
+ (<command>mysqld</command> processes) are specified as such
+ in this discussion.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">Node Group</emphasis>: A node group
- consists of one or more nodes, and stores a partition, or
- set of <firstterm>replicas</firstterm> (see next item).
+ consists of one or more nodes, and stores partitions, or
+ sets of <firstterm>replicas</firstterm> (see next item).
</para>
<para>
@@ -431,15 +436,15 @@
<para>
<emphasis role="bold">Partition</emphasis>: This is a
portion of the data stored by the cluster. There are as many
- cluster partitions as node groups participating in the
- cluster, and each node group is responible for keeping at
- least one copy of the partition assigned to it (that is, at
- least one replica) available to the cluster.
+ cluster partitions as nodes participating in the
+ cluster. Each node is responible for keeping at least one
+ copy of any partitions assigned to it (that is, at least one
+ replica) available to the cluster.
</para>
<para>
- A partition belongs entirely to a single node group; a node
- group can store several partitions.
+ A replica belongs entirely to a single node; a node can
+ (and usually does) store several replicas.
</para>
</listitem>
@@ -457,11 +462,13 @@
<para>
The following diagram illustrates a MySQL Cluster with four data
- nodes, arranged in two node groups of two nodes each. Note that
- no nodes other than data nodes are shown here, although a
- working cluster requires an <command>ndb_mgm</command> process
- for cluster management and at least one SQL node to access the
- data stored by the cluster.
+ nodes, arranged in two node groups of two nodes each; nodes 1
+ and 2 belong to node group 0, and nodes 3 and 4 belong to node
+ group 1. Note that only data (<command>ndbd</command>) nodes are
+ shown here; although a working cluster requires an
+ <command>ndb_mgm</command> process for cluster management and at
+ least one SQL node to access the data stored by the cluster,
+ these have been omitted in the figure for clarity.
</para>
<mediaobject>
@@ -475,25 +482,56 @@
</mediaobject>
<para>
- The data stored by the cluster is divided into two partitions,
- labeled <emphasis role="bold">A</emphasis> and
- <emphasis role="bold">B</emphasis> in the diagram. Each
- partition is stored — in multiple copies — on a node
- group. The data making up Partition
- <emphasis role="bold">A</emphasis> is stored on Node
- <emphasis role="bold">A-1</emphasis>, and this data is identical
- to that stored by Node <emphasis role="bold">A-2</emphasis>. The
- data stored by Nodes <emphasis role="bold">B-1</emphasis> and
- <emphasis role="bold">B-2</emphasis> is also the same —
- these two nodes store identical copies of the data making up
- Partition <emphasis role="bold">B</emphasis>.
+ The data stored by the cluster is divided into four partitions,
+ numbered 0, 1, 2, and 3. Each partition is stored — in
+ multiple copies — on the same node group. Partitions are
+ stored on alternate node groups:
+ Partition 2 is stored on .
</para>
-
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Partition 0 is stored on node group 0; a <firstterm>primary
+ replica</firstterm> (primary copy) is stored on node 1,
+ and a <firstterm>backup replica</firstterm> (backup copy of
+ the partition) is stored on node 2.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Partition 1 is stored on the other node group (node group
+ 1); this partition's primary replica is on node 3, and its
+ backup replica is on node 4.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Partition 2 is stored on node group 0. However, the placing
+ of its two replicas is reversed from that of Partition 0;
+ for Partition 2, the primary replica is stored on node 2,
+ and the backup on node 1.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Partition 3 is stored on node group 1, and the placement of
+ its two replicas are reversed from those of partition 1.
+ That is, its primary replica is located on node 4, with the
+ backup on node 3.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+
<para>
What this means so far as the continued operation of a MySQL
Cluster is this: so long as each node group participating in the
- cluster has at least one <quote>live</quote> node, the cluster
- has a complete copy of all data and remains viable. This is
+ cluster has at least one node operating, the cluster has a
+ complete copy of all data and remains viable. This is
illustrated in the next diagram.
</para>
@@ -513,16 +551,15 @@
<para>
In this example, where the cluster consists of two node groups
- of two nodes each, any combination of at least one node in Node
- Group <emphasis role="bold">A</emphasis> and at least one node
- in Node Group <emphasis role="bold">B</emphasis> is sufficient
+ of two nodes each, any combination of at least one node in node
+ group 0 and at least one node in node group 1 is sufficient
to keep the cluster <quote>alive</quote> (indicated by arrows in
- the diagram). However, if both nodes from either node group
- fail, the remaining two nodes are not sufficient (shown by
- arrows marked out with an <emphasis role="bold">X</emphasis>);
- in either case, the cluster has lost an entire partition and so
- can no longer provide access to a complete set of all cluster
- data.
+ the diagram). However, if <emphasis>both</emphasis> nodes from
+ <emphasis>either</emphasis> node group fail, the remaining two
+ nodes are not sufficient (shown by the arrows marked out with an
+ <emphasis role="bold">X</emphasis>); in either case, the cluster
+ has lost an entire partition and so can no longer provide access
+ to a complete set of all cluster data.
</para>
<remark role="todo">
@@ -530,11 +567,6 @@
multiple CPUs.
</remark>
- <remark role="todo">
- [js] Add description of memory requirements based on Hartmut's
- example scripts.
- </remark>
-
</section>
</section>
Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml 2006-05-02 12:23:39 UTC (rev 1988)
+++ trunk/refman-5.1/ndbcluster.xml 2006-05-02 12:29:01 UTC (rev 1989)
@@ -371,6 +371,10 @@
Jeb Miller, and Hartmut Holzgraefe
</remark>
+ <remark role="note">
+ Revised with feedback from Mikael Ronström and bug reports
+ </remark>
+
<para>
This section discusses the manner in which MySQL Cluster divides
and duplicates data for storage.
@@ -405,17 +409,18 @@
It is common for the terms <quote>node</quote> and
<quote>data node</quote> to be used interchangeably when
referring to an <command>ndbd</command> process; where
- mentioned, management nodes (<command>ndb_mgmd</command>
- processes) and SQL nodes (<command>mysqld</command>
- processes) are specified as such in this discussion.
+ mentioned, management (MGM) nodes
+ (<command>ndb_mgmd</command> processes) and SQL nodes
+ (<command>mysqld</command> processes) are specified as such
+ in this discussion.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">Node Group</emphasis>: A node group
- consists of one or more nodes, and stores a partition, or
- set of <firstterm>replicas</firstterm> (see next item).
+ consists of one or more nodes, and stores partitions, or
+ sets of <firstterm>replicas</firstterm> (see next item).
</para>
<para>
@@ -428,15 +433,15 @@
<para>
<emphasis role="bold">Partition</emphasis>: This is a
portion of the data stored by the cluster. There are as many
- cluster partitions as node groups participating in the
- cluster, and each node group is responible for keeping at
- least one copy of the partition assigned to it (that is, at
- least one replica) available to the cluster.
+ cluster partitions as nodes participating in the
+ cluster. Each node is responible for keeping at least one
+ copy of any partitions assigned to it (that is, at least one
+ replica) available to the cluster.
</para>
<para>
- A partition belongs entirely to a single node group; a node
- group can store several partitions.
+ A replica belongs entirely to a single node; a node can
+ (and usually does) store several replicas.
</para>
</listitem>
@@ -454,11 +459,13 @@
<para>
The following diagram illustrates a MySQL Cluster with four data
- nodes, arranged in two node groups of two nodes each. Note that
- no nodes other than data nodes are shown here, although a
- working cluster requires an <command>ndb_mgm</command> process
- for cluster management and at least one SQL node to access the
- data stored by the cluster.
+ nodes, arranged in two node groups of two nodes each; nodes 1
+ and 2 belong to node group 0, and nodes 3 and 4 belong to node
+ group 1. Note that only data (<command>ndbd</command>) nodes are
+ shown here; although a working cluster requires an
+ <command>ndb_mgm</command> process for cluster management and at
+ least one SQL node to access the data stored by the cluster,
+ these have been omitted in the figure for clarity.
</para>
<mediaobject>
@@ -472,25 +479,56 @@
</mediaobject>
<para>
- The data stored by the cluster is divided into two partitions,
- labeled <emphasis role="bold">A</emphasis> and
- <emphasis role="bold">B</emphasis> in the diagram. Each
- partition is stored — in multiple copies — on a node
- group. The data making up Partition
- <emphasis role="bold">A</emphasis> is stored on Node
- <emphasis role="bold">A-1</emphasis>, and this data is identical
- to that stored by Node <emphasis role="bold">A-2</emphasis>. The
- data stored by Nodes <emphasis role="bold">B-1</emphasis> and
- <emphasis role="bold">B-2</emphasis> is also the same —
- these two nodes store identical copies of the data making up
- Partition <emphasis role="bold">B</emphasis>.
+ The data stored by the cluster is divided into four partitions,
+ numbered 0, 1, 2, and 3. Each partition is stored — in
+ multiple copies — on the same node group. Partitions are
+ stored on alternate node groups:
+ Partition 2 is stored on .
</para>
-
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Partition 0 is stored on node group 0; a <firstterm>primary
+ replica</firstterm> (primary copy) is stored on node 1,
+ and a <firstterm>backup replica</firstterm> (backup copy of
+ the partition) is stored on node 2.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Partition 1 is stored on the other node group (node group
+ 1); this partition's primary replica is on node 3, and its
+ backup replica is on node 4.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Partition 2 is stored on node group 0. However, the placing
+ of its two replicas is reversed from that of Partition 0;
+ for Partition 2, the primary replica is stored on node 2,
+ and the backup on node 1.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Partition 3 is stored on node group 1, and the placement of
+ its two replicas are reversed from those of partition 1.
+ That is, its primary replica is located on node 4, with the
+ backup on node 3.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+
<para>
What this means so far as the continued operation of a MySQL
Cluster is this: so long as each node group participating in the
- cluster has at least one <quote>live</quote> node, the cluster
- has a complete copy of all data and remains viable. This is
+ cluster has at least one node operating, the cluster has a
+ complete copy of all data and remains viable. This is
illustrated in the next diagram.
</para>
@@ -510,16 +548,15 @@
<para>
In this example, where the cluster consists of two node groups
- of two nodes each, any combination of at least one node in Node
- Group <emphasis role="bold">A</emphasis> and at least one node
- in Node Group <emphasis role="bold">B</emphasis> is sufficient
+ of two nodes each, any combination of at least one node in node
+ group 0 and at least one node in node group 1 is sufficient
to keep the cluster <quote>alive</quote> (indicated by arrows in
- the diagram). However, if both nodes from either node group
- fail, the remaining two nodes are not sufficient (shown by
- arrows marked out with an <emphasis role="bold">X</emphasis>);
- in either case, the cluster has lost an entire partition and so
- can no longer provide access to a complete set of all cluster
- data.
+ the diagram). However, if <emphasis>both</emphasis> nodes from
+ <emphasis>either</emphasis> node group fail, the remaining two
+ nodes are not sufficient (shown by the arrows marked out with an
+ <emphasis role="bold">X</emphasis>); in either case, the cluster
+ has lost an entire partition and so can no longer provide access
+ to a complete set of all cluster data.
</para>
<remark role="todo">
@@ -527,11 +564,6 @@
multiple CPUs.
</remark>
- <remark role="todo">
- [js] Add description of memory requirements based on Hartmut's
- example scripts.
- </remark>
-
</section>
</section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1989 - in trunk: refman-4.1 refman-5.0 refman-5.1 | jon | 2 May |
