Php文档 Php问答行业资讯 Php论坛 Php手册 Php博客

游戏榜单

软件榜单

关闭导航

热搜榜

热门下载

热门标签

关闭搜索

php爱好者> php文档>MySQL Cluster Overview

MySQL Cluster Overview

时间：2007-07-27 来源：makewong

MySQL Cluster is a technology that enables clustering of in-memory databases in a shared-nothing system. The shared-nothing architecture allows the system to work with very inexpensive hardware, and with a minimum of specific requirements for hardware or software.

MySQL Cluster is designed not to have any single point of failure. For this reason, each component is expected to have its own memory and disk, and the use of shared storage mechanisms such as network shares, network filesystems, and SANs is not recommended or supported.

MySQL Cluster integrates the standard MySQL server with an in-memory clustered storage engine called NDB. In our documentation, the term NDB refers to the part of the setup that is specific to the storage engine, whereas “MySQL Cluster” refers to the combination of MySQL and the NDB storage engine.

A MySQL Cluster consists of a set of computers, each running a one or more processes which may include a MySQL server, a data node, a management server, and (possibly) a specialized data access programs. The relationship of these components in a cluster is shown here:

All these programs work together to form a MySQL Cluster. When data is stored in the NDB Cluster storage engine, the tables are stored in the data nodes. Such tables are directly accessible from all other MySQL servers in the cluster. Thus, in a payroll application storing data in a cluster, if one application updates the salary of an employee, all other MySQL servers that query this data can see this change immediately.

The data stored in the data nodes for MySQL Cluster can be mirrored; the cluster can handle failures of individual data nodes with no other impact than that a small number of transactions are aborted due to losing the transaction state. Because transactional applications are expected to handle transaction failure, this should not be a source of problems.

MySQL Cluster 5.1 Carrier Grade Edition

MySQL Cluster 5.1 Carrier Grade Edition is a branch of MySQL 5.1 using advanced versions of the NDB storage engine and NDB API. It is intended for use in the telcommunications industry, and is available in binary and source form to commercial customers. Two development trees can also be accessed via http://mysql.bkbits.net/:

mysql-5.1-telco
mysql-5.1-telco-6.1

MySQL Cluster 5.1 Carrier Grade Edition versioning. MySQL Cluster 5.1 Carrier Grade Edition — sometimes also referred to as “CGE” — follows a somewhat different release pattern from the mainline MySQL 5.1 Cluster series of releases. Each MySQL Cluster 5.1 Carrier Grade Edition release is identified by a two-part version string which identifies the mainline MySQL version from which the CGE release was branched and the version of the NDB storage engine used. For example, the first CGE release was mysql-5.1.14-ndb-6.1.0. The version string tells us that this version:

Derives from MySQL 5.1.14, and contains all feature enhancement and bugfixes from MySQL 5.1, up to and including MySQL 5.1.14.
Uses version 6.1.0 of the NDB storage engine.

MySQL Cluster 5.1 Carrier Grade Edition change history. Changelogs for MySQL Cluster 5.1 Carrier Grade Edition releases may be found in Section C.1, “Changes in release 5.1.x (Development)”, and are grouped together according to the mainline MySQL 5.1 version from which they derive, in the following sections:

Section C.1.8, “Changes in MySQL 5.1.14 Carrier Grade Edition”: Includes Section C.1.8.1, “Changes in release MySQL 5.1.14-ndb-6.1.0-beta (20 December 2006)”.

This release includes all feature enhancements and bugfixes made in MySQL 5.1 up to and including the 5.1.14 release.
Section C.1.6, “Changes in MySQL 5.1.15 Carrier Grade Edition”: Includes Section C.1.6.7, “Changes in release MySQL 5.1.15-ndb-6.1.1-beta (01 February 2007)”, Section C.1.6.6, “Changes in release MySQL 5.1.15-ndb-6.1.2-beta (07 February 2007)”, Section C.1.6.5, “Changes in release MySQL 5.1.15-ndb-6.1.3-beta (25 February 2007)”, Section C.1.6.4, “Changes in release MySQL 5.1.15-ndb-6.1.4-beta (09 March 2007 - testing only)”, Section C.1.6.3, “Changes in release MySQL 5.1.15-ndb-6.1.5-beta (15 March 2007)”, and Section C.1.6.2, “Changes in release MySQL 5.1.15-ndb-6.1.6-beta (Not released)”.

These releases include all feature enhancements and bugfixes made in MySQL 5.1 up to and including 5.1.15, as well as those CGE-specific enhancements made in MySQL-5.1.14-ndb-6.1.0.
Section C.1.4, “Changes in MySQL 5.1.16 Carrier Grade Edition”: Includes Section C.1.4.2, “Changes in release MySQL 5.1.16-ndb-6.2.0-beta (03 March 2007)” and Section C.1.4.1, “Changes in release MySQL 5.1.16-ndb-6.2.1-beta (Not yet released)”.

These releases include all feature enhancements and bugfixes made in MySQL 5.1 up to and including 5.1.16, as well as those CGE-specific enhancements that were made in ndb-6.1.x releases.

Each of the MySQL Cluster 5.1 Carrier Grade Edition includes enhancements to the NDB storage engine that do not appear in the mainline MySQL 5.1 tree. We plan to port these to MySQL 5.1 or later mainline MySQL releases at some point in the future.

Some fixes that were applied first in MySQL Cluster 5.1 Carrier Grade Edition have already been ported to MySQL 5.1. In these cases, the fix is listed twice in Section C.1, “Changes in release 5.1.x (Development)”.

Since all bugfixes applied in MySQL Cluster 5.1 Carrier Grade Edition relate to MySQL Cluster, changelog entries for CGE releases are not prefixed with “NDB Cluster:” as MySQL Cluster bugfixes in mainline MySQL 5.1 are.

Important

This chapter of the MySQL Manual covers both MySQL 5.1 and MySQL Cluster 5.1 Carrier Grade Edition.

Information which applies to MySQL Cluster 5.1 Carrier Grade Edition releases but not to mainline 5.1 releases is indicated with a warning such as this one:

MySQL Cluster 5.1 Carrier Grade Edition. The following information applies to users of MySQL Cluster 5.1 Carrier Grade Edition only. For more information about MySQL Cluster 5.1 Carrier Grade Edition, see Section 15.2, “MySQL Cluster 5.1 Carrier Grade Edition”.

Information which applies to mainline MySQL 5.1 releases but not to MySQL Cluster 5.1 Carrier Grade Edition releases is indicated with a warning such as this one:

MySQL Cluster 5.1 Carrier Grade Edition. The following information does not apply to users of MySQL Cluster 5.1 Carrier Grade Edition. For more information about MySQL Cluster 5.1 Carrier Grade Edition, see Section 15.2, “MySQL Cluster 5.1 Carrier Grade Edition”.

Currently, both the ndb-6.1.x and ndb-6.2.x series are under active development, with the ndb-6.1.x series intended for use by telecommunications customers and ndb-6.2.x intended for testing purposes.

Additional information about obtaining MySQL Cluster 5.1 Carrier Grade Edition binaries can be found on the MySQL AB web site at http://www.mysql.com/products/database/clustercge/, or by contacting <[email protected]>.

Basic MySQL Cluster Concepts 15.3.1. MySQL Cluster Nodes, Node Groups, Replicas, and Partitions

NDB is an in-memory storage engine offering high-availability and data-persistence features.

The NDB storage engine can be configured with a range of failover and load-balancing options, but it is easiest to start with the storage engine at the cluster level. MySQL Cluster's NDB storage engine contains a complete set of data, dependent only on other data within the cluster itself.

The cluster portion of MySQL Cluster is currently configured independently of the MySQL servers. In a MySQL Cluster, each part of the cluster is considered to be a node.

Note: In many contexts, the term “node” is used to indicate a computer, but when discussing MySQL Cluster it means a process. It is possible to run any number of nodes on a single computer, for which we use the term cluster host.

(However, it should be noted MySQL does not currently support the use of multiple data nodes on a single computer in a production setting. See Issues exclusive to MySQL Cluster.)

There are three types of cluster nodes, and in a minimal MySQL Cluster configuration, there will be at least three nodes, one of each of these types:

Management node (MGM node): The role of this type of node is to manage the other nodes within the MySQL Cluster, performing such functions as providing configuration data, starting and stopping nodes, running backup, and so forth. Because this node type manages the configuration of the other nodes, a node of this type should be started first, before any other node. An MGM node is started with the command ndb_mgmd.
Data node: This type of node stores cluster data. There are as many data nodes as there are replicas, times the number of fragments. For example, with two replicas, each having two fragments, you will need four data nodes. It is not necessary to have more than one replica. A data node is started with the command ndbd.
SQL node: This is a node that accesses the cluster data. In the case of MySQL Cluster, an SQL node is a traditional MySQL server that uses the NDB Cluster storage engine. An SQL node is typically started with the command mysqld --ndbcluster or by using mysqld with the ndbcluster option added to my.cnf.

An SQL node is actually just a specialised type of API node, which designates any application which accesses Cluster data. One example of an API node is the ndb_restore utility that is used to restore a cluster backup. It is possible to write such applications using the NDB API.

Important: It is not realistic to expect to employ a three-node setup in a production environment. Such a configuration provides no redundancy; in order to benefit from MySQL Cluster's high-availability features, you must use multiple data and SQL nodes. The use of multiple management nodes is also highly recommended.

For a brief introduction to the relationships between nodes, node groups, replicas, and partitions in MySQL Cluster, see Section 15.3.1, “MySQL Cluster Nodes, Node Groups, Replicas, and Partitions”.

Configuration of a cluster involves configuring each individual node in the cluster and setting up individual communication links between nodes. MySQL Cluster is currently designed with the intention that data nodes are homogeneous in terms of processor power, memory space, and bandwidth. In addition, to provide a single point of configuration, all configuration data for the cluster as a whole is located in one configuration file.

The management server (MGM node) manages the cluster configuration file and the cluster log. Each node in the cluster retrieves the configuration data from the management server, and so requires a way to determine where the management server resides. When interesting events occur in the data nodes, the nodes transfer information about these events to the management server, which then writes the information to the cluster log.

In addition, there can be any number of cluster client processes or applications. These are of two types:

Standard MySQL clients: These are no different for MySQL Cluster than they are for standard (non-Cluster) MySQL. In other words, MySQL Cluster can be accessed from existing MySQL applications written in PHP, Perl, C, C++, Java, Python, Ruby, and so on.
Management clients: These clients connect to the management server and provide commands for starting and stopping nodes gracefully, starting and stopping message tracing (debug versions only), showing node versions and status, starting and stopping backups, and so on.

User Comments

Posted by Jon Gabrielson on February 15 2006 3:57pm

[Delete] [Edit]

From the glossary:
A fragment is sometimes also called a “partition”; however, “fragment” is the preferred term.

Posted by li zhou on November 17 2006 10:18am

[Delete] [Edit]

The explacation of *Data node* looks not so good.

It's better be

" There are as many data nodes as there are replicas, times the number of *Partition(node groups)*.For example, with two replicas, each partition(node groups) having two fragments, you will need four data nodes. "

Add your own comment.

MySQL Cluster Nodes, Node Groups, Replicas, and Partitions

This section discusses the manner in which MySQL Cluster divides and duplicates data for storage.

Central to an understanding of this topic are the following concepts, listed here with brief definitions:

(Data) Node: An ndbd process, which stores a replica —that is, a copy of the partition (see below) assigned to the node group of which the node is a member.

Each data node should be located on a separate computer. While it is also possible to host multiple ndbd processes on a single computer, such a configuration is not supported.

It is common for the terms “node” and “data node” to be used interchangeably when referring to an ndbd process; where mentioned, management (MGM) nodes (ndb_mgmd processes) and SQL nodes (mysqld processes) are specified as such in this discussion.
Node Group: A node group consists of one or more nodes, and stores partitions, or sets of replicas (see next item).

Note: Currently, all node groups in a cluster must have the same number of nodes.
Partition: This is a portion of the data stored by the cluster. There are as many cluster partitions as nodes participating in the cluster. Each node is responsible for keeping at least one copy of any partitions assigned to it (that is, at least one replica) available to the cluster.

A replica belongs entirely to a single node; a node can (and usually does) store several replicas.
Replica: This is a copy of a cluster partition. Each node in a node group stores a replica. Also sometimes known as a partition replica. The number of replicas is equal to the number of nodes per node group.

The following diagram illustrates a MySQL Cluster with four data nodes, arranged in two node groups of two nodes each; nodes 1 and 2 belong to node group 0, and nodes 3 and 4 belong to node group 1. Note that only data (ndbd) nodes are shown here; although a working cluster requires an ndb_mgm process for cluster management and at least one SQL node to access the data stored by the cluster, these have been omitted in the figure for clarity.

The data stored by the cluster is divided into four partitions, numbered 0, 1, 2, and 3. Each partition is stored — in multiple copies — on the same node group. Partitions are stored on alternate node groups:

Partition 0 is stored on node group 0; a primary replica (primary copy) is stored on node 1, and a backup replica (backup copy of the partition) is stored on node 2.
Partition 1 is stored on the other node group (node group 1); this partition's primary replica is on node 3, and its backup replica is on node 4.
Partition 2 is stored on node group 0. However, the placing of its two replicas is reversed from that of Partition 0; for Partition 2, the primary replica is stored on node 2, and the backup on node 1.
Partition 3 is stored on node group 1, and the placement of its two replicas are reversed from those of partition 1. That is, its primary replica is located on node 4, with the backup on node 3.

What this means regarding the continued operation of a MySQL Cluster is this: so long as each node group participating in the cluster has at least one node operating, the cluster has a complete copy of all data and remains viable. This is illustrated in the next diagram.

In this example, where the cluster consists of two node groups of two nodes each, any combination of at least one node in node group 0 and at least one node in node group 1 is sufficient to keep the cluster “alive” (indicated by arrows in the diagram). However, if both nodes from either node group fail, the remaining two nodes are not sufficient (shown by the arrows marked out with an X); in either case, the cluster has lost an entire partition and so can no longer provide access to a complete set of all cluster data.

Simple Multi-Computer How-To

15.4.1. Hardware, Software, and Networking 15.4.2. Multi-Computer Installation 15.4.3. Multi-Computer Configuration 15.4.4. Initial Startup 15.4.5. Loading Sample Data and Performing Queries 15.4.6. Safe Shutdown and Restart

This section is a “How-To” that describes the basics for how to plan, install, configure, and run a MySQL Cluster. Whereas the examples in Section 15.5, “MySQL Cluster Configuration” provide more in-depth information on a variety of clustering options and configuration, the result of following the guidelines and procedures outlined here should be a usable MySQL Cluster which meets the minimum requirements for availability and safeguarding of data.

This section covers hardware and software requirements; networking issues; installation of MySQL Cluster; configuration issues; starting, stopping, and restarting the cluster; loading of a sample database; and performing queries.

Basic Assumptions

This How-To makes the following assumptions:

The cluster setup has four nodes, each on a separate host, and each with a fixed network address on a typical Ethernet as shown here:

Node	IP Address
Management (MGM) node	192.168.0.10
MySQL server (SQL) node	192.168.0.20
Data (NDBD) node "A"	192.168.0.30
Data (NDBD) node "B"	192.168.0.40

This may be made clearer in the following diagram:

In the interest of simplicity (and reliability), this How-To uses only numeric IP addresses. However, if DNS resolution is available on your network, it is possible to use hostnames in lieu of IP addresses in configuring Cluster. Alternatively, you can use the /etc/hosts file or your operating system's equivalent for providing a means to do host lookup if such is available.

Note

A common problem when trying to use hostnames for Cluster nodes arises because of the way in which some operating systems (including some Linux distributions) set up the system's own hostname in the /etc/hosts during installation. Consider two machines with the hostnames ndb1 and ndb2, both in the cluster network domain. Red Hat Linux (including some derivatives such as CentOS and Fedora) places the following entries in these machines' /etc/hosts files:

# ndb1 /etc/hosts: 127.0.0.1 ndb1.cluster ndb1 localhost.localdomain localhost

# ndb2 /etc/hosts: 127.0.0.1 ndb2.cluster ndb2 localhost.localdomain localhost

SuSE Linux (including OpenSuSE) places these entries in the machines' /etc/hosts files:

# ndb1 /etc/hosts: 127.0.0.1 localhost 127.0.0.2 ndb1.cluster ndb1

# ndb2 /etc/hosts: 127.0.0.1 localhost 127.0.0.2 ndb2.cluster ndb2

In both instances, ndb1 routes ndb1.cluster to a loopback IP address, but gets a public IP address from DNS for ndb2.cluster, while ndb2 routes ndb2.cluster to a loopback address and obtains a public address for ndb1.cluster. The result is that each data node connects to the management server, but cannot tell when any other data nodes have connected, and so the data nodes appear to hang while starting.

You should also be aware that you cannot mix localhost and other hostnames or IP addresses in config.ini. For these reasons, the solution in such cases (other than to use IP addresses for all config.ini HostName entries) is to remove the fully qualified hostnames from /etc/hosts and use these in config.ini for all cluster hosts.

Each host in our scenario is an Intel-based desktop PC running a common, generic Linux distribution installed to disk in a standard configuration, and running no unnecessary services. The core OS with standard TCP/IP networking capabilities should be sufficient. Also for the sake of simplicity, we also assume that the filesystems on all hosts are set up identically. In the event that they are not, you will need to adapt these instructions accordingly.
Standard 100 Mbps or 1 gigabit Ethernet cards are installed on each machine, along with the proper drivers for the cards, and that all four hosts are connected via a standard-issue Ethernet networking appliance such as a switch. (All machines should use network cards with the same throughout. That is, all four machines in the cluster should have 100 Mbps cards or all four machines should have 1 Gbps cards.) MySQL Cluster will work in a 100 Mbps network; however, gigabit Ethernet will provide better performance.

Note that MySQL Cluster is not intended for use in a network for which throughput is less than 100 Mbps. For this reason (among others), attempting to run a MySQL Cluster over a public network such as the Internet is not likely to be successful, and is not recommended.
For our sample data, we will use the world database which is available for download from the MySQL AB Web site. As this database takes up a relatively small amount of space, we assume that each machine has 256MB RAM, which should be sufficient for running the operating system, host NDB process, and (for the data nodes) for storing the database.

Although we refer to a Linux operating system in this How-To, the instructions and procedures that we provide here should be easily adaptable to other supported operating systems. We also assume that you already know how to perform a minimal installation and configuration of the operating system with networking capability, or that you are able to obtain assistance in this elsewhere if needed.

We discuss MySQL Cluster hardware, software, and networking requirements in somewhat greater detail in the next section. (See Section 15.4.1, “Hardware, Software, and Networking”.)

Hardware, Software, and Networking

One of the strengths of MySQL Cluster is that it can be run on commodity hardware and has no unusual requirements in this regard, other than for large amounts of RAM, due to the fact that all live data storage is done in memory. (Note that this is not the case with Disk Data tables — see Section 15.12, “MySQL Cluster Disk Data Tables”, for more information about these.) Naturally, multiple and faster CPUs will enhance performance. Memory requirements for other Cluster processes are relatively small.

The software requirements for Cluster are also modest. Host operating systems do not require any unusual modules, services, applications, or configuration to support MySQL Cluster. For supported operating systems, a standard installation should be sufficient. The MySQL software requirements are simple: all that is needed is a production release of MySQL 5.1 to have Cluster support. It is not necessary to compile MySQL yourself merely to be able to use Cluster. In this How-To, we assume that you are using the server binary appropriate to your operating system, available via the MySQL software downloads page at http://dev.mysql.com/downloads/.

For inter-node communication, Cluster supports TCP/IP networking in any standard topology, and the minimum expected for each host is a standard 100 Mbps Ethernet card, plus a switch, hub, or router to provide network connectivity for the cluster as a whole. We strongly recommend that a MySQL Cluster be run on its own subnet which is not shared with non-Cluster machines for the following reasons:

Security: Communications between Cluster nodes are not encrypted or shielded in any way. The only means of protecting transmissions within a MySQL Cluster is to run your Cluster on a protected network. If you intend to use MySQL Cluster for Web applications, the cluster should definitely reside behind your firewall and not in your network's De-Militarized Zone (DMZ) or elsewhere.
Efficiency: Setting up a MySQL Cluster on a private or protected network allows the cluster to make exclusive use of bandwidth between cluster hosts. Using a separate switch for your MySQL Cluster not only helps protect against unauthorized access to Cluster data, it also ensures that Cluster nodes are shielded from interference caused by transmissions between other computers on the network. For enhanced reliability, you can use dual switches and dual cards to remove the network as a single point of failure; many device drivers support failover for such communication links.

It is also possible to use the high-speed Scalable Coherent Interface (SCI) with MySQL Cluster, but this is not a requirement. See Section 15.13, “Using High-Speed Interconnects with MySQL Cluster”, for more about this protocol and its use with MySQL Cluster.