Author: jstephens
Date: 2006-01-15 06:29:22 +0100 (Sun, 15 Jan 2006)
New Revision: 842
Log:
Reformat.
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-01-15 05:24:34 UTC (rev 841)
+++ trunk/refman-4.1/ndbcluster.xml 2006-01-15 05:29:22 UTC (rev 842)
@@ -256,11 +256,11 @@
</listitem>
</itemizedlist>
-
+
<para>
For a brief introduction to the relationships between nodes, node
- groups, replicas, and partitions in MySQL Cluster, see
- <xref linkend="mysql-cluster-nodes-groups"/>.
+ groups, replicas, and partitions in MySQL Cluster, see
+ <xref linkend="mysql-cluster-nodes-groups"/>.
</para>
<para>
@@ -361,171 +361,176 @@
</remark>
<section id="mysql-cluster-nodes-groups">
+
<title>&title-mysql-cluster-nodes-groups;</title>
-
- <remark role="note">
- Author: Jon Stephens, with valuable assistance from Tomas Ulin, Jeb
- Miller, and Hartmut Holzgraefe
- </remark>
-
- <para>
- This section discusses the manner in which MySQL Cluster divides
- and duplicates data for storage and its implications for CLuster
- memory requirements.
- </para>
-
- <para>
- <emphasis role="bold">Concepts</emphasis>
- </para>
-
- <para>
- Central to an understanding of this topic are the following
- concepts, listed here with brief definitions:
- </para>
-
- <itemizedlist>
- <listitem>
+
+ <remark role="note">
+ Author: Jon Stephens, with valuable assistance from Tomas Ulin,
+ Jeb Miller, and Hartmut Holzgraefe
+ </remark>
+
<para>
- <emphasis role="bold">(Data) Node</emphasis>: An
- <command>ndbd</command> process, which stores a
- <firstterm>replica</firstterm> —that is, a copy of the
- <firstterm>partition</firstterm> (see below) assigned to the
- node group of which the node is a member.
+ This section discusses the manner in which MySQL Cluster divides
+ and duplicates data for storage and its implications for CLuster
+ memory requirements.
</para>
-
+
<para>
- Each data node is usually located on a separate computer.
- However, it is also possible to host multiple data nodes on a
- single computer having more than one processor. In such cases,
- it is feasible to run one instance of <command>ndbd</command>
- per physical CPU. (Note that a processor with multiple cores is
- still a single processor.)
+ <emphasis role="bold">Concepts</emphasis>
</para>
-
+
<para>
- 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.
+ Central to an understanding of this topic are the following
+ concepts, listed here with brief definitions:
</para>
- </listitem>
-
- <listitem>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <emphasis role="bold">(Data) Node</emphasis>: An
+ <command>ndbd</command> process, which stores a
+ <firstterm>replica</firstterm> —that is, a copy of the
+ <firstterm>partition</firstterm> (see below) assigned to the
+ node group of which the node is a member.
+ </para>
+
+ <para>
+ Each data node is usually located on a separate computer.
+ However, it is also possible to host multiple data nodes on
+ a single computer having more than one processor. In such
+ cases, it is feasible to run one instance of
+ <command>ndbd</command> per physical CPU. (Note that a
+ processor with multiple cores is still a single processor.)
+ </para>
+
+ <para>
+ 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.
+ </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).
+ </para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: Currently, all node
+ groups in a cluster must have the same number of nodes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <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, at
+ least one replica) available to the cluster.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <emphasis role="bold">Replica</emphasis>: This is a copy of
+ a cluster partition. Each node in a node group stores a
+ replica. Also sometimes known as a <firstterm>partition
+ replica</firstterm>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<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).
+ 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 in order to
+ access the data stored by the cluster.
</para>
-
+
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/replicas-groups-1-1.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">A MySQL Cluster, with 2 node groups having 2
+ nodes each</phrase>
+ </textobject>
+ </mediaobject>
+
<para>
- <emphasis role="bold">Note</emphasis>: Currently, all node
- groups in a cluster must have the same number of nodes.
+ 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>.
</para>
- </listitem>
-
- <listitem>
+
<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, at least one replica) available
- to the cluster.
+ 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
+ illustrated in the next diagram.
</para>
- </listitem>
-
- <listitem>
+
+ <remark role="todo">
+ [js] Not a very good caption; think of a better one.
+ </remark>
+
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/replicas-groups-1-2.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">Nodes required to keep a 2x2 cluster
+ viable</phrase>
+ </textobject>
+ </mediaobject>
+
<para>
- <emphasis role="bold">Replica</emphasis>: This is a copy of a
- cluster partition. Each node in a node group stores a replica.
- Also sometimes known as a <firstterm>partition
- replica</firstterm>.
+ 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
+ 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.
</para>
- </listitem>
- </itemizedlist>
-
- <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 in order to access the data
- stored by the cluster.
- </para>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/replicas-groups-1-1.png" format="PNG"/>
- </imageobject>
- <textobject>
- <phrase lang="en">A MySQL Cluster, with 2 node groups having 2
- nodes each</phrase>
- </textobject>
- </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>.
- </para>
-
- <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 illustrated in
- the next diagram.
- </para>
-
- <remark role="todo">
- [js] Not a very good caption; think of a better one.
- </remark>
-
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/replicas-groups-1-2.png" format="PNG"/>
- </imageobject>
- <textobject>
- <phrase lang="en">Nodes required to keep a 2x2 cluster viable</phrase>
- </textobject>
- </mediaobject>
-
- <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 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.
- </para>
-
<remark role="todo">
[js] Add discussion of application of the above to hosts running
multiple CPUs.
</remark>
-
+
<remark role="todo">
[js] Add description of memory requirements based on Hartmut's
example scripts.
</remark>
+
</section>
-
-
+
</section>
<section id="multi-computer">
@@ -2604,7 +2609,7 @@
old logfile is renamed by appending
<filename>.x</filename> to the filename, where
<literal>x</literal> is the next number not yet
- used with this name.
+ used with this name.
</para>
</listitem>
Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml 2006-01-15 05:24:34 UTC (rev 841)
+++ trunk/refman-5.0/ndbcluster.xml 2006-01-15 05:29:22 UTC (rev 842)
@@ -258,8 +258,8 @@
<para>
For a brief introduction to the relationships between nodes, node
- groups, replicas, and partitions in MySQL Cluster, see
- <xref linkend="mysql-cluster-nodes-groups"/>.
+ groups, replicas, and partitions in MySQL Cluster, see
+ <xref linkend="mysql-cluster-nodes-groups"/>.
</para>
<para>
@@ -359,172 +359,177 @@
@subsection How MySQL Cluster Avoids Network Partitioning
</remark>
- <section id="mysql-cluster-nodes-groups">
+ <section id="mysql-cluster-nodes-groups">
+
<title>&title-mysql-cluster-nodes-groups;</title>
-
- <remark role="note">
- Author: Jon Stephens, with valuable assistance from Tomas Ulin, Jeb
- Miller, and Hartmut Holzgraefe
- </remark>
-
- <para>
- This section discusses the manner in which MySQL Cluster divides
- and duplicates data for storage and its implications for CLuster
- memory requirements.
- </para>
-
- <para>
- <emphasis role="bold">Concepts</emphasis>
- </para>
-
- <para>
- Central to an understanding of this topic are the following
- concepts, listed here with brief definitions:
- </para>
-
- <itemizedlist>
- <listitem>
+
+ <remark role="note">
+ Author: Jon Stephens, with valuable assistance from Tomas Ulin,
+ Jeb Miller, and Hartmut Holzgraefe
+ </remark>
+
<para>
- <emphasis role="bold">(Data) Node</emphasis>: An
- <command>ndbd</command> process, which stores a
- <firstterm>replica</firstterm> —that is, a copy of the
- <firstterm>partition</firstterm> (see below) assigned to the
- node group of which the node is a member.
+ This section discusses the manner in which MySQL Cluster divides
+ and duplicates data for storage and its implications for CLuster
+ memory requirements.
</para>
-
+
<para>
- Each data node is usually located on a separate computer.
- However, it is also possible to host multiple data nodes on a
- single computer having more than one processor. In such cases,
- it is feasible to run one instance of <command>ndbd</command>
- per physical CPU. (Note that a processor with multiple cores is
- still a single processor.)
+ <emphasis role="bold">Concepts</emphasis>
</para>
-
+
<para>
- 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.
+ Central to an understanding of this topic are the following
+ concepts, listed here with brief definitions:
</para>
- </listitem>
-
- <listitem>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <emphasis role="bold">(Data) Node</emphasis>: An
+ <command>ndbd</command> process, which stores a
+ <firstterm>replica</firstterm> —that is, a copy of the
+ <firstterm>partition</firstterm> (see below) assigned to the
+ node group of which the node is a member.
+ </para>
+
+ <para>
+ Each data node is usually located on a separate computer.
+ However, it is also possible to host multiple data nodes on
+ a single computer having more than one processor. In such
+ cases, it is feasible to run one instance of
+ <command>ndbd</command> per physical CPU. (Note that a
+ processor with multiple cores is still a single processor.)
+ </para>
+
+ <para>
+ 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.
+ </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).
+ </para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: Currently, all node
+ groups in a cluster must have the same number of nodes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <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, at
+ least one replica) available to the cluster.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <emphasis role="bold">Replica</emphasis>: This is a copy of
+ a cluster partition. Each node in a node group stores a
+ replica. Also sometimes known as a <firstterm>partition
+ replica</firstterm>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<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).
+ 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 in order to
+ access the data stored by the cluster.
</para>
-
+
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/replicas-groups-1-1.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">A MySQL Cluster, with 2 node groups having 2
+ nodes each</phrase>
+ </textobject>
+ </mediaobject>
+
<para>
- <emphasis role="bold">Note</emphasis>: Currently, all node
- groups in a cluster must have the same number of nodes.
+ 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>.
</para>
- </listitem>
-
- <listitem>
+
<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, at least one replica) available
- to the cluster.
+ 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
+ illustrated in the next diagram.
</para>
- </listitem>
-
- <listitem>
+
+ <remark role="todo">
+ [js] Not a very good caption; think of a better one.
+ </remark>
+
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/replicas-groups-1-2.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">Nodes required to keep a 2x2 cluster
+ viable</phrase>
+ </textobject>
+ </mediaobject>
+
<para>
- <emphasis role="bold">Replica</emphasis>: This is a copy of a
- cluster partition. Each node in a node group stores a replica.
- Also sometimes known as a <firstterm>partition
- replica</firstterm>.
+ 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
+ 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.
</para>
- </listitem>
- </itemizedlist>
-
- <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 in order to access the data
- stored by the cluster.
- </para>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/replicas-groups-1-1.png" format="PNG"/>
- </imageobject>
- <textobject>
- <phrase lang="en">A MySQL Cluster, with 2 node groups having 2
- nodes each</phrase>
- </textobject>
- </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>.
- </para>
-
- <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 illustrated in
- the next diagram.
- </para>
-
- <remark role="todo">
- [js] Not a very good caption; think of a better one.
- </remark>
-
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/replicas-groups-1-2.png" format="PNG"/>
- </imageobject>
- <textobject>
- <phrase lang="en">Nodes required to keep a 2x2 cluster viable</phrase>
- </textobject>
- </mediaobject>
-
- <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 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.
- </para>
-
<remark role="todo">
[js] Add discussion of application of the above to hosts running
multiple CPUs.
</remark>
-
+
<remark role="todo">
[js] Add description of memory requirements based on Hartmut's
example scripts.
</remark>
+
</section>
-
-
+
</section>
<section id="multi-computer">
@@ -2594,7 +2599,7 @@
old logfile is renamed by appending
<filename>.x</filename> to the filename, where
<literal>x</literal> is the next number not yet
- used with this name.
+ used with this name.
</para>
</listitem>
Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml 2006-01-15 05:24:34 UTC (rev 841)
+++ trunk/refman-5.1/ndbcluster.xml 2006-01-15 05:29:22 UTC (rev 842)
@@ -258,8 +258,8 @@
<para>
For a brief introduction to the relationships between nodes, node
- groups, replicas, and partitions in MySQL Cluster, see
- <xref linkend="mysql-cluster-nodes-groups"/>.
+ groups, replicas, and partitions in MySQL Cluster, see
+ <xref linkend="mysql-cluster-nodes-groups"/>.
</para>
<para>
@@ -359,172 +359,177 @@
@subsection How MySQL Cluster Avoids Network Partitioning
</remark>
- <section id="mysql-cluster-nodes-groups">
+ <section id="mysql-cluster-nodes-groups">
+
<title>&title-mysql-cluster-nodes-groups;</title>
-
- <remark role="note">
- Author: Jon Stephens, with valuable assistance from Tomas Ulin, Jeb
- Miller, and Hartmut Holzgraefe
- </remark>
-
- <para>
- This section discusses the manner in which MySQL Cluster divides
- and duplicates data for storage and its implications for CLuster
- memory requirements.
- </para>
-
- <para>
- <emphasis role="bold">Concepts</emphasis>
- </para>
-
- <para>
- Central to an understanding of this topic are the following
- concepts, listed here with brief definitions:
- </para>
-
- <itemizedlist>
- <listitem>
+
+ <remark role="note">
+ Author: Jon Stephens, with valuable assistance from Tomas Ulin,
+ Jeb Miller, and Hartmut Holzgraefe
+ </remark>
+
<para>
- <emphasis role="bold">(Data) Node</emphasis>: An
- <command>ndbd</command> process, which stores a
- <firstterm>replica</firstterm> —that is, a copy of the
- <firstterm>partition</firstterm> (see below) assigned to the
- node group of which the node is a member.
+ This section discusses the manner in which MySQL Cluster divides
+ and duplicates data for storage and its implications for CLuster
+ memory requirements.
</para>
-
+
<para>
- Each data node is usually located on a separate computer.
- However, it is also possible to host multiple data nodes on a
- single computer having more than one processor. In such cases,
- it is feasible to run one instance of <command>ndbd</command>
- per physical CPU. (Note that a processor with multiple cores is
- still a single processor.)
+ <emphasis role="bold">Concepts</emphasis>
</para>
-
+
<para>
- 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.
+ Central to an understanding of this topic are the following
+ concepts, listed here with brief definitions:
</para>
- </listitem>
-
- <listitem>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <emphasis role="bold">(Data) Node</emphasis>: An
+ <command>ndbd</command> process, which stores a
+ <firstterm>replica</firstterm> —that is, a copy of the
+ <firstterm>partition</firstterm> (see below) assigned to the
+ node group of which the node is a member.
+ </para>
+
+ <para>
+ Each data node is usually located on a separate computer.
+ However, it is also possible to host multiple data nodes on
+ a single computer having more than one processor. In such
+ cases, it is feasible to run one instance of
+ <command>ndbd</command> per physical CPU. (Note that a
+ processor with multiple cores is still a single processor.)
+ </para>
+
+ <para>
+ 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.
+ </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).
+ </para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: Currently, all node
+ groups in a cluster must have the same number of nodes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <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, at
+ least one replica) available to the cluster.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <emphasis role="bold">Replica</emphasis>: This is a copy of
+ a cluster partition. Each node in a node group stores a
+ replica. Also sometimes known as a <firstterm>partition
+ replica</firstterm>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<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).
+ 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 in order to
+ access the data stored by the cluster.
</para>
-
+
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/replicas-groups-1-1.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">A MySQL Cluster, with 2 node groups having 2
+ nodes each</phrase>
+ </textobject>
+ </mediaobject>
+
<para>
- <emphasis role="bold">Note</emphasis>: Currently, all node
- groups in a cluster must have the same number of nodes.
+ 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>.
</para>
- </listitem>
-
- <listitem>
+
<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, at least one replica) available
- to the cluster.
+ 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
+ illustrated in the next diagram.
</para>
- </listitem>
-
- <listitem>
+
+ <remark role="todo">
+ [js] Not a very good caption; think of a better one.
+ </remark>
+
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/replicas-groups-1-2.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">Nodes required to keep a 2x2 cluster
+ viable</phrase>
+ </textobject>
+ </mediaobject>
+
<para>
- <emphasis role="bold">Replica</emphasis>: This is a copy of a
- cluster partition. Each node in a node group stores a replica.
- Also sometimes known as a <firstterm>partition
- replica</firstterm>.
+ 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
+ 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.
</para>
- </listitem>
- </itemizedlist>
-
- <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 in order to access the data
- stored by the cluster.
- </para>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/replicas-groups-1-1.png" format="PNG"/>
- </imageobject>
- <textobject>
- <phrase lang="en">A MySQL Cluster, with 2 node groups having 2
- nodes each</phrase>
- </textobject>
- </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>.
- </para>
-
- <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 illustrated in
- the next diagram.
- </para>
-
- <remark role="todo">
- [js] Not a very good caption; think of a better one.
- </remark>
-
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/replicas-groups-1-2.png" format="PNG"/>
- </imageobject>
- <textobject>
- <phrase lang="en">Nodes required to keep a 2x2 cluster viable</phrase>
- </textobject>
- </mediaobject>
-
- <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 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.
- </para>
-
<remark role="todo">
[js] Add discussion of application of the above to hosts running
multiple CPUs.
</remark>
-
+
<remark role="todo">
[js] Add description of memory requirements based on Hartmut's
example scripts.
</remark>
+
</section>
-
-
+
</section>
<section id="multi-computer">
@@ -2592,7 +2597,7 @@
old logfile is renamed by appending
<filename>.x</filename> to the filename, where
<literal>x</literal> is the next number not yet
- used with this name.
+ used with this name.
</para>
</listitem>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r842 - in trunk: refman-4.1 refman-5.0 refman-5.1 | jon | 15 Jan |
