| List: | Internals | « Previous MessageNext Message » | |
| From: | jon | Date: | July 29 2005 1:32pm |
| Subject: | bk commit - mysqldoc@docsrva tree (jon:1.3130) | ||
| View as plain text | |||
Below is the list of changes that have just been committed into a local mysqldoc repository of jon. When jon does a push these changes will be propagated to the main repository and, within 24 hours after the push, to the public repository. For information on how to access the public repository see http://www.mysql.com/doc/I/n/Installing_source_tree.html ChangeSet 1.3130 05/07/29 21:32:51 jon@stripped +3 -0 RefMan-5.0 Cluster chapter: Remaining RefMan-5.0 edits (except for Cluster Limitations section). RefMan-5.0 titles.ent: Made overly generic section title more specific. Updated Status. refman-5.0/titles.ent 1.41 05/07/29 21:32:50 jon@stripped +1 -1 Made overly generic title more specific. refman-5.0/ndbcluster.xml 1.23 05/07/29 21:32:49 jon@stripped +588 -437 Remaining RefMan-5.0 edits (except for Cluster Limitations section) refman-5.0/Status 1.14 05/07/29 21:32:49 jon@stripped +4 -2 Updating... # This is a BitKeeper patch. What follows are the unified diffs for the # set of deltas contained in the patch. The rest of the patch, the part # that BitKeeper cares about, is below these diffs. # User: jon # Host: gigan. # Root: /home/jon/bk/mysqldoc --- 1.22/refman-5.0/ndbcluster.xml 2005-07-29 12:37:56 +10:00 +++ 1.23/refman-5.0/ndbcluster.xml 2005-07-29 21:32:49 +10:00 @@ -9137,7 +9137,10 @@ </orderedlist> -<!-- Ref: NDB client apps: ndb_mgmd, ndb_mgm, ndbd, mysqld --> +<!-- + TODO: Provide pointers to info on NDB client apps: ndb_mgmd, + ndb_mgm, ndbd, mysqld [js] +--> </listitem> <listitem> @@ -9147,18 +9150,21 @@ </para> <para> - As of MySQL 4.1.12, MySQL Cluster is officially supported on - Linux, Mac OS X, and Solaris. We are working to add Cluster - support for other platforms, including Windows (expected in - MySQL 5.0), and our goal is eventually to offer MySQL Cluster - on all platforms for which MySQL itself is supported. + In MySQL 5.0, MySQL Cluster is officially supported on Linux, + Mac OS X, and Solaris. We are working to add Cluster support + for other platforms, including Windows, and our goal is + eventually to offer MySQL Cluster on all platforms for which + MySQL itself is supported. </para> <para> It may be possible to run Cluster processes on other operating - systems (including Windows), but Cluster on any but the three - platforms mentioned here should be considered alpha software - only and not for production use. + systems. We have had reports from users who say that they have + run Cluster successfully on FreeBSD. However, Cluster on any + but the three platforms mentioned here should be considered + alpha software (at best), cannot be guaranteed relaiable in a + production setting, and <emphasis>is not supported by MySQL + AB</emphasis>. </para> </listitem> @@ -9167,7 +9173,7 @@ <emphasis>What are the hardware requirements for running MySQL Cluster?</emphasis> </para> - +<!-- TODO: Add pointers to SCI, Fragments, Replicas. [js] --> <para> Cluster should run on any platform for which NDB-enabled binaries are available. Naturally, faster CPUs and more memory @@ -9179,8 +9185,6 @@ via a standard TCP/IP network and hardware. For SCI support, special networking hardware is required. </para> - -<!-- Ref: SCI, Fragments, Replicas --> </listitem> <listitem> @@ -9191,12 +9195,13 @@ </para> <para> - It is important to keep in mind that communications between - the nodes in a MySQL Cluster are not secure; they are neither - encrypted nor safeguarded by any other protective mechanism. - The most secure configuration for a cluster is in a private - network behind a firewall, with no direct access to any - Cluster data or management nodes from outside. + It is important to keep in mind that <emphasis>communications + between the nodes in a MySQL Cluster are not + secure</emphasis>; they are neither encrypted nor safeguarded + by any other protective mechanism. The most secure + configuration for a cluster is in a private network behind a + firewall, with no direct access to any Cluster data or + management nodes from outside. </para> <para> @@ -9205,8 +9210,8 @@ and implemented with the assumption that it would be run under conditions guaranteeing dedicated high-speed connectivity such as that found in a LAN setting using 100 Mbps or gigabit - Ethernet. We neither test nor warrant its performance using - anything slower than this. + Ethernet (preferably the latter). We neither test nor warrant + its performance using anything slower than this. </para> </listitem> @@ -9221,37 +9226,37 @@ configure the cluster itself, only standard (My)SQL queries and commands are required for: </para> + +<!-- TODO: Add pointers to NDB client commands/options. [js] --> <itemizedlist> <listitem> <para> - creating, altering, and dropping tables + Creating, altering, and dropping tables </para> </listitem> <listitem> <para> - inserting, updating, and deleting table data + Inserting, updating, and deleting table data </para> </listitem> <listitem> <para> - creating, changing, and dropping primary and unique + Creating, changing, and dropping primary and unique indexes </para> </listitem> <listitem> <para> - configuring and managing SQL nodes (MySQL servers) + Configuring and managing SQL nodes (MySQL servers) </para> </listitem> </itemizedlist> - -<!-- Ref: NDB clients --> </listitem> <listitem> @@ -9279,7 +9284,7 @@ <listitem> <para> From a system shell prompt, use <command>perror --ndb - <replaceable>error-code</replaceable></command>. + <replaceable>error_code</replaceable></command>. </para> </listitem> @@ -9293,15 +9298,16 @@ </para> <para> - Yes. MySQL Cluster is enabled for tables created with the NDB - storage engine, which supports transactions. NDB is the only - MySQL storage engine which supports clustering. + Yes. MySQL Cluster is enabled for tables created with the + <literal>NDB</literal> storage engine, which supports + transactions. <literal>NDB</literal> is the only MySQL storage + engine which supports clustering. </para> </listitem> <listitem> <para> - <emphasis>What does "NDB" mean?</emphasis> + <emphasis>What does <quote>NDB</quote> mean?</emphasis> </para> <para> @@ -9309,11 +9315,22 @@ <emphasis role="bold">D</emphasis>ata<emphasis role="bold">b</emphasis>ase". </para> -<!-- This question needs to remain commented out until answered. --> - -<!-- @item --> - -<!-- @emph{How do I continue to send queries if one of the SQL nodes fails?} --> +<!-- + TODO: This question needs to remain commented out until + answered. [js] +--> +<!-- + <listitem> + <para> + <emphasis>How do I continue to send queries in the event that + one of the SQL nodes fails?</emphasis> + </para> + + <para> + ... + </para> + </listitem> +--> </listitem> <listitem> @@ -9323,27 +9340,31 @@ </para> <para> - Cluster is supported in the MySQL-max binaries from version - 4.1.3 onwards. You can determine whether or not your server - binary has NDB support using either of the commands - <literal>SHOW VARIABLES LIKE 'have_%';</literal> or - <literal>SHOW ENGINES;</literal>. (See + Cluster is supported in all MySQL-max binaries in the 5.0 + release series, except as noted in the following paragraph. + You can determine whether or not your server has NDB support + using either of the commands <literal>SHOW VARIABLES LIKE + 'have_%';</literal> or <literal>SHOW ENGINES;</literal>. (See <xref linkend="mysqld-max"/> for more information.) </para> <para> - Linux users, please note that NDB is - <emphasis role="bold">not</emphasis> included in the 4.1.x - RPMs; you should use the binaries supplied as - <literal>.tar.gz</literal> archives in the - <ulink url="http://dev.mysql.com/downloads/">MySQL Downloads - area</ulink> instead. You can also obtain NDB support by - compiling the <literal>-max</literal> binaries from source, - but it is not necessary to do so simply to use MySQL Cluster. - Beginning with MySQL 5.0.4, there are separate RPM packages - for the NDB storage engine and accoompanying management and - other tools; see the NDB RPM Downloads section of the MySQL - 5.0 Downloads page for these. + Linux users, please note that <literal>NDB</literal> is + <emphasis>not</emphasis> included in the standard MySQL server + RPMs. Beginning with MySQL 5.0.4, there are separate RPM + packages for the NDB storage engine and accoompanying + management and other tools; see the NDB RPM Downloads section + of the MySQL 5.0 Downloads page for these. (Prior to 5.0.4, + you had to use the <literal>-max</literal> binaries supplied + as <filename>.tar.gz</filename> archives. This is still + possible, but is not required, so you can use your Linux + distribution's RPM manager if you prefer.) You can also obtain + NDB support by compiling the <literal>-max</literal> binaries + from source, but it is not necessary to do so simply to use + MySQL Cluster. To download the latest binary, RPM, or + source distibution in the MySQL 5.0 series, visit + <ulink url="http://dev.mysql.com/downloads/mysql/5.0.html"/>. + </para> </listitem> @@ -9370,9 +9391,7 @@ </para> <programlisting> - (SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfDataNodes - </programlisting> <para> @@ -9388,10 +9407,9 @@ <listitem> <para> - In MySQL 4.1, each primary key or hash index created for - an NDBCluster table requires 25 bytes storage, plus the - size of the key, per record. In MySQL 5.0, this amount is - reduced to 21-25 bytes per record. These indexes use + Each primary key or hash index created for + an <literal>NDBCluster</literal> table requires 21-25 + bytes per record. These indexes use <literal>IndexMemory</literal>. </para> </listitem> @@ -9409,9 +9427,8 @@ ordered index, unless this index is created with <literal>USING HASH</literal>. In other words, if created without <literal>USING HASH</literal>, a primary key or - unique index on a Cluster table will take up 35 bytes - (plus the size of the key) per record in MySQL 4.1, and - 31-35 bytes per record in MySQL 5.0. + unique index on a Cluster table will take up 31-35 bytes + per record in MySQL 5.0. </para> <para> @@ -9437,16 +9454,18 @@ </para> <para> - As of MySQL 4.1.11/MySQL 5.0.4-beta there is no easy way - determine exactly how much memory is being used for storage of - Cluster indexes; however, warnings are written to the Cluster - log when 80% of available DataMemory or IndexMemory is in use, - and again when 85%, 90%, and so on is in use. + Currently there is no easy way in MySQL 5.0 to determine + exactly how much memory is being used for storage of Cluster + indexes at any given time; however, warnings are written to + the Cluster log when 80% of available + <literal>DataMemory</literal> and/or + <literal>IndexMemory</literal> is in use, and again when 85%, + 90%, and so on is in use. </para> <para> We often see questions from users who report that, when - they're trying to populate a Cluster database, the loading + they are trying to populate a Cluster database, the loading process terminates prematurely and an error message like this one is observed: </para> @@ -9458,8 +9477,10 @@ <para> When this occurs, the cause is very likely to be that your setup does not provide sufficient RAM for all table data and - all indexes, <emphasis>including the primary key required by - NDB</emphasis>. + all indexes, <emphasis>including the primary key required by + the <literal>NDB</literal> storage engine and automatically + created in the event that the table definition does not + include the definition of a primary key</emphasis>. </para> <para> @@ -9476,8 +9497,9 @@ <listitem> <para> - <emphasis>In the event of a catstrophic failure --- say, for - instance, the whole city lost power AND my UPS failed --- + <emphasis>In the event of a catastrophic failure — say, + for instance, the whole city loses power + <emphasis role="bold">and</emphasis> my UPS fails — would I lose all my data?</emphasis> </para> @@ -9486,20 +9508,22 @@ possible that some data could be lost in the event of a catastrophe, this should be quite limited. Data loss can be further reduced by minimising the number of operations per - transaction. + transaction. (It is not a good idea to perform large numbers + of operations per transaction in any case.) </para> </listitem> <listitem> <para> - <emphasis>Is it possible to use FULLTEXT indexes with - Cluster?</emphasis> + <emphasis>Is it possible to use <literal>FULLTEXT</literal> + indexes with Cluster?</emphasis> </para> <para> - <literal>FULLTEXT</literal> indexing is not currently (MySQL - 4.1.9) supported by the NDB storage engine. We are working to - add this capability in a future release. + <literal>FULLTEXT</literal> indexing is not currently + supported by the <literal>NDB</literal> storage engine, or by + any storage engine other than <literal>MyISAM</literal>. We + are working to add this capability in a future release. </para> </listitem> @@ -9544,40 +9568,43 @@ <listitem> <para> - Making a complete backup of all Cluster data + Make a complete backup of all Cluster data </para> </listitem> <listitem> <para> - Complete shutting down the cluster and all cluster node + Completely shut down the cluster and all cluster node processes </para> </listitem> <listitem> <para> - Restarting the cluster, using the - <command>--initial</command> startup option + Restart the cluster, using the <option>--initial</option> + startup option </para> </listitem> <listitem> <para> - Restoring all cluster data from the backup + Restore all cluster data from the backup </para> </listitem> </itemizedlist> <para> - In future, we hope to implement "hot" reconfiguration - capability for MySQL Cluster in order to minimize (if not - eliminate) requirements for restarting the cluster when adding - new nodes. + In future, we hope to implement <quote>hot</quote> + reconfiguration capability for MySQL Cluster in order to + minimize (if not eliminate) the requirement for restarting the + cluster when adding new nodes. </para> </listitem> - +<!-- + TODO: Check this list against mysql-cluster-limitations once that + section has been reviewed for 5.0. [js] +--> <listitem> <para> <emphasis>Are there any limitations that I should be aware of @@ -9585,7 +9612,7 @@ </para> <para> - NDB tables in MySQL 4.1 are subject to the following + <literal>NDB</literal> tables in MySQL are subject to the following limitations: </para> @@ -9654,8 +9681,7 @@ </itemizedlist> <para> - We expect to lift many of these restrictions in MySQL 5.0. For - additional information on current limitations, see + For additional information on Cluster limitations, see <xref linkend="mysql-cluster-limitations"/>. </para> </listitem> @@ -9671,9 +9697,10 @@ with any other version of MySQL. Other than the limitation mentioned in the previous question, the only other special requirement is that any tables to be included in the cluster - must use the NDB storage engine. This means that the tables - must be created with the option <command>ENGINE=NDB</command> - or <command>ENGINE=NDBCLUSTER</command>. + must use the <literal>NDB</literal> storage engine. This means + that the tables must be created with the option + <command>ENGINE=NDB</command> or + <command>ENGINE=NDBCLUSTER</command>. </para> </listitem> @@ -9699,33 +9726,34 @@ <listitem> <para> - <emphasis>What is an arbitrator?</emphasis> + <emphasis>What is an <quote>arbitrator</quote>?</emphasis> </para> <para> If one or more nodes in a cluster fail, it is possible that - not all cluster nodes will not be able to "see" one another. - In fact, it is possible that two sets of nodes might become - isolated from one another in a network partitioning, also - known as a "split brain" scenario. This type of situation is - undesirable because each set of nodes tries to behave as - though it is the entire cluster. + not all cluster nodes will not be able to <quote>see</quote> + one another. In fact, it is possible that two sets of nodes + might become isolated from one another in a network + partitioning, also known as a <quote>split brain</quote> + scenario. This type of situation is undesirable because each + set of nodes tries to behave as though it is the entire + cluster. </para> <para> When cluster nodes go down, there are two possibilities. If more than 50% of the remaining nodes can communicate with each - other, then we have what is sometimes called a "majority - rules" situation, and this set of nodes is considered to be - the cluster. The arbitrator comes into play when there is an - even number of nodes: in such a case, the set of nodes to + other, then we have what is sometimes called a <quote>majority + rules</quote> situation, and this set of nodes is considered + to be the cluster. The arbitrator comes into play when there + is an even number of nodes: in such cases, the set of nodes to which the arbitrator belongs is considered to be the cluster, and nodes not belonging to this set are shut down. </para> <para> - The above is somewhat simplified; a more complete explanation - taking into account node groups follows below: + The above information is somewhat simplified; a more complete + explanation taking into account node groups follows below: </para> <para> @@ -9733,22 +9761,22 @@ partitioning is not an issue, because no one portion of the cluster can form a functional cluster. The real problem arises when no single node group has all its nodes alive, in which - case network partitioning (the "split-brain" scenario) becomes - possible. Then an arbitrator is required. All cluster nodes - recognise the same node as the arbitrator, which is normally - the management server; however, it is possible to configure - any of the MySQL Servers in the cluster to act as the - arbirtrator instead. The arbitrator accepts the first set of - cluster nodes to contact it, and tells the remaining set to - die. Arbitrator selection is controlled by the - <literal>ArbitrationRank</literal> configuration parameter for - MySQL Server and management server nodes. (See - <xref linkend="mysql-cluster-mgm-definition"/> for details.) - It should also be noted that the role of arbitrator does not - in and of itself impose any heavy demands upon the host so - designated, and thus the artitrator host does not need to be - particularly fast or to have extra memory especially for this - purpose. + case network partitioning (the <quote>split-brain</quote> + scenario mentioned above) becomes possible. Then an arbitrator + is required. All cluster nodes recognise the same node as the + arbitrator, which is normally the management server; however, + it is possible to configure any of the MySQL Servers in the + cluster to act as the arbitrator instead. The arbitrator + accepts the first set of cluster nodes to contact it, and + tells the remaining set to die. Arbitrator selection is + controlled by the <literal>ArbitrationRank</literal> + configuration parameter for MySQL Server and management server + nodes. (See <xref linkend="mysql-cluster-mgm-definition"/> + for details.) It should also be noted that the role of + arbitrator does not in and of itself impose any heavy demands + upon the host so designated, and thus the artitrator host does + not need to be particularly fast or to be supplied with extra + memory especially for this purpose. </para> </listitem> @@ -9760,17 +9788,18 @@ <para> MySQL Cluster supports all of the usual MySQL column types, - with the exception of those associated with MySQL's - <xref linkend="spatial-extensions-in-mysql"/>. In addition, + with the exception of those associated with MySQL's spatial + extensions. (See + <xref linkend="spatial-extensions-in-mysql"/>.) In addition, there are some differences with regard to indexes when used with NDB tables. <emphasis role="bold">Note</emphasis>: In - MySQL 4.1 and 5.0, Cluster tables (that is, tables created - with <literal>ENGINE=NDBCLUSTER</literal>) have only - fixed-width rows. This means that (for example) each record - containing a <literal>VARCHAR(255)</literal> column will will - require 256 bytes of storage for that column, regardless of - the size of the data stored therein. This issue is expected to - be fixed in MySQL 5.1. + MySQL 5.0, Cluster tables (that is, tables created with + <literal>ENGINE=NDBCLUSTER</literal>) have only fixed-width + rows. This means that (for example) each record containing a + <literal>VARCHAR(255)</literal> column will will require 256 + bytes of storage for that column, regardless of the size of + the data stored therein. This issue is expected to + be fixed in a future MySQL release series. </para> <para> @@ -9813,11 +9842,11 @@ </listitem> </orderedlist> - +<!-- TODO: Add pointer to additional info. [js] --> <para> - Each of these commands must be run from a shell on the machine - housing the affected node. You can verify the the cluster is - running by starting the MGM management client + Each of these commands must be run from a system shell on the + machine housing the affected node. You can verify the the + cluster is running by starting the MGM management client <command>ndb_mgm</command> on the machine housing the MGM node. </para> @@ -9872,8 +9901,7 @@ nodes to take over in the evnt that the primary MGM node fails. </para> - -<!-- Ref: Cluster Configuration --> +<!-- TODO: Add pointers to cluster configuration material. [js] --> </listitem> <listitem> @@ -9885,9 +9913,8 @@ <para> Yes, so long as all machines and operating systems are the same endian. It is also possible to use different MySQL - Cluster releases on different nodes (for example, 4.1.8 on - some nodes and 4.1.9 on others); however, we recommend this be - done only as part of a rolling upgrade procedure. + Cluster releases on different nodes; however, we recommend + this be done only as part of a rolling upgrade procedure. </para> </listitem> @@ -9898,7 +9925,7 @@ </para> <para> - Yes, it is possible to do this. In the case of multiple stdata + Yes, it is possible to do this. In the case of multiple data nodes, each node must use a different data directory. If you want to run multiple SQL nodes on one machine, then each instance of <command>mysqld</command> must use a different @@ -9912,29 +9939,34 @@ </para> <para> - Yes, it's possible to use DNS and DHCP for cluster hosts. + Yes, it is possible to use DNS and DHCP for cluster hosts. However, if your application requires "five nines" availability, we recommend using fixed IP addresses. This is because making communication between Cluster hosts dependent on such services introduces additional points of failure, and the fewer of these, the better. </para> + </listitem> -<!-- TODO: Need to answer this question --> - -<!-- @item --> - -<!-- @emph{How do I handle MySQL users in a Cluster having multiple MySQL --> - -<!-- servers?} --> +<!-- TODO: Need to answer this question. [js] --> +<!-- + <listitem> + <para> + <emphasis>How do I handle MySQL users in a Cluster having + multiple MySQL servers?</emphasis> + </para> + + <para> + </para> </listitem> + --> </itemizedlist> -<!-- ## END CLUSTER FAQ ## --> - </section> +<!-- ## END CLUSTER FAQ ## --> + <section id="mysql-cluster-glossary"> <title id='title-mysql-cluster-glossary'>&title-mysql-cluster-glossary;</title> @@ -9950,24 +9982,45 @@ <listitem> <para> - <emphasis role="bold">Cluster</emphasis>: In its generic - sense, a cluster is a set of computers functioning as a unit - and working together to accomplish a single task. - <emphasis role="bold">NDB Cluster</emphasis> is the storage - engine used by MySQL to implement data storage, retrieval, and - management distributed amongst several computers. - <emphasis role="bold">MySQL Cluster </emphasis>refers to a - group of computers working together using the NDB engine to - support a distributed MySQL database in a - <emphasis role="bold">shared-nothing architecture</emphasis> - using <emphasis role="bold">in-memory storage</emphasis>. + <emphasis role="bold">Cluster</emphasis>: + </para> + + <para> + In its generic sense, a cluster is a set of computers + functioning as a unit and working together to accomplish a + single task. + </para> + + <para> + <emphasis role="bold"><literal>NDB Cluster</literal></emphasis>: + </para> + + <para> + This is the storage engine used in MySQL to implement data + storage, retrieval, and management distributed amongst several + computers. + </para> + + <para> + <emphasis role="bold">MySQL Cluster</emphasis>: + </para> + + <para> + This refers to a group of computers working together using the + <literal>NDB</literal> storage engine to support a distributed + MySQL database in a <emphasis>shared-nothing + architecture</emphasis> using <emphasis>in-memory + storage</emphasis>. </para> </listitem> <listitem> <para> - <emphasis role="bold">Configuration files</emphasis>: Text - files containing directives and information regarding the + <emphasis role="bold">Configuration files</emphasis>: + </para> + + <para> + Text files containing directives and information regarding the cluster, its hosts, and its nodes. These are read by the cluster's management nodes when the cluster is started. See <xref linkend="mysql-cluster-config-file"/> for details. @@ -9976,78 +10029,101 @@ <listitem> <para> - <emphasis role="bold">Backup</emphasis>: A complete copy of - all cluster data, transactions and logs, saved to disk or - other long-term storage. + <emphasis role="bold">Backup</emphasis>: + </para> + + <para> + A complete copy of all cluster data, transactions and logs, + saved to disk or other long-term storage. </para> </listitem> <listitem> <para> - <emphasis role="bold">Restore</emphasis>: Returning the - cluster to a previous state as stored in a backup. + <emphasis role="bold">Restore</emphasis>: + </para> + + <para> + Returning the cluster to a previous state, as stored in a + backup. </para> </listitem> <listitem> <para> - <emphasis role="bold">Checkpoint</emphasis>: Generally - speaking, when data is saved to disk, it is said that a - checkpoint has been reached. More specific to Cluster, it is a - point in time where all committed transactions are stored on - disk. With regard to the NDB storage engine, there are two - sorts of checkpoints which work together to ensure that a - consistent view of the cluster's data is maintained: + <emphasis role="bold">Checkpoint</emphasis>: </para> + + <para> + Generally speaking, when data is saved to disk, it is said + that a checkpoint has been reached. More specific to Cluster, + it is a point in time where all committed transactions are + stored on disk. With regard to the <literal>NDB</literal> + storage engine, there are two sorts of checkpoints which work + together to ensure that a consistent view of the cluster's + data is maintained: - <itemizedlist> - - <listitem> - <para> - <emphasis role="bold">Local Checkpoint (LCP)</emphasis>: - This is a checkpoint that is specific to a single node; - however, LCP's take place for all nodes in the cluster - more or less concurrently. An LCP involves saving all of a - node's data to disk, and so usually occurs every few - minutes. The precise interval varies, and depends upon the - amount of data stored by the node, the level of cluster - activity, and other factors. - </para> - </listitem> - - <listitem> - <para> - <emphasis role="bold">Global Checkpoint (GCP)</emphasis>: - A GCP occurs every few seconds, when transactions for all - nodes are synchronised and the redo-log is flushed to - disk. - </para> - </listitem> - - </itemizedlist> + <itemizedlist> + + <listitem> + <para> + <emphasis role="bold">Local Checkpoint (LCP)</emphasis>: + </para> + + <para> + This is a checkpoint that is specific to a single node; + however, LCP's take place for all nodes in the cluster + more or less concurrently. An LCP involves saving all of + a node's data to disk, and so usually occurs every few + minutes. The precise interval varies, and depends upon the + amount of data stored by the node, the level of cluster + activity, and other factors. + </para> + </listitem> + + <listitem> + <para> + <emphasis role="bold">Global Checkpoint (GCP)</emphasis>: + </para> + + <para> + A GCP occurs every few seconds, when transactions for all + nodes are synchronised and the redo-log is flushed to + disk. + </para> + </listitem> + + </itemizedlist> + </para> </listitem> <listitem> <para> - <emphasis role="bold">Cluster host</emphasis>: A computer - making up part of a MySQL Cluster. A cluster has both a - <emphasis>physical</emphasis> structure and a + <emphasis role="bold">Cluster host</emphasis>: + </para> + + <para> + A computer making up part of a MySQL Cluster. A cluster has + both a <emphasis>physical</emphasis> structure and a <emphasis>logical</emphasis> structure. Physically, the cluster consists of a number of computers, known as - <emphasis role="bold">cluster hosts</emphasis> (or more simply - as <emphasis role="bold">hosts</emphasis>). See also - <emphasis role="bold">Node</emphasis>, - <emphasis role="bold">Node group</emphasis>. + <firstterm>cluster hosts</firstterm> (or more simply as + <firstterm>hosts</firstterm>. See also + <emphasis role="bold">Node</emphasis> and + <emphasis role="bold">Node group</emphasis> below. </para> </listitem> <listitem> <para> - <emphasis role="bold">Node</emphasis>: This refers to a - logical or functional unit of MySQL Cluster, sometimes also - referred to as a <emphasis role="bold">cluster - node</emphasis>. In the context of MySQl Cluster, we use the - term <emphasis role="bold">node</emphasis> to indicate a + <emphasis role="bold">Node</emphasis>: + </para> + + <para> + This refers to a logical or functional unit of MySQL Cluster, + and is sometimes also referred to as a <firstterm>cluster + node</firstterm>. In the context of MySQl Cluster, we use the + term <quote>node</quote> to indicate a <emphasis>process</emphasis> rather than a physical component of the cluster. There are three node types required to implement a working MySQL Cluster. These are: @@ -10058,7 +10134,10 @@ <listitem> <para> <emphasis role="bold">Management (MGM) nodes</emphasis>: - Manages the other nodes within the MySQL Cluster. It + </para> + + <para> + Manages the other nodes within the MySQL Cluster. It provides configuration data to the other nodes; starts and stops nodes; handles network partitioning; creates backups and restores from them, and so forth. @@ -10068,7 +10147,10 @@ <listitem> <para> <emphasis role="bold">SQL (MySQL server) nodes</emphasis>: - Instances of MySQL Server which serve as front ends to + </para> + + <para> + Instances of MySQL Server which serve as front ends to data kept in the cluster's <emphasis role="bold">data nodes</emphasis>. Clients desiring to store, retrieve, or update data can access an SQL node just as they would any @@ -10083,13 +10165,15 @@ <listitem> <para> - <emphasis role="bold">Data nodes</emphasis>: These nodes - store the actual data. Table data fragments are stored in - a set of node groups; each node group stores a different - subset of the table data. Each of the nodes making up a - node group stores a replica of the fragment for which that - node group is responsible. Currently a single cluster can - support up to 48 data nodes total. + <emphasis role="bold">Data nodes</emphasis>: + </para> + <para> + These nodes store the actual data. Table data fragments + are stored in a set of node groups; each node group stores + a different subset of the table data. Each of the nodes + making up a node group stores a replica of the fragment + for which that node group is responsible. Currently a + single cluster can support up to 48 data nodes total. </para> </listitem> @@ -10099,12 +10183,12 @@ It is possible for more than one node to co-exist on a single machine. (In fact, it is even possible to set up a complete cluster on one machine, although one would almost certainly - not want to do this in a production environment.) It may be - helpful to remember that, when working with MySQL Cluster, - <emphasis role="bold">host</emphasis> refers to a physical - component of the cluster whereas a - <emphasis role="bold">node</emphasis> is a logical or - functional component (that is, a process). + <emphasis>not</emphasis> want to do this in a production + environment.) It may be helpful to remember that, when working + with MySQL Cluster, the term <emphasis>host</emphasis> refers + to a physical component of the cluster whereas a + <emphasis>node</emphasis> is a logical or functional component + (that is, a process). </para> <para> @@ -10120,36 +10204,48 @@ <listitem> <para> - <emphasis role="bold">Node group</emphasis>: A set of data - nodes. All data nodes in a node group contain the same data - (fragments), and all nodes in a single group should reside on - different hosts. It is possible to control which nodes belong - to which node groups. + <emphasis role="bold">Node group</emphasis>: + </para> + + <para> + A set of data nodes. All data nodes in a node group contain + the same data (fragments), and all nodes in a single group + should reside on different hosts. It is possible to control + which nodes belong to which node groups. </para> </listitem> <listitem> <para> - <emphasis role="bold">Node failure</emphasis>: MySQL Cluster - is not solely dependent upon the functioning of any single - node making up the cluster; the cluster can continue to run if - one or more nodes fail. The precise number of node failures - that the cluster can tolerate depends upon the number of nodes - and the cluster's configuration. + <emphasis role="bold">Node failure</emphasis>: + </para> + + <para> + MySQL Cluster is not solely dependent upon the functioning of + any single node making up the cluster; the cluster can + continue to run if one or more nodes fail. The precise number + of node failures that a given cluster can tolerate depends + upon the number of nodes and the cluster's configuration. </para> </listitem> <listitem> <para> - <emphasis role="bold">Node restart</emphasis>: The process of - restarting a failed cluster node. + <emphasis role="bold">Node restart</emphasis>: + </para> + + <para> + The process of restarting a failed cluster node. </para> </listitem> <listitem> <para> - <emphasis role="bold">Initial node restart</emphasis>: The - process of starting a cluster node with its filesystem + <emphasis role="bold">Initial node restart</emphasis>: + </para> + + <para> + The process of starting a cluster node with its filesystem removed. This is sometimes used in the course of software upgrades and in other special circumstances. </para> @@ -10158,122 +10254,162 @@ <listitem> <para> <emphasis role="bold">System crash</emphasis> (or - <emphasis role="bold">system failure</emphasis>): This can - occur when so many cluster nodes have failed that the + <emphasis role="bold">system failure</emphasis>): + </para> + + <para> + This can occur when so many cluster nodes have failed that the cluster's state can no longer be guaranteed. </para> </listitem> <listitem> <para> - <emphasis role="bold">System restart</emphasis>: The process - of restarting the cluster and reinitialising its state from - disk logs and checkpoints. This is required after either a - planned or an unplanned shutdown of the cluster. + <emphasis role="bold">System restart</emphasis>: + </para> + + <para> + The process of restarting the cluster and reinitialising its + state from disk logs and checkpoints. This is required after + either a planned or an unplanned shutdown of the cluster. </para> </listitem> <listitem> <para> - <emphasis role="bold">Fragment</emphasis>: A portion of a - database table; in the NDB storage engine, a table is broken - up into and stored as a number of fragments. A fragment is - sometimes also called a - <emphasis role="bold">partition</emphasis>; however, - "fragment" is the preferred term. Tables are fragmented in - MySQL Cluster in order to facilitate load balancing between - machines and nodes. + <emphasis role="bold">Fragment</emphasis>: + </para> + + <para> + A portion of a database table; in the <literal>NDB</literal> + storage engine, a table is broken up into and stored as a + number of fragments. A fragment is sometimes also called a + <quote>partition</quote>; however, <quote>fragment</quote> is + the preferred term. Tables are fragmented in MySQL Cluster in + order to facilitate load balancing between machines and nodes. </para> </listitem> <listitem> <para> - <emphasis role="bold">Replica</emphasis>: Under the NDB - storage engine, each table fragment has number of replicas - stored on other data nodes in order to provide redundancy. - Currently there may be up 4 replicas per fragment. + <emphasis role="bold">Replica</emphasis>: + </para> + + <para> + Under the <literal>NDB</literal> storage engine, each table + fragment has number of replicas stored on other data nodes in + order to provide redundancy. Currently there may be up 4 + replicas per fragment. </para> </listitem> <listitem> <para> - <emphasis role="bold">Transporter</emphasis>: A protocol - providing data transfer between nodes. MySQL Cluster currently - supports 4 different types of transporter connections: - <emphasis role="bold">TCP/IP</emphasis> (local), TCP/IP - (remote), <emphasis role="bold">SCI</emphasis>, and - <emphasis role="bold">SHM</emphasis> (experimental in MySQL - 4.1). + <emphasis role="bold">Transporter</emphasis>: + </para> + + <para> + A protocol providing data transfer between nodes. MySQL + Cluster currently supports 4 different types of transporter + connections: + + <itemizedlist> + + <listitem> + <para> + TCP/IP (local) + </para> + + <para> + This is, of course, the familiar network protocol that + underlies HTTP, FTP (and so on) on the Internet. + </para> + </listitem> + + <listitem> + <para> + TCP/IP (remote) + </para> + + <para> + Same as above, except as used for communicating + remotely. + </para> + </listitem> + + <listitem> + <para> + SCI + </para> + + <para> + <emphasis role="bold">S</emphasis>calable + <emphasis role="bold">C</emphasis>oherent + <emphasis role="bold">I</emphasis>nterface is a + high-speed protocol used in building multiprocessor + systems and parallel-processing applications. Use of SCI + with MySQL Cluster requires specialized hardware and is + discussed in <xref linkend="sci-sockets"/>. For a basic + introduction to SCI, see + <ulink url="http://www.dolphinics.com/corporate/scitech.html">this + essay at dolphinics.com</ulink>. + </para> + </listitem> + + <listitem> + <para> + SHM + </para> + + + <para> + Unix-style <emphasis role="bold">sh</emphasis>ared + <emphasis role="bold">m</emphasis>emory segments. Where + supported, SHM is used automatically to connect nodes + running on the same host. The + <ulink url="http://www.scit.wlv.ac.uk/cgi-bin/mansec?2+shmop">Unix + man page for <literal>shmop(2)</literal></ulink> is a good + place to begin obtaining additional information about this + topic. + </para> + </listitem> + + </itemizedlist> + </para> - <itemizedlist> - - <listitem> - <para> - <emphasis role="bold">TCP/IP</emphasis> is, of course, the - familiar network protocol that underlies HTTP, FTP, etc., - on the Internet. - </para> - </listitem> - - <listitem> - <para> - <emphasis role="bold">SCI</emphasis> - (<emphasis role="bold">S</emphasis>calable - <emphasis role="bold">C</emphasis>oherent - <emphasis role="bold">I</emphasis>nterface) is a - high-speed protocol used in building multiprocessor - systems and parallel-processing applications. Use of SCI - with MySQL Cluster requires specialized hardware and is - discussed in <xref linkend="sci-sockets"/>. For a basic - introduction to SCI, see - <ulink url="http://www.dolphinics.com/corporate/scitech.html">this - essay at dolphinics.com</ulink>. - </para> - </listitem> - - <listitem> - <para> - <emphasis role="bold">SHM</emphasis> stands for Unix-style - <emphasis role="bold">sh</emphasis>ared - <emphasis role="bold">m</emphasis>emory segments. Where - supported, SHM is used automatically to connect nodes - running on the same host. This is experimental in MySQL - 4.1, but we intend to enable it fully in MySQL 5.0. The - <ulink url="http://www.scit.wlv.ac.uk/cgi-bin/mansec?2+shmop">Unix - man page for <literal>shmop(2)</literal></ulink> is a good - place to begin obtaining additional information about this - topic. - </para> - </listitem> - - </itemizedlist> - <para> <emphasis role="bold">Note</emphasis>: The cluster transporter is internal to the cluster. Applications using MySQL Cluster communicate with SQL nodes just as they do with any other - version of MySQL Server (via TCP/IP or Windows named - pipes/Unix sockets). Queries can be sent and results retrieved - using the standard APIs. + version of MySQL Server (via TCP/IP, or through the use of + Unix sockets or Windows named pipes). Queries can be sent and + results retrieved using the standard MySQL APIs. </para> </listitem> <listitem> <para> - <emphasis role="bold">NDB</emphasis>: Refers to the storage - engine used to enable MySQL Cluster. The NDB storage engine - supports all the usual MySQL column types and SQL statements, - and is ACID-compliant. This engine also provides full support - for transactions (commits and rollbacks). "NDB" stands for - <emphasis role="bold">N</emphasis>etwork - <emphasis role="bold">D</emphasis>ata<emphasis role="bold">b</emphasis>ase. + <emphasis role="bold"><literal>NDB</literal></emphasis>: + </para> + + <para> + This stands for <emphasis role="bold">N</emphasis>etwork + <emphasis role="bold">D</emphasis>ata<emphasis role="bold">b</emphasis>ase, + and refers to the storage engine used to enable MySQL Cluster. + The <literal>NDB</literal> storage engine supports all the + usual MySQL column types and SQL statements, and is + ACID-compliant. This engine also provides full support for + transactions (commits and rollbacks). </para> </listitem> <listitem> <para> <emphasis role="bold">Share-nothing architecture</emphasis>: + </para> + + <para> The ideal architecture for a MySQL Cluster. In a true share-nothing setup, each node runs on a separate host. The advantage such an arrangement is that there no single host or @@ -10284,52 +10420,69 @@ <listitem> <para> - <emphasis role="bold">In-memory storage</emphasis>: All data - stored in each data node is kept in memory on the node's host - computer. For each data node in the cluster, you must have - available an amount of RAM equal to the size of the database - times the number of replicas, divided by the number of data - nodes. Thus, if the database takes up 1 gigabyte of memory, - and you wish to set up the cluster with 4 replicas and 8 data - nodes, a minimum of 500 MB memory will be required per node. - Note that this is in addition to any requirements for the - operating system and any applications running on the host. + <emphasis role="bold">In-memory storage</emphasis>: + </para> + + <para> + All data stored in each data node is kept in memory on the + node's host computer. For each data node in the cluster, you + must have available an amount of RAM equal to the size of the + database times the number of replicas, divided by the number + of data nodes. Thus, if the database takes up 1 gigabyte of + memory, and you wish to set up the cluster with 4 replicas and + 8 data nodes, a minimum of 500 MB memory will be required per + node. Note that this is in addition to any requirements for + the operating system and any other applications that might be + running on the host. </para> </listitem> <listitem> <para> - <emphasis role="bold">Table</emphasis>: As is usual in the - context of a relational database, the term "table" denotes an - ordered set of identically structured records. In MySQL - Cluster, a database table is stored in a data node as a set of - fragments, each of which is replicated on additional data - nodes. The set of data nodes replicating the same fragment or - set of fragments is referred to as a - <emphasis role="bold">node group</emphasis>. + <emphasis role="bold">Table</emphasis>: + </para> + + <para> + As is usual in the context of a relational database, the term + <quote>table</quote> denotes an ordered set of identically + structured records. In MySQL Cluster, a database table is + stored in a data node as a set of fragments, each of which is + replicated on additional data nodes. The set of data nodes + replicating the same fragment or set of fragments is referred + to as a <emphasis>node group</emphasis>. </para> </listitem> <listitem> <para> - <emphasis role="bold">Cluster programs</emphasis>: These are - command-line programs used in running, configuring and - administering MySQL Cluster. They include both server daemons: + <emphasis role="bold">Cluster programs</emphasis>: + </para> + <para> + These are command-line programs used in running, configuring, + and administering MySQL Cluster. They include both server + daemons: </para> <itemizedlist> <listitem> <para> - <literal>ndbd</literal>: The data node daemon (runs a data - node process) + <literal>ndbd</literal>: + </para> + + <para> + The data node daemon (runs a data node process) </para> </listitem> <listitem> <para> - <literal>ndb_mgmd</literal>: The management server daemon - (runs a management server process) + <literal>ndb_mgmd</literal>: + </para> + + <para> + The management server daemon (runs a management server + process) </para> </listitem> @@ -10343,22 +10496,32 @@ <listitem> <para> - <literal>ndb_mgm</literal>: The management client - (provides an interface for executing management commands) + <literal>ndb_mgm</literal>: + </para> + + <para> + The management client (provides an interface for executing + management commands) </para> </listitem> <listitem> <para> - <literal>ndb_waiter</literal>: Used to verify status of - all nodes in a cluster + <literal>ndb_waiter</literal>: + </para> + + <para> + Used to verify status of all nodes in a cluster </para> </listitem> <listitem> <para> - <literal>ndb_restore</literal>: Restores cluster data from - backup + <literal>ndb_restore</literal>: + </para> + + <para> + Restores cluster data from backup </para> </listitem> @@ -10372,10 +10535,13 @@ <listitem> <para> - <emphasis role="bold">Event log</emphasis>: MySQL Cluster logs - events by category (startup, shutdown, errors, checkpoints, - etc.), priority, and severity. A complete listing of all - reportable events may be found in + <emphasis role="bold">Event log</emphasis>: + </para> + + <para> + MySQL Cluster logs events by category (startup, shutdown, + errors, checkpoints, and so on), priority, and severity. A + complete listing of all reportable events may be found in <xref linkend="mysql-cluster-event-reports"/>. Event logs are of two types: </para> @@ -10384,16 +10550,23 @@ <listitem> <para> - <emphasis role="bold">Cluster log</emphasis>: Keeps a - record of all desired reportable events for the cluster as - a whole. + <emphasis role="bold">Cluster log</emphasis>: + </para> + + <para> + Keeps a record of all desired reportable events for the + cluster as a whole. </para> </listitem> <listitem> <para> - <emphasis role="bold">Node log</emphasis>: A separate log - is also kept for each individual node. + <emphasis role="bold">Node log</emphasis>: + </para> + + <para> + A separate log which is also kept for each individual + node. </para> </listitem> @@ -10411,81 +10584,59 @@ <!-- *** END CLUSTER GLOSSARY *** --> -<!-- @node MySQL Cluster Tables --> - -<!-- @section Creating NDBCluster Tables --> - -<!-- @node MySQL Cluster Trans Model --> - -<!-- @section The Transaction Model for MySQL Cluster --> - -<!-- @node MySQL Cluster Structures --> - -<!-- @section Record and Index Structures in MySQL Cluster --> - -<!-- @node MySQL Cluster Fixed --> - -<!-- @subsection Fixed Record Structure --> - -<!-- @node MySQL Cluster Variable --> - -<!-- @subsection Variable Sized Record Parts --> - -<!-- @node MySQL Cluster BLOB --> - -<!-- @subsection @code{BLOB} Handling in MySQL Cluster --> - -<!-- @node MySQL Cluster Hash Index --> - -<!-- @subsection Hash Index Structure --> - -<!-- @node MySQL Cluster Ordered Index --> - -<!-- @subsection Structure of the Ordered Index --> - -<!-- @node MySQL Cluster Access --> - -<!-- @section Table Access Methods in MySQL Cluster --> - -<!-- @node MySQL Cluster PK --> - -<!-- @subsection Primary Key Access --> - -<!-- @node MySQL Cluster UK --> - -<!-- @subsection Unique Hash Index Access --> - -<!-- @node MySQL Cluster Scan --> - -<!-- @subsection Full Table Scan --> - -<!-- @node MySQL Cluster Range --> - -<!-- @subsection Range Scan --> - -<!-- @node MySQL Cluster Performance --> - -<!-- @section Performance Tuning of MySQL Cluster --> - -<!-- @node MySQL Cluster Software Upgrade --> - -<!-- @section Software Upgrade of MySQL Cluster --> - -<!-- @node MySQL Cluster Error --> - -<!-- @section Error Handling in MySQL Cluster --> - -<!-- @node MySQL Cluster Restrictions --> - -<!-- @section Restrictions on NDBCluster Tables --> - -<!-- @node MySQL Cluster Troubleshooting --> - -<!-- @section Troubleshooting MySQL Cluster --> - -<!-- @node MySQL Cluster TODO --> - -<!-- @section TODO list for MySQL Cluster --> +<!-- TODO: Determine which if any of the following sections need to be + created and either do so or remove from comment block. [js] +--> + +<!-- + @node MySQL Cluster Tables + @section Creating NDBCluster Tables + + @node MySQL Cluster Trans Model + @section The Transaction Model for MySQL Cluster + + @node MySQL Cluster Structures + @section Record and Index Structures in MySQL Cluster + + @node MySQL Cluster Fixed + @subsection Fixed Record Structure + + @node MySQL Cluster Variable + @subsection Variable Sized Record Parts + + @node MySQL Cluster BLOB + @subsection @code{BLOB} Handling in MySQL Cluster + + @node MySQL Cluster Hash Index + @subsection Hash Index Structure + + @node MySQL Cluster Ordered Index + @subsection Structure of the Ordered Index + + @node MySQL Cluster Access + @section Table Access Methods in MySQL Cluster + + @node MySQL Cluster PK + @subsection Primary Key Access + + @node MySQL Cluster UK + @subsection Unique Hash Index Access + + @node MySQL Cluster Scan + @subsection Full Table Scan + + @node MySQL Cluster Range + @subsection Range Scan + + @node MySQL Cluster Performance + @section Performance Tuning of MySQL Cluster + + @node MySQL Cluster Software Upgrade + @section Software Upgrade of MySQL Cluster + + @node MySQL Cluster Error + @section Error Handling in MySQL Cluster +--> </section> --- 1.40/refman-5.0/titles.ent 2005-07-29 12:37:56 +10:00 +++ 1.41/refman-5.0/titles.ent 2005-07-29 21:32:50 +10:00 @@ -540,7 +540,7 @@ <!ENTITY title-mysql-indexes "How MySQL Uses Indexes"><!-- "How MySQL Uses Indexes" --> <!ENTITY title-mysql-cluster-news-4-1-10 "MySQL Cluster-4.1.10 (12 Feb 2005)"><!-- "MySQL Cluster-4.1.10 (12 Feb 2005)" --> <!ENTITY title-mysql-stmt-row-seek "<literal>mysql_stmt_row_seek()</literal>"><!-- "<literal>mysql_stmt_row_seek()</literal>" --> -<!ENTITY title-mysql-cluster-building "Building from Source Code"><!-- "Building from Source Code" --> +<!ENTITY title-mysql-cluster-building "Building MySQL Cluster from Source Code"><!-- "Building MySQL Cluster from Source Code" --> <!ENTITY title-compressed-format "Compressed Table Characteristics"><!-- "Compressed Table Characteristics" --> <!ENTITY title-year-2000-compliance "Year 2000 Compliance"><!-- "Year 2000 Compliance" --> <!ENTITY title-packages "Packages that support MySQL"><!-- "Packages that support MySQL" --> --- 1.13/refman-5.0/Status 2005-07-29 12:37:56 +10:00 +++ 1.14/refman-5.0/Status 2005-07-29 21:32:49 +10:00 @@ -20,9 +20,11 @@ limits restrictions mysql-optimization + ndbcluster (Will update Limitations section after consulting with + Jeb and NDB devs) -- 5.0 chapters awaiting edits: - ndbcluster +- 5.0 chapters awaiting major edits: + [more or less complete] - 5.0 chapters (probably/hopefully) needing minimal if any edits: maxdb
| Thread | ||
|---|---|---|
| • bk commit - mysqldoc@docsrva tree (jon:1.3130) | jon | 29 Jul |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 1.142 sec. using MySQL 5.1.14-beta-log