Author: jstephens
Date: 2009-01-08 18:37:53 +0100 (Thu, 08 Jan 2009)
New Revision: 13041
Log:
Added procedure for adding data nodes/node groups in Cluster 6.4.0+ to
cluster management section
Updated ndb-6.4.0 changelog, ndb-6.4 roadmap, ndb mgt client commands,
ALTER TABLE Syntax sections
Updated dependencies
Modified:
trunk/dynamic-docs/changelog/mysqld-1.xml
trunk/mysqlqb/Makefile.depends
trunk/refman-5.1/Makefile.depends
trunk/refman-5.1/mysql-cluster-management.xml
trunk/refman-5.1/mysql-cluster-overview.xml
trunk/refman-5.1/mysql-cluster-roadmap.xml
trunk/refman-5.1/sql-syntax-data-definition.xml
Modified: trunk/dynamic-docs/changelog/mysqld-1.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-1.xml 2009-01-08 16:15:14 UTC (rev 13040)
+++ trunk/dynamic-docs/changelog/mysqld-1.xml 2009-01-08 17:37:53 UTC (rev 13041)
Changed blocks: 1, Lines Added: 28, Lines Deleted: 0; 939 bytes
@@ -6,6 +6,34 @@
]>
<changelog>
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndbd"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.4.0"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It is now possible to add data nodes to a MySQL Cluster online
+ — that is, to a running MySQL Cluster without shutting it
+ down.
+ </para>
+
+ <para>
+ For information about the procedure for adding data nodes
+ online, see <xref linkend="mysql-cluster-online-add-node"/>.
+ </para>
+
+ </message>
+
+ </logentry>
+
<logentry entrytype="bug">
<tags>
Modified: trunk/mysqlqb/Makefile.depends
===================================================================
--- trunk/mysqlqb/Makefile.depends 2009-01-08 16:15:14 UTC (rev 13040)
+++ trunk/mysqlqb/Makefile.depends 2009-01-08 17:37:53 UTC (rev 13041)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 575 bytes
@@ -67,7 +67,7 @@
../refman-5.0/metadata/views.idmap \
../refman-common/metadata/bug-reports.idmap \
../refman-common/metadata/credits.idmap \
- metadata/mysqlqb_functions.idmap
+ ../refman-common/metadata/regexp.idmap
mysqlqb.validpure: $(mysqlqb_SOURCES)
mysqlqb.titles: $(mysqlqb_SOURCES)
mysqlqb.useless: $(mysqlqb_SOURCES)
Modified: trunk/refman-5.1/Makefile.depends
===================================================================
--- trunk/refman-5.1/Makefile.depends 2009-01-08 16:15:14 UTC (rev 13040)
+++ trunk/refman-5.1/Makefile.depends 2009-01-08 17:37:53 UTC (rev 13041)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 0; 1032 bytes
@@ -3488,6 +3488,7 @@
mysql_cluster_overview_IDMAPS = \
../ndbapi/metadata/ndbapi.idmap \
../refman-5.1/metadata/mysql-cluster-limitations.idmap \
+ ../refman-5.1/metadata/mysql-cluster-management.idmap \
../refman-5.1/metadata/mysql-cluster-overview.idmap
mysql-cluster-overview.validpure: $(mysql_cluster_overview_SOURCES)
mysql-cluster-overview.titles: $(mysql_cluster_overview_SOURCES)
@@ -4686,6 +4687,7 @@
../refman-5.1/metadata/language-structure-core.idmap \
../refman-5.1/metadata/mysql-cluster-disk-data.idmap \
../refman-5.1/metadata/mysql-cluster-limitations.idmap \
+ ../refman-5.1/metadata/mysql-cluster-management.idmap \
../refman-5.1/metadata/mysql-cluster.idmap \
../refman-5.1/metadata/news-5.1-core.idmap \
../refman-5.1/metadata/optimization.idmap \
Modified: trunk/refman-5.1/mysql-cluster-management.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-management.xml 2009-01-08 16:15:14 UTC (rev 13040)
+++ trunk/refman-5.1/mysql-cluster-management.xml 2009-01-08 17:37:53 UTC (rev 13041)
Changed blocks: 2, Lines Added: 1173, Lines Deleted: 0; 40387 bytes
@@ -881,6 +881,47 @@
</para>
</listitem>
+ <listitem>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>CREATE NODEGROUP command</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>CREATE NODEGROUP command (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ <literal>CREATE NODEGROUP <replaceable>nodeid</replaceable>[,
+ <replaceable>nodeid</replaceable>, ...]</literal>
+ </para>
+
+ <para>
+ Creates a new MySQL Cluster node group and causes data nodes
+ to join it.
+ </para>
+
+ <para>
+ This command is used after adding new data nodes online to a
+ MySQL Cluster, and causes them to join a new node group and
+ thus to begin participating fully in the cluster. The command
+ takes as its sole parameter a comma-separated list of node IDs
+ — these are the IDs of the nodes just added and started
+ that are to join the new node group. The number of nodes must
+ be the same as the number of nodes in each node group that is
+ already part of the cluster (each MySQL Cluster node group
+ must have the same number of nodes). In other words, if the
+ MySQL Cluster has 2 node groups of 2 data nodes each, then the
+ new node group must also have 2 data nodes.
+ </para>
+
+ <para>
+ This command was introduced in MySQL Cluster NDB 6.4.0. For
+ more information, see
+ <xref linkend="mysql-cluster-online-add-node"/>.
+ </para>
+ </listitem>
+
</itemizedlist>
</section>
@@ -7247,4 +7288,1136 @@
</section>
+ <section id="mysql-cluster-online-add-node">
+
+ <title>Adding MySQL Cluster Data Nodes Online</title>
+
+ <para>
+ This section describes how to add MySQL Cluster data nodes
+ <quote>online</quote> — that is, without needing to shut
+ down the cluster completely and restart it as part of the process.
+ This capability is available beginning with MySQL Cluster NDB
+ 6.4.0.
+ </para>
+
+ <important>
+ <para>
+ Currently, you must add new data nodes to a MySQL Cluster as
+ part of a new node group. In addition, it is not possible to
+ change the number of replicas (or the number of nodes per node
+ group) online.
+ </para>
+ </important>
+
+ <section id="mysql-cluster-online-add-node-remarks">
+
+ <title>General Issues</title>
+
+ <para>
+ This section provides general information about the behavior of
+ and current limitations in adding MySQL Cluster nodes online.
+ </para>
+
+ <formalpara>
+
+ <title>Redistribution of Data</title>
+
+ <para>
+ The ability to add new nodes online includes a means to
+ reorganize <literal>NDBCLUSTER</literal> table data and
+ indexes so that they are distributed across all data nodes,
+ including the new ones. Table reorganization of both in-memory
+ and Disk Data tables is supported. This redistribution does
+ not currently include unique indexes (only ordered indexes are
+ redistibuted) or <literal>BLOB</literal> table data, but we
+ are working to add redistibution of these in the near future.
+ The initial redistribution is not automatic, but can be
+ accomplished using simple SQL statements in
+ <command>mysql</command> or another MySQL client program.
+ However, once a new node group has been added to the cluster,
+ all new data and indexes are distributed automatically among
+ all cluster nodes, including the new ones.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Partial starts</title>
+
+ <para>
+ It is possible to add a new node group without all of the new
+ data nodes being started. It is also possible to add a new
+ node group to a degraded cluster — that is, a cluster
+ that is only partially started, or where one or more data
+ nodes are not running. In the latter case, the cluster must
+ have enough nodes running to be viable before the new node
+ group can be added.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Effects on ongoing operations</title>
+
+ <para>
+ Normal DML operations using MySQL Cluster data are not
+ prevented by the creation or addition of a new node group, or
+ by table reorganization. However, it is not possible to
+ perform DDL concurrently with table reorganization —
+ that is, no other DDL statements can be issued while an
+ <literal>ALTER TABLE ... REORGANIZE PARTITION</literal>
+ statement is executing. In addition, during the execution of
+ <literal>ALTER TABLE ... REORGANIZE PARTITION</literal> (or
+ the execution of any other DDL statement), it is not possible
+ to restart cluster data nodes.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Failure handling</title>
+
+ <para>
+ Failures of data nodes during node group creation and table
+ reorganization are handled as hown in the following table:
+
+ <informaltable>
+ <tgroup cols="3">
+ <colspec colwidth="25*"/>
+ <colspec colwidth="25*" colname="2"/>
+ <colspec colwidth="25*"/>
+ <colspec colwidth="25*" colname="4"/>
+ <spanspec namest="2" nameend="4" spanname="title"/>
+ <thead>
+ <row>
+ <entry morerows="1">Failure occurs during:</entry>
+ <entry spanname="title">Failure occurs in:</entry>
+ </row>
+ <row>
+ <entry><quote>Old</quote> data nodes</entry>
+ <entry><quote>New</quote> data nodes</entry>
+ <entry>System</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>Node group creation</entry>
+ <entry><itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>If a node other than the master fails:</title>
+
+ <para>
+ The creation of the node group is always
+ rolled forward.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the master fails:</title>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the internal commit point has been reached:</title>
+
+ <para>
+ The creation of the node group is
+ rolled forward.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the internal commit point has not yet been reached</title>
+
+ <para>
+ The creation of the node group is
+ rolled back
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist></entry>
+ <entry><itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>If a node other than the master fails:</title>
+
+ <para>
+ The creation of the node group is always
+ rolled forward.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the master fails:</title>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the internal commit point has been reached:</title>
+
+ <para>
+ The creation of the node group is
+ rolled forward.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the internal commit point has not yet been reached</title>
+
+ <para>
+ The creation of the node group is
+ rolled back
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist></entry>
+ <entry><itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the execution of <literal>CREATE NODEGROUP</literal> has reached the
+ internal commit point:</title>
+
+ <para>
+ When restarted, the cluster includes the new
+ node group. Otherwise it without.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the execution of <literal>CREATE NODEGROUP</literal> has not yet
+ reached the internal commit point:</title>
+
+ <para>
+ When restarted, the cluster does not include
+ the new node group.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist></entry>
+ </row>
+ <row>
+ <entry>Table reorganization</entry>
+ <entry><itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>If a node other than the master fails:</title>
+
+ <para>
+ The table reorganization is always rolled
+ forward.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the master fails:</title>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the internal commit point has been reached:</title>
+
+ <para>
+ The table reorganization is rolled
+ forward.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the internal commit point has not yet been reached</title>
+
+ <para>
+ The table reorganization is rolled
+ back.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist></entry>
+ <entry><itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>If a node other than the master fails:</title>
+
+ <para>
+ The table reorganization is always rolled
+ forward.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the master fails:</title>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the internal commit point has been reached:</title>
+
+ <para>
+ The table reorganization is rolled
+ forward.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the internal commit point has not yet been reached</title>
+
+ <para>
+ The table reorganization is rolled
+ back.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist></entry>
+ <entry><itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the execution of an <literal>ALTER ONLINE TABLE
+ <replaceable>table</replaceable> REORGANIZE
+ PARTITION</literal> statement has reached
+ the internal commit point:</title>
+
+ <para>
+ When the cluster is restarted, the the data
+ and indexes belonging to
+ <replaceable>table</replaceable> are
+ distributed using the <quote>new</quote>
+ data nodes.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>If the execution of an <literal>ALTER ONLINE TABLE
+ <replaceable>table</replaceable> REORGANIZE
+ PARTITION</literal> statement has not yet
+ reached the internal commit point:</title>
+
+ <para>
+ When the cluster is restarted, the the data
+ and indexes belonging to
+ <replaceable>table</replaceable> are
+ distributed using only the
+ <quote>old</quote> data nodes.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </para>
+
+ </formalpara>
+
+ </section>
+
+ <section id="mysql-cluster-online-add-node-basics">
+
+ <title>Basic procedure</title>
+
+ <para>
+ In this section, we list the basic steps required to add new
+ nodes to a MySQL Cluster. For a detailed example, see
+ <xref linkend="mysql-cluster-online-add-node-example"/>.
+ </para>
+
+ <para>
+ Assuming that you already have a running MySQL Cluster, adding
+ data nodes online requires the following steps:
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Edit the cluster configuration
+ <filename>config.ini</filename> file, adding new
+ <literal>[ndbd]</literal> sections corresponding to the
+ nodes to be added. In the case where the cluster uses
+ multiple management servers, these changes need to be made
+ to all <filename>config.ini</filename> files used by the
+ management servers.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Perform a rolling restart of all MySQL Cluster management
+ servers.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Perform a rolling restart of all existing MySQL Cluster
+ data nodes.
+ </para>
+
+ <note>
+ <para>
+ It is not necessary to use <option>--initial</option>
+ when restarting the existing data nodes.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ Perform a rolling restart of any SQL or API nodes
+ connected to the MySQL Cluster.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Perform an initial start of the new data nodes.
+ </para>
+
+ <note>
+ <para>
+ The new data nodes may be started in any order, and can
+ also be started concurrently, as long as they are
+ started after the rolling restarts of all existing nodes
+ have been completed and before proceeding to the next
+ step.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ Execute one or more <literal>CREATE NODEGROUP</literal>
+ commands in the MySQL Cluster management client to create
+ the new node group or node groups to which the new data
+ nodes will belong.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Redistribute the cluster's data among all data nodes
+ (including the new ones) by issuing an <literal>ALTER
+ ONLINE TABLE ... REORGANIZE PARTITION</literal> statement
+ in the <command>mysql</command> client for each
+ <literal>NDBCLUSTER</literal> table. To reclaim wasted
+ memory, issue an <literal>OPTIMIZE TABLE</literal>
+ statement for each <literal>NDBCLUSTER</literal> table as
+ well.
+ </para>
+
+ <note>
+ <para>
+ This needs to be done only for tables already existing
+ at the time the new node group is added; data in tables
+ created after the new node group is added will be
+ distributed automatically.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ Reclaim the space freed on the <quote>old</quote> nodes by
+ issuing, for each <literal>NDBCLUSTER</literal> table, an
+ <literal
+ role="stmt">OPTIMIZE
+ TABLE</literal> statement in the <command>mysql</command>
+ client.
+ </para>
+ </listitem>
+
+ </orderedlist>
+ </para>
+
+ </section>
+
+ <section id="mysql-cluster-online-add-node-example">
+
+ <title>Adding New Cluster Nodes: Detailed Example</title>
+
+ <para>
+ In this section we provide a detailed example illustrating how
+ to add new MySQL Cluster data nodes online, starting with a
+ MySQL Cluster having 2 data nodes in a single node group and
+ concluding with a cluster having 4 data nodes in 2 node groups.
+ </para>
+
+ <formalpara>
+
+ <title>Starting configuration</title>
+
+ <para>
+ For purposes of illustration, we assume a minimal
+ configuration, and that the cluster uses a
+ <filename>config.ini</filename> file containing only the
+ following information:
+
+<programlisting>
+[ndbd default]
+DataMemory = 100M
+IndexMemory = 100M
+NoOfReplicas = 2
+DataDir = /usr/local/mysql/var/mysql-cluster
+
+[ndbd]
+Id = 1
+HostName = 192.168.0.1
+
+[ndbd]
+Id = 2
+HostName = 192.168.0.2
+
+[mgm]
+HostName = 192.168.0.10
+Id = 10
+
+[api]
+Id=20
+HostName = 192.168.0.20
+
+[api]
+Id=21
+HostName = 192.168.0.21
+</programlisting>
+
+ We also assume that you have already started the cluster using
+ the appropriate command line or <filename>my.cnf</filename>
+ options, and that running <literal>SHOW</literal> in the
+ management client produces output similar to what is shown
+ here:
+
+<programlisting>
+-- NDB Cluster -- Management Client --
+ndb_mgm> <userinput>SHOW</userinput>
+Connected to Management Server at: 192.168.0.10:1186
+Cluster Configuration
+---------------------
+[ndbd(NDB)] 2 node(s)
+id=1 @192.168.0.1 (mysql-5.1.30 ndb-6.4.0, Nodegroup: 0, Master)
+id=2 @192.168.0.2 (mysql-5.1.30 ndb-6.4.0, Nodegroup: 0)
+
+[ndb_mgmd(MGM)] 1 node(s)
+id=10 @192.168.0.10 (mysql-5.1.30 ndb-6.4.0)
+
+[mysqld(API)] 2 node(s)
+id=20 @192.168.0.20 (mysql-5.1.30 ndb-6.4.0)
+id=21 @192.168.0.21 (mysql-5.1.30 ndb-6.4.0)
+</programlisting>
+
+ Finally, we assume that the cluster contains a single
+ <literal>NDBCLUSTER</literal> table created as shown here:
+
+<programlisting>
+USE n;
+
+CREATE TABLE ips (
+ id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+ country_code CHAR(2) NOT NULL,
+ type CHAR(4) NOT NULL,
+ ip_address varchar(15) NOT NULL,
+ addresses BIGINT UNSIGNED DEFAULT NULL,
+ date BIGINT UNSIGNED DEFAULT NULL
+) ENGINE NDBCLUSTER;
+</programlisting>
+
+ The memory usage and related information shown later in this
+ section was generated after inserting approximately 50000 rows
+ into this table.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Step 1: Update configuration file</title>
+
+ <para>
+ Open the cluster global configuration file in a text editor
+ and add <literal>[ndbd]</literal> sections corresponding to
+ the 2 new data nodes. (We give these data nodes IDs 3 and 4,
+ and assume that they are to be run on host machines at
+ addresses 192.168.0.3 and 192.168.0.4, respectively.) After
+ you have added the new sections, the contents of the
+ <filename>config.ini</filename> file should look like what is
+ shown here, where the additions to the file are shown in bold
+ type:
+
+<programlisting>
+[ndbd default]
+DataMemory = 100M
+IndexMemory = 100M
+NoOfReplicas = 2
+DataDir = /usr/local/mysql/var/mysql-cluster
+
+[ndbd]
+Id = 1
+HostName = 192.168.0.1
+
+[ndbd]
+Id = 2
+HostName = 192.168.0.2
+
+<emphasis role="bold">[ndbd]
+Id = 3
+HostName = 192.168.0.3
+
+[ndbd]
+Id = 4
+HostName = 192.168.0.4</emphasis>
+
+[mgm]
+HostName = 192.168.0.10
+Id = 10
+
+[api]
+Id=20
+HostName = 192.168.0.20
+
+[api]
+Id=21
+HostName = 192.168.0.21
+</programlisting>
+
+ Once you have made the necessary changes, save the file.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Step 2: Restart the management server</title>
+
+ <para>
+ Restarting the cluster management server requires that you
+ issue separate commands to stop the management server and then
+ to start it again, as follows:
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Stop the management server using the management client
+ <literal>STOP</literal> command, as shown here:
+
+<programlisting>
+ndb_mgm> <userinput>10 STOP</userinput>
+Node 10 has shut down.
+Disconnecting to allow Management Server to shutdown
+
+shell>
+</programlisting>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Because shutting down the management server causes the
+ management client to terminate, you must start the
+ management server from the system shell. For simplicity,
+ we assume that <filename>config.ini</filename> is in the
+ same directory as the management server binary, but in
+ practice, you must supply the correct path to the
+ configuration file. If your shell's current
+ directory is also the same as the directory where the
+ management server binary is located, then you can invoke
+ the management server as shown here:
+
+<programlisting>
+shell> <userinput>ndb_mgmd -f config.ini</userinput>
+2008-12-08 17:29:23 [MgmSrvr] INFO -- NDB Cluster Management Server. mysql-5.1.30 ndb-6.4.0-alpha
+2008-12-08 17:29:23 [MgmSrvr] INFO -- Reading cluster configuration from 'config.ini'
+</programlisting>
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ If you check the output of <literal>SHOW</literal> in the
+ management client after restarting the
+ <command>ndb_mgm</command> process, you should now see
+ something like this:
+
+<programlisting>
+-- NDB Cluster -- Management Client --
+ndb_mgm> <userinput>SHOW</userinput>
+Connected to Management Server at: 192.168.0.10:1186
+Cluster Configuration
+---------------------
+[ndbd(NDB)] 2 node(s)
+id=1 @192.168.0.1 (mysql-5.1.30 ndb-6.4.0, Nodegroup: 0, Master)
+id=2 @192.168.0.2 (mysql-5.1.30 ndb-6.4.0, Nodegroup: 0)
+id=3 (not connected, accepting connect from 192.168.0.3)
+id=4 (not connected, accepting connect from 192.168.0.4)
+
+[ndb_mgmd(MGM)] 1 node(s)
+id=10 @192.168.0.10 (mysql-5.1.30 ndb-6.4.0)
+
+[mysqld(API)] 2 node(s)
+id=20 @192.168.0.20 (mysql-5.1.30 ndb-6.4.0)
+id=21 @192.168.0.21 (mysql-5.1.30 ndb-6.4.0)
+</programlisting>
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Step 3: Perform a rolling restart of the existing data nodes</title>
+
+ <para>
+ This step can be accomplished entirely within the cluster
+ management client using the <literal>RESTART</literal>
+ command, as shown here:
+
+<programlisting>
+ndb_mgm> <userinput>1 RESTART</userinput>
+Node 1: Node shutdown initiated
+Node 1: Node shutdown completed, restarting, no start.
+Node 1 is being restarted
+
+ndb_mgm> Node 1: Start initiated (version 6.4.0)
+Node 1: Started (version 6.4.0)
+
+ndb_mgm> <userinput>2 RESTART</userinput>
+Node 2: Node shutdown initiated
+Node 2: Node shutdown completed, restarting, no start.
+Node 2 is being restarted
+
+ndb_mgm> Node 2: Started (version 6.4.0)
+</programlisting>
+
+ <important>
+ <para>
+ After issuing each <literal><replaceable>X</replaceable>
+ RESTART</literal> command, wait until the management
+ client reports <literal>Node <replaceable>X</replaceable>:
+ Started (version ...)</literal>
+ <emphasis>before</emphasis> proceeding any further.
+ </para>
+ </important>
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Step 4: Perform a rolling restart of all cluster API nodes</title>
+
+ <para>
+ Shut down and restart each MySQL server acting as an SQL node
+ in the cluster using <command>mysqladmin shutdown</command>
+ followed by <command>mysqld_safe</command> (or another startup
+ script). This should be similar to what is shown here, where
+ <replaceable>password</replaceable> is the MySQL
+ <literal>root</literal> password for a given MySQL server
+ instance:
+
+<programlisting>
+shell> <userinput>mysqladmin -uroot -p<replaceable>password</replaceable> shutdown</userinput>
+081208 20:19:56 mysqld_safe mysqld from pid file
+/usr/local/mysql/var/tonfisk.pid ended
+shell> <userinput>mysqld_safe --ndbcluster --ndb-connectstring=192.168.0.10 &</userinput>
+081208 20:20:06 mysqld_safe Logging to '/usr/local/mysql/var/tonfisk.err'.
+081208 20:20:06 mysqld_safe Starting mysqld daemon with databases
+from /usr/local/mysql/var
+</programlisting>
+
+ Of course, the exact input and output depend on how and where
+ MySQL is installed on the system, as well as which options you
+ choose to start it (and whether or not some or all of these
+ options are specified in a <filename>my.cnf</filename> file).
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Step 5: Perform an initial start of the new data nodes</title>
+
+ <para>
+ From a system shell on each of the hosts for the new data
+ nodes, start the data nodes as shown here, using the
+ <option>--initial</option> option:
+
+<programlisting>
+shell> <userinput>ndbd -c 192.168.0.10 --initial</userinput>
+</programlisting>
+
+ <note>
+ <para>
+ Unlike the case with restarting the existing data nodes,
+ you can start the new data nodes concurrently; you do not
+ need to wait for one to finish starting before starting
+ the other.
+ </para>
+ </note>
+
+ <emphasis>Wait until both of the new data nodes have started
+ before proceeding with the next step</emphasis>. Once the new
+ data nodes have started, you can see in the output of the
+ management client <literal>SHOW</literal> show command that
+ they do not yet belong to any node group (as indicated with
+ bold type here):
+
+<programlisting>
+ndb_mgm> <userinput>SHOW</userinput>
+Connected to Management Server at: 192.168.0.10:1186
+Cluster Configuration
+---------------------
+[ndbd(NDB)] 2 node(s)
+id=1 @192.168.0.1 (mysql-5.1.30 ndb-6.4.0, Nodegroup: 0, Master)
+id=2 @192.168.0.2 (mysql-5.1.30 ndb-6.4.0, Nodegroup: 0)
+id=3 @192.168.0.3 (mysql-5.1.30 ndb-6.4.0, <emphasis role="bold">no nodegroup</emphasis>)
+id=4 @192.168.0.4 (mysql-5.1.30 ndb-6.4.0, <emphasis role="bold">no nodegroup</emphasis>)
+
+[ndb_mgmd(MGM)] 1 node(s)
+id=10 @192.168.0.10 (mysql-5.1.30 ndb-6.4.0)
+
+[mysqld(API)] 2 node(s)
+id=20 @192.168.0.20 (mysql-5.1.30 ndb-6.4.0)
+id=21 @192.168.0.21 (mysql-5.1.30 ndb-6.4.0)
+</programlisting>
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Step 6: Create a new node group</title>
+
+ <para>
+ You can do this by issuing a <literal>CREATE
+ NODEGROUP</literal> command in the cluster management client.
+ This command takes as its argument a comma-separated list of
+ the node IDs of the data nodes to be included in the new node
+ group, as shown here:
+
+<programlisting>
+ndb_mgm> <userinput>CREATE NODEGROUP 3,4</userinput>
+Nodegroup 1 created
+</programlisting>
+
+ By issuing <literal>SHOW</literal> again, you can verify that
+ data nodes 3 and 4 have joined the new node group (again
+ indicated in bold type):
+
+<programlisting>
+ndb_mgm> <userinput>SHOW</userinput>
+Connected to Management Server at: 192.168.0.10:1186
+Cluster Configuration
+---------------------
+[ndbd(NDB)] 2 node(s)
+id=1 @192.168.0.1 (mysql-5.1.30 ndb-6.4.0, Nodegroup: 0, Master)
+id=2 @192.168.0.2 (mysql-5.1.30 ndb-6.4.0, Nodegroup: 0)
+id=3 @192.168.0.3 (mysql-5.1.30 ndb-6.4.0, <emphasis role="bold">Nodegroup: 1</emphasis>)
+id=4 @192.168.0.4 (mysql-5.1.30 ndb-6.4.0, <emphasis role="bold">Nodegroup: 1</emphasis>)
+
+[ndb_mgmd(MGM)] 1 node(s)
+id=10 @192.168.0.10 (mysql-5.1.30 ndb-6.4.0)
+
+[mysqld(API)] 2 node(s)
+id=20 @192.168.0.20 (mysql-5.1.30 ndb-6.4.0)
+id=21 @192.168.0.21 (mysql-5.1.30 ndb-6.4.0)
+</programlisting>
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Step 7: Redistribute cluster data</title>
+
+ <para>
+ When a node group is created, existing data and indexes are
+ not automatically distributed to the new node group's
+ data nodes, as you can see by issuing the appropriate
+ <literal>REPORT</literal> command in the management client:
+
+<programlisting>
+ndb_mgm> <userinput>ALL REPORT MEMORY</userinput>
+
+Node 1: Data usage is 5%(177 32K pages of total 3200)
+Node 1: Index usage is 0%(108 8K pages of total 12832)
+Node 2: Data usage is 5%(177 32K pages of total 3200)
+Node 2: Index usage is 0%(108 8K pages of total 12832)
+<emphasis role="bold">Node 3: Data usage is 0%(0 32K pages of total 3200)
+Node 3: Index usage is 0%(0 8K pages of total 12832)
+Node 4: Data usage is 0%(0 32K pages of total 3200)
+Node 4: Index usage is 0%(0 8K pages of total 12832)</emphasis>
+</programlisting>
+
+ By using <command>ndb_desc</command> using the
+ <option>-p</option> option, which causes the output to include
+ partitioning information, you can see that the table still
+ uses only 2 partitions (bold text):
+
+<programlisting>
+shell> <userinput>ndb_desc -c 192.168.0.10 -d n ips -p</userinput>
+-- ips --
+Version: 1
+Fragment type: 9
+K Value: 6
+Min load factor: 78
+Max load factor: 80
+Temporary table: no
+Number of attributes: 6
+Number of primary keys: 1
+Length of frm data: 340
+Row Checksum: 1
+Row GCI: 1
+SingleUserMode: 0
+ForceVarPart: 1
+FragmentCount: 2
+TableStatus: Retrieved
+-- Attributes --
+id Bigint PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY AUTO_INCR
+country_code Char(2;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
+type Char(4;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
+ip_address Varchar(15;latin1_swedish_ci) NOT NULL AT=SHORT_VAR ST=MEMORY
+addresses Bigunsigned NULL AT=FIXED ST=MEMORY
+date Bigunsigned NULL AT=FIXED ST=MEMORY
+
+-- Indexes --
+PRIMARY KEY(id) - UniqueHashIndex
+PRIMARY(id) - OrderedIndex
+
+<emphasis role="bold">-- Per partition info --
+Partition Row count Commit count Frag fixed memory Frag varsized memory
+0 26086 26086 1572864 557056
+1 26329 26329 1605632 557056</emphasis>
+
+NDBT_ProgramExit: 0 - OK
+</programlisting>
+
+ You can cause the data to be redistributed among all of the
+ data nodes by performing, for each
+ <literal>NDBCLUSTER</literal> table, an <literal>ALTER ONLINE
+ TABLE ... REORGANIZE PARTITION</literal> statement in the
+ <command>mysql</command> client. After issuing the statement
+ <literal>ALTER ONLINE TABLE ips REORGANIZE
+ PARTITION</literal>, you can see using
+ <command>ndb_desc</command> that the data for this table is
+ now stored using 4 partitions, as shown here (with the
+ relevant portions of the output in bold type):
+
+<programlisting>
+shell> <userinput>ndb_desc -c 192.168.0.10 -d n ips -p</userinput>
+-- ips --
+Version: 16777217
+Fragment type: 9
+K Value: 6
+Min load factor: 78
+Max load factor: 80
+Temporary table: no
+Number of attributes: 6
+Number of primary keys: 1
+Length of frm data: 341
+Row Checksum: 1
+Row GCI: 1
+SingleUserMode: 0
+ForceVarPart: 1
+FragmentCount: 4
+TableStatus: Retrieved
+-- Attributes --
+id Bigint PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY AUTO_INCR
+country_code Char(2;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
+type Char(4;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
+ip_address Varchar(15;latin1_swedish_ci) NOT NULL AT=SHORT_VAR ST=MEMORY
+addresses Bigunsigned NULL AT=FIXED ST=MEMORY
+date Bigunsigned NULL AT=FIXED ST=MEMORY
+
+-- Indexes --
+PRIMARY KEY(id) - UniqueHashIndex
+PRIMARY(id) - OrderedIndex
+
+<emphasis role="bold">-- Per partition info --
+Partition Row count Commit count Frag fixed memory Frag varsized memory
+0 12981 52296 1572864 557056
+1 13236 52515 1605632 557056
+2 13105 13105 819200 294912
+3 13093 13093 819200 294912</emphasis>
+
+NDBT_ProgramExit: 0 - OK
+</programlisting>
+
+ <note>
+ <para>
+ Normally, <literal>ALTER [ONLINE] TABLE
+ <replaceable>table_name</replaceable> REORGANIZE
+ PARTITION</literal> is used with a list of partition
+ identifiers and a set of partition definitions to create a
+ new partitioning scheme for a table that has already been
+ explicitly partitioned. Its use here to redistribute data
+ onto a new MySQL Cluster node group is an exception in
+ this regard; when used in this way, only the name of the
+ table is used following the <literal>TABLE</literal>
+ keyword, and no other keywords or identifiers follow
+ <literal>REORGANIZE PARTITION</literal>.
+ </para>
+ </note>
+
+ Also for each table, the <literal>ALTER ONLINE TABLE</literal>
+ statement should be followed by an <literal>OPTIMIZE
+ TABLE</literal> to reclaim wasted space. You can obtain a list
+ of all <literal>NDBCLUSTER</literal> tables using the
+ following query against the
+ <literal>INFORMATION_SCHEMA.TABLES</literal> table:
+
+<programlisting>
+SELECT TABLE_SCHEMA, TABLE_NAME
+ FROM INFORMATION_SCHEMA.TABLES
+ WHERE ENGINE = 'NDBCLUSTER';
+</programlisting>
+
+ <note>
+ <para>
+ The <literal>INFORMATION_SCHEMA.TABLES.ENGINE</literal>
+ value for a MySQL Cluster table is always
+ <literal>NDBCLUSTER</literal>, regardless of whether the
+ <literal>CREATE TABLE</literal> statement used to create
+ the table (or <literal>ALTER TABLE</literal> statement
+ used to convert an existing table from a different storage
+ engine) used <literal>NDB</literal> or
+ <literal>NDBCLUSTER</literal> in its
+ <literal>ENGINE</literal> option.
+ </para>
+ </note>
+
+ You can see after performing these statements in the output of
+ <literal>ALL REPORT MEMORY</literal> that the data and indexes
+ are now redistributed between all cluster data nodes, as shown
+ here:
+
+<programlisting>
+ndb_mgm> <userinput>ALL REPORT MEMORY</userinput>
+
+Node 1: Data usage is 5%(176 32K pages of total 3200)
+Node 1: Index usage is 0%(76 8K pages of total 12832)
+Node 2: Data usage is 5%(176 32K pages of total 3200)
+Node 2: Index usage is 0%(76 8K pages of total 12832)
+Node 3: Data usage is 2%(80 32K pages of total 3200)
+Node 3: Index usage is 0%(51 8K pages of total 12832)
+Node 4: Data usage is 2%(80 32K pages of total 3200)
+Node 4: Index usage is 0%(50 8K pages of total 12832)
+</programlisting>
+
+ <note>
+ <para>
+ Since only one DDL operation on
+ <literal>NDBCLUSTER</literal> tables can be executed at a
+ time, you must wait for each <literal>ALTER ONLINE TABLE
+ ... REORGANIZE PARTITION</literal> statement to finish
+ before issuing the next one.
+ </para>
+ </note>
+ </para>
+
+ </formalpara>
+
+ </section>
+
+ </section>
+
</section>
Modified: trunk/refman-5.1/mysql-cluster-overview.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-overview.xml 2009-01-08 16:15:14 UTC (rev 13040)
+++ trunk/refman-5.1/mysql-cluster-overview.xml 2009-01-08 17:37:53 UTC (rev 13041)
Changed blocks: 1, Lines Added: 10, Lines Deleted: 0; 894 bytes
@@ -429,6 +429,16 @@
nodes.
</para>
</note>
+
+ <para>
+ Prior to MySQL Cluster NDB 6.4.0, it was not possible to add
+ new data nodes to a MySQL Cluster without shutting down the
+ cluster completely and reloading all of its data. Beginning
+ with MySQL Cluster NDB 6.4.0, you can add new node groups (and
+ thus new data nodes) to a running MySQL Cluster — see
+ <xref linkend="mysql-cluster-online-add-node"/>, for
+ information about how this can be done.
+ </para>
</listitem>
<listitem>
Modified: trunk/refman-5.1/mysql-cluster-roadmap.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-roadmap.xml 2009-01-08 16:15:14 UTC (rev 13040)
+++ trunk/refman-5.1/mysql-cluster-roadmap.xml 2009-01-08 17:37:53 UTC (rev 13041)
Changed blocks: 2, Lines Added: 11, Lines Deleted: 18; 2345 bytes
@@ -1321,22 +1321,12 @@
<para>
The following list provides an overview of significant feature
- additions and changes first made in MySQL Cluster NDB 6.4. For
- more detailed information about all feature changes and bugfixes
- made in MySQL Cluster NDB 6.4, see
+ additions and changes made in or planned for MySQL Cluster NDB
+ 6.4. For more detailed information about all feature changes and
+ bugfixes made in MySQL Cluster NDB 6.4, see
<xref linkend="mysql-cluster-news-6-4"/>.
</para>
- <note>
- <para>
- Some features planned for MySQL Cluster NDB 6.4 are still in
- early development and not all of these have yet been finalized.
- For this reason, the contents of this section are subject to
- change without warning. You should check this section frequently
- for new and updated information.
- </para>
- </note>
-
<itemizedlist>
<listitem>
@@ -1360,13 +1350,16 @@
<title>Ability to add nodes and node groups online</title>
<para>
- It is now possible to add new node groups (and thus add new
- data nodes) to a running MySQL Cluster without shutting down
- the cluster. As part of enabling this feature, a new command
+ Beginning with MySQL Cluster NDB 6.4.0, it is possible to
+ add new node groups (and thus new data nodes) to a running
+ MySQL Cluster without shutting down and reloading the
+ cluster. As part of enabling this feature, a new command
<literal>CREATE NODEGROUP</literal> has been added to the
cluster management client and the functionality of the
- <literal>ALTER ONLINE TABLE ... ADD PARTITION</literal> SQL
- statement has been extended.
+ <literal>ALTER ONLINE TABLE ... REORGANIZE
+ PARTITION</literal> SQL statement has been extended. For
+ more information, see
+ <xref linkend="mysql-cluster-online-add-node"/>.
</para>
</formalpara>
Modified: trunk/refman-5.1/sql-syntax-data-definition.xml
===================================================================
--- trunk/refman-5.1/sql-syntax-data-definition.xml 2009-01-08 16:15:14 UTC (rev 13040)
+++ trunk/refman-5.1/sql-syntax-data-definition.xml 2009-01-08 17:37:53 UTC (rev 13041)
Changed blocks: 2, Lines Added: 46, Lines Deleted: 1; 3218 bytes
@@ -753,7 +753,7 @@
| ADD PARTITION (<replaceable>partition_definition</replaceable>)
| DROP PARTITION <replaceable>partition_names</replaceable>
| COALESCE PARTITION <replaceable>number</replaceable>
- | REORGANIZE PARTITION <replaceable>partition_names</replaceable> INTO (<replaceable>partition_definitions</replaceable>)
+ | REORGANIZE PARTITION [<replaceable>partition_names</replaceable> INTO (<replaceable>partition_definitions</replaceable>)]
| ANALYZE PARTITION <replaceable>partition_names</replaceable>
| CHECK PARTITION <replaceable>partition_names</replaceable>
| OPTIMIZE PARTITION <replaceable>partition_names</replaceable>
@@ -2117,6 +2117,51 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ This statement may also be used without the
+ <literal><replaceable>partition_names</replaceable> INTO
+ (<replaceable>partition_definitions</replaceable>)</literal>
+ option on tables that are automatically partitioned using
+ <literal>HASH</literal> partitioning in order to force
+ redistribution of data. (Currently, only
+ <literal>NDBCLUSTER</literal> tables are automatically
+ partitioned in this way.) This is useful in MySQL
+ Cluster NDB 6.4.0 and later where, after you have added new
+ MySQL Cluster data nodes online to an existing MySQL
+ Cluster, you wish to redistribute existing MySQL Cluster
+ table data to the new data nodes. In such cases, you
+ should invoke the satement with the
+ <literal>ONLINE</literal> option; in words words, as shown
+ here:
+ </para>
+
+<programlisting>
+ALTER ONLINE TABLE <replaceable>table</replaceable> REORGANIZE PARTITION;
+</programlisting>
+
+ <para>
+ You cannot perform other DDL concurrently with online
+ table reorganization — that is, no other DDL
+ statements can be issued while an <literal>ALTER ONLINE
+ TABLE ... REORGANIZE PARTITION</literal> statement is
+ executing. For more information about adding MySQL Cluster
+ data nodes online, see
+ <xref linkend="mysql-cluster-online-add-node"/>.
+ </para>
+
+ <para>
+ Attempting to use <literal>REORGANIZE PARTITION</literal>
+ without the
+ <literal><replaceable>partition_names</replaceable> INTO
+ (<replaceable>partition_definitions</replaceable>)</literal>
+ option on explicitly partitioned tables results in the
+ error <errortext>REORGANIZE PARTITION without parameters
+ can only be used on auto-partitioned tables using HASH
+ partitioning</errortext>.
+ </para>
+ </listitem>
+
</itemizedlist>
<note>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r13041 - in trunk: dynamic-docs/changelog mysqlqb refman-5.1 | jon | 8 Jan |
