MySQL Cluster使用到目前为止遇到渴望得到答案的问题，也是直接影响使用的问题就是MySQL Cluster的写入效率问题和Cluster是否适合大数据存储、如何配置存储的问题。

继续我们的验证工作，这次是搭建MySQL的主从配置，再利用Amoeba实现读写分离，搭建一个相对有实际意义的MySQL集群环境。

MySQL的主从配置比较简单，网上也有很多的文章，这里不多介绍。基于之前的介绍的环境考虑：

10.4.44.206 主-写
10.4.44.207 从-读1
10.4.44.208 从-读2

MySQL的主从配置确实十分简单。主要就是配置好日志的监听。这里OneCoder是参考：http://369369.blog.51cto.com/319630/790921 的文章完成的配置。配置好后，验证一下主从环境是否可用。连接206插入一条数据，在207和208上可成功查询到该数据，证明我们的主从环境配置成功。接下来我们再来配置Amoeba，只要在amoeba.xml中配置好读写库就可以了。

然后连接205Amoeba服务端写入数据，分别直接206，207，208节点查询数据，均可查到，并且与通过Amoeba节点查询出的数据是相同的。可见数据是自动同步的。

   通过208查询效果，（205，206，207节点查询效果均相同）

通过Amoeba查询数据，可以看到只有配置的读节点有网络传输，写节点的网络是风平浪静的。

206写

208 读节点

考虑的是，Amoeba是不支持事物的，所以我们可以考虑把写节点直接暴露出来，表引擎选择InnoDB, 其他读节点通过Amoeba进行负载均衡。不过这里就需要业务自己来控制读写的数据源选择了。

至此，对于MySQL的验证工作也基本告一段落了，对于形形色色的方案及其试用场景，OneCoder也需要好好消化总结一下了。

由于MySQL Cluster自身就实现了数据的自动同步等功能，在此之上架一层Amoeba基本只起到了分担SQL层负载的的作用，所以我们很有必要基于传统的单点MySQL服务之上的 Amoeba都能帮我们做些什么。

环境搭建的过程不再赘述，我们在两个新的虚拟机上启动两个独立的MySQL服务，然后配置在 Amoeba中即可。此时SQL节点的IP分别为：

10.4.44.206 写
10.4.44.207 读
10.4.44.208 读
10.4.44.205 Amoeba节点

这里使用的MySQL版本为，mysql-5.5.29-linux2.6-x86_64。先手动分别在三个节点上创建了相同的数据库(bigdata)和表(data_house)。修改amoeba.xml和dbServers.xml配置，重启amoeba服务。

怀着好奇，先测试通过Amoeba节点写入数据和查询数据的情况，看看数据是否是各个节点自动同步的。同样，使用的之前使用的JDBC测试代码。观察写入过程中虚拟机的网络和磁盘指标情况。

write206节点监控图表

发现果然只有206写节点有网络和磁盘传输请求，207和208节点一片平静。显然数据不是这样同步的，通过Amoeba查询，果然没有数据。在这种情况下，我们应该配置Amoeba的水平切分规则，让数据分别存储在各个节点上。不过这样的话每个节点都只有一部分数据，任何一个节点的故障都会导致数据的不完整，我们来验证看看是不是这样。

修改rule.xml中的配置，

根据ID hash(2)的值水平切分数据。这里每个规则都对应自己的读写节点。这里验证就是Amoeba的路由规则功能。执行数据插入，可以看到数据平均的分配到207和208两个数据节点上，各10000条数据。

此时执行count操作，返回值始终是10000，可见此时无法查询到完整的数据。但是有了这种切分规则，你可以灵活的进行的自己的配置，比如可以进行垂直切分等。所以可见，Amoeba的主要职责是起到了一个路由的作用，把请求分发下去，数据同步不是它关心的。所以Amoeba官网中介绍的读写分离也是基于MySQL主从配置的，这也是我们接下来要进行的工作：）

龙年完成的Amoeba环境初步搭建工作，蛇年开始进行读写分离和负载均衡的验证工作。先祝大家蛇年一切顺利。上回的工作我们只是完成Amoeba框架的引入，但是并不满足读写分离场景的要求，因为最基本的，SQL节点只有一个。
所以，我们首先需要添加一个SQL节点，具体操作不再赘述。添加，重启后，MySQL Clluster集群环境如下。

修改Amoeba的环境配置dbServers.xml，增加一个dbServer节点10.4.44.200。

重启Amoeba服务使配置生效。

此时，使用之前写好的JDBC代码直接访问Amoeba的服务即可完成对数据的操作，只需修改IP地址和端口(默认为8066)即可。

通过测试发现，通过访问Amoeba服务，确实完成对了SQL层的负载均衡，观察虚拟机的网络指标，发现两个SQL节点的网络负载比较平均。

               SQL200的网络负载

SQL201相同时刻的网络负载情况

读写分离配置。

<queryRouter class="com.meidusa.amoeba.mysql.parser.MysqlQueryRouter">
                <property name="ruleLoader">
                        <bean class="com.meidusa.amoeba.route.TableRuleFileLoader">
                                <property name="ruleFile">${amoeba.home}/conf/rule.xml</property>
                                <property name="functionFile">${amoeba.home}/conf/ruleFunctionMap.xml</property>
                        </bean>
                </property>
                <property name="sqlFunctionFile">${amoeba.home}/conf/functionMap.xml</property>
                <property name="LRUMapSize">1500</property>
                <property name="defaultPool">server2</property>

                <property name="writePool">server2</property>
                <property name="readPool">multiPool</property>
                <property name="needParse">true</property>
 </queryRouter>

关键是打开默认注释掉的readPool和writePool 的配置项，这里可以配置单节点名称也可以填入在dbServers.xml中定义的虚拟节点的名称，比如这里的multiPool实际包含了server1,server2两个节点。Amoeba按照负载均衡策略进行读取。
注：上述配置是在不进行数据切分的情况下，快速进行读写分离的配置。

连接205的Amoeba节点进行读写操作，观察虚拟机监控图表，可以看到当读数据的时候，负载分担在server1和server2节点上，写数据的时候，只有server2有压力。

备注：Amoeba不能做什么

目前还不支持事务

暂时不支持存储过程（近期会支持）

不适合从amoeba导数据的场景或者对大数据量查询的query并不合适（比如一次请求返回10w以上甚至更多数据的场合）

暂时不支持分库分表，amoeba目前只做到分数据库实例，每个被切分的节点需要保持库表结构一致。

从第四点可以联想到，我们测试的环境是基于MySQL Cluster的多个SQL节点，底层的Data node自然是数据同步的，甚至都不存在他说的保持库表一致的问题。OneCoder也认为，Amoeba在设计之初的使用场景底层应该是基于独立的MySQL节点的。这也是OneCoder接下来考虑的验证工作：）

为了同步在MacOS下和Windows下编写的C++练习代码，同时也想多学一些命令行的操作，OneCoder决定鼓捣一下Mac OS X下的Git代码管理，抛弃以往完全依赖工具界面的操作方式，完全采用shell的操作模式，加深理解。

首先从Github上下载了Git的Mac版，安装。执行：

$>git

即可验证是否安装成功。

根据Git设计理念，我们先创建一个本地库。进入想要创建Git仓库的目录。

$>git init

然后像Git仓库中添加文件，利用git add命令。git add支持各种模糊匹配模式，将当前目标下的所有文件添加如git仓库执行。

$>git add .

即可。
然后执行：

$>git commit

输入备注后，提交入本地git仓库。通过git log可以查看到此次提交的日志信息。
如果我们对文件进行了修改，再通过

$>git status

命令便可以查看到变化的文件。

上图在文件修改后，已经执行git add <file>命令后的效果，再次git commit即可提交修改。

不过一般情况下，我们使用代码管理的很重要的理由是需要代码同步，这里我们以GitHub作为远端托管仓库。先在GitHub上创建一个git仓库，然后通过

$>git clone

命令拷贝到本地。
将代码文件放在git仓库目录下，执行前面的操作本地commit代码。然后执行

$>git push

即可将本地代码推送到远端。

此时如果需要异地同步下载代码，只需要git pull到本地即可。git pull本身就是集成了下载和merge两个命令，即会自动和你本地的代码合并的。如果只下载不合并的话，则可使用git fetch命令。

git的其他使用细节，OneCoder也需要慢慢摸索，这里也不再介绍。至少至此，我们的代码是已经可以成功提交到远端仓库之上了，并且也初步熟悉了一下git的命令行操作，对我来说也算是略有收获了。

对MySQL Cluster的学习还在继续，这次OneCoder是利用Amoeba搭建一个可读写分离、均衡负载的MySQL集群环境。

跟MySQL Cluster一样，安装的过程就是下载、解压、配置、启动。
Amoeba官方文档地址：http://docs.hexnova.com/amoeba/index.html 
Amoeba项目地址：http://sourceforge.net/projects/amoeba/files/

解压后，在运行命令:

$>amoeba

验证的时候，就出现了第一个问题：

The stack size specified is too small, Specify at least 160k.

显然是JVM参数的问题。用vim编辑amoeba启动文件。修改其中的：

将图中选中行的DEFAULT_OPTS="-server ..."最后的 -Xss128k, 改为512k即可。验证通过。继续配置Amoeba。

以下内容摘自Amoeba官方文档：

Amoeba有哪些主要的配置文件？

想象Amoeba作为数据库代理层，它一定会和很多数据库保持通信，因此它必须知道由它代理的数据库如何连接，比如最基础的：主机IP、端口、Amoeba使用的用户名和密码等等。这些信息存储在$AMOEBA_HOME/conf/dbServers.xml中。

Amoeba为了完成数据切分提供了完善的切分规则配置，为了了解如何分片数据、如何将数据库返回的数据整合，它必须知道切分规则。与切分规则相关的信息存储在$AMOEBA_HOME/conf/rule.xml中。

当我们书写SQL来操作数据库的时候，常常会用到很多不同的数据库函数，比如：UNIX_TIMESTAMP()、SYSDATE()等等。这些函数如何被Amoeba解析呢？$AMOEBA_HOME/conf/functionMap.xml描述了函数名和函数处理的关系。

对$AMOEBA_HOME/conf/rule.xml进行配置时，会用到一些我们自己定义的函数，比如我们需要对用户ID求HASH值来切分数据，这些函数在$AMOEBA_HOME/conf/ruleFunctionMap.xml中定义。

Amoeba可以制定一些可访问以及拒绝访问的主机IP地址，这部分配置在$AMOEBA_HOME/conf/access_list.conf中

Amoeba允许用户配置输出日志级别以及方式，配置方法使用log4j的文件格式，文件是$AMOEBA_HOME/conf/log4j.xml。

修改dbServers.xml中的关于数据库链接的配置(一目了然)。

然后确认MySQL Cluster运行正常，再启动 Amoeba。

通过MySQL命令直接连接205进行测试。成功访问。

这里其实OneCoder遇到一个挺巧的问题，就是我环境中的server1暂时不好用，我仅仅配置了server2。可以启动，但是客户端连接就总报拒绝访问。几番检查，才在amoeba.xml中发现了一个默认节点的设置。还配置的server1，改成server2终于好用了。

、

可以看到服务的version已经是mysql-amoeba-proxy了。并且通过show databases命令也可以正常列出数据库列表了。

继续OneCoder之前提出的要验证的问题，为了方便测试MySQL Cluster的数据分片功能，我们设置集群节点配置如下：

NoOfReplicas=1   
DataMemory=50M  
IndexMemory=10M

初始化重启节点：

开始写入80w数据。观察写入过程，可以看到数据是大致均匀写入两个节点之中：

跟之前不同的事，这次不会双节点都保持完全 一样的内存占用了。这说明，这不是由于数据复制造成的，而是正常的数据分片导致。最终80w数据成功写入了容量均为50m的两个数据节点中。这说明MySQL Cluster是可以自动将数据分片保存的。

Begin to prepare statement.
It's up to batch count: 100000
Batch data commit finished. Time cost: 90128
It's up to batch count: 100000
Batch data commit finished. Time cost: 87141
It's up to batch count: 100000
Batch data commit finished. Time cost: 86353
It's up to batch count: 100000
Batch data commit finished. Time cost: 86775
It's up to batch count: 100000
Batch data commit finished. Time cost: 89635
It's up to batch count: 100000
Batch data commit finished. Time cost: 87782
It's up to batch count: 100000
Batch data commit finished. Time cost: 89180
It's up to batch count: 100000
Batch data commit finished. Time cost: 89021
All data insert finished. Total time cost: 706041

那么，如果是在集群已有存储容量不足的情况下，扩充新节点进来，会是怎样的情况呢。我们再测试一下。先去掉一个节点，将容量再调小。然后写入数据直到写满，再加入第二个节点，继续写入数据。看是否可以成功，并且观察数据的分配情况。

在写入的过程，也观察到另外一个现象，就是在一次批量写入没有提交的情况下，内存的占用大于存储需要的空间容量，在提交以后，这部分内存会释放，内存的占用量会降低。因此调整每批次写入的数据量，可在现有的空间中存入更多的数据。这里采用单批次1w输入写入。

注：在单批次20w的情况下。根本无法成功写入任何数据，10w的时候只能写入20w数据。

加入新节点：

目前数据并没有自动调配。我们先继续写入数据测试，看看集群容量是否真的扩容了，并观察后续空间使用状况。数据库现有数据23w。直接继续写入数据，仍然提示空间不足。

观察到，新加入的节点是no nodegroup 状态。所以我们通过：

ndb_mgm>create nodegroup 3;

来创建nodegroup。然后再调整分区数据：

mysql> alter online table data_house reorganize partition;

发现分区果然有变化了。再次继续写入数据，成功！

新加入的节点已经可以写入数据了。

通过工具也可看到，数据库里已经有42w数据了。最终两个节点共写入50w数据。查询效率仍然是20ms左右。至此，MySQL Cluster的一些基本的功能特性，都验证完成了。不过想用于生产环境还需要更多的考量，目前网上也有很多改造过的开源和商业版本，如果有需要可以具体考察一下。

承接之前的初测，题目本来想叫深入测试的，不过想想太大了，就还叫使用的一个小结吧。

在扩充数据节点之前，OneCoder向数据库中又写入900w的数据，总量达到1kw。每批次写入20w的数据，写入时间大致如下：

……
It's up to batch count: 200000
Batch data commit finished. Time cost: 202634
It's up to batch count: 200000
Batch data commit finished. Time cost: 168834
It's up to batch count: 200000
Batch data commit finished. Time cost: 181764
It's up to batch count: 200000
Batch data commit finished. Time cost: 156975
It's up to batch count: 200000
Batch data commit finished. Time cost: 184845
It's up to batch count: 200000
Batch data commit finished. Time cost: 202010
It's up to batch count: 200000
Batch data commit finished. Time cost: 177443
It's up to batch count: 200000
Batch data commit finished. Time cost: 203957
It's up to batch count: 200000
Batch data commit finished. Time cost: 159565
All data insert finished. Total time cost: 10476439

1kw数据执行Select，查询10条结果效率如下：

Query ten rows from table [data_house] cost time: 27

可见效率还是很快。当前数据分布情况如下：

现在，再添加一个数据节点。步骤略，主要就是修改配置文件，按顺序重启即可。不过在重启Data Node时候需要耐心等待成功。

通过

ndb_mgm>all report memory

查看内存占用：

发现数据并没有均匀分配。此时再通过代码查询记录，看看耗时情况。耗时还是24ms左右。没有明显变化。不过，这里我们还是想让数据均匀分配的。先测试再写入100w数据。会不会分别存储。测试显示，数据还是集中在原来的节点保存。插入效率基本与原来一致。

将NoOfReplicas的值从1改为2， 重新启动，发现一直报错：

Node 2: Forced node shutdown completed. Occured during startphase 1. Caused by error 2350: 'Invalid configuration received from Management Server(Configuration error). Permanent error, external action needed'

这个问题确实有由于修改了值引起的，但是找了半天一直没有正常的解决。考虑到现在data存储都是测试数据，所以考虑在data节点采用：

shell>ndbd --initial-start --foreground

的方式重启节点，并通过foreground的方式查看启动日志。最后，倒是正常启动成功了，只是数据确实被"initial"干净了。重新灌数据吧。还拿100w试验。数据灌入效率差不多，只是数据在两个节点上被复制两份了

查询效率还是20ms左右。

继续测试，在执行之前的1kw数据，20w一组批量写入数据灌入测试中，却出现：

Lock wait timeout exceeded; try restarting transaction

的错误。有人说需要调整

TransactionDeadLockDetectionTimeOut=10000

参数的值，默认是1200。不过我并没有采用，因为重启挺坎坷，根据网上的一些讨论分析，减少了每次写入的数量，到10w。目前来看，稳定许多，尚未出现错误。
关闭一个节点，验证集群的高可用性。

再次调用查询接口。正常返回数据。

目前为止，我们还差最关心的数据自动分片，分节点保存的问题没有验证清楚。随后，我们将针对此问题再进行进一步的验证。

基于上篇搭建的环境，验证一些基本功能和性能需求。这里先说一下功能使用的问题。OneCoder也是第一次用。摸索着来，仅做一个记录。

从部署图就可知道，对数据库的请求操作发生在SQL节点上。为了达到试验效果，这里又追加了一个sql节点。现在集群环境如下：

在追加的过程中，发现MySQL Cluster对启动顺序要求严格，在没考虑热部署方案的情况下，必须停止了所有节点，重新按照management->data->sql的顺序启动节点。

现在测试对表的创建和修改的自动同步：

在任意SQL节点执行：（这里选择44.200节点）

create table bigdata_cluster(id int primary key, name varchar(20)) engine=ndbcluster default charset utf8;

创建表，注意表的引擎一定要指定ndbcluster，在201节点查看

show tables;

发现已经可以同步查询了。其实本来底层data节点对上层就是透明的，自然可以查到。多sql节点，就可以起到负载均衡的效果。

调整表和数据插入，都跟传统的MySQL方式相同，不再赘述，同样也是可以做到实时同步的，这里也测过了。下面通过JDBC代码测试下API操作的效果，同时也想灌入100w的数据，进行一下效率测试和对比。

在测试前，OneCoder先用SQLyog工具，测试了一下数据库远端访问权限，发现果然没有。在一个节点grant all了一下以后，却发现另一个节点仍然无法访问，搜索才知，原来MySQL Cluster的用户权限默认不是共享的，进行如下设置，在mysql终端执行：

mysql> SOURCE /usr/local/mysql/share/ndb_dist_priv.sql;
mysql> CALL mysql.mysql_cluster_move_privileges();

即可完成权限共享，现在在一个终端设置的权限就是集群共享的了。在用SQLYog测试，果然均可以链接了。下面开始开发JDBC链接MySQL的代码：</p>

/**
  * 向数据库中插入数据
  *
  * @param conn
  * @param totalRowCount
  * @param perRowCount
  * @param tableName
  * @author lihzh(OneCoder)
  * @throws SQLException
  * @date 2013-1-17 下午1:57:10
  */
private void insertDataToTable(Connection conn, String tableName,
long totalRowCount, long perRowCount) throws SQLException {
conn.setAutoCommit(false);
long start = System.currentTimeMillis();
String sql = "insert into " + tableName + " VALUES(?,?,?)";
System.out.println("Begin to prepare statement.");
PreparedStatement statement = conn.prepareStatement(sql);
for (int j = 0; j < TOTAL_ROW_COUNT / BATCH_ROW_COUNT; j++) {
long batchStart = System.currentTimeMillis();
for (int i = 0; i < BATCH_ROW_COUNT; i++) {
long id = j * BATCH_ROW_COUNT + i;
String name_pre = String.valueOf(id);
statement.setLong(1, id);
statement.setString(2, name_pre);
statement.setString(3, name_pre);
statement.addBatch();
}
System.out.println("It's up to batch count: " + BATCH_ROW_COUNT);
statement.executeBatch();
conn.commit();
long batchEnd = System.currentTimeMillis();
System.out.println("Batch data commit finished. Time cost: " + (batchEnd - batchStart));
}
long end = System.currentTimeMillis();
System.out.println("All data insert finished. Total time cost: " + (end - start));
}

开始设置BATCH_ROW_COUNT为5w，结果报错：

java.sql.BatchUpdateException: Got temporary error 233 'Out of operation records in transaction coordinator (increase MaxNoOfConcurrentOperations)' from NDBCLUSTER

意思比较明显，超过了MaxNoOfConcurrentOperations设置的值。该值默认为：32768。你可以通过修改config.ini里的配置改变默认值。不过有人提到，修改该值的同事，你也需要修改

MaxNoOfLocalOperations的值，并且建议后者的值超过前者值10%左右（1.1倍）。

这里为了避免麻烦，我们直接将代码的里预设值调小到2w，再运行代码。

Begin to prepare statement.
It's up to batch count: 20000
Batch data commit finished. Time cost: 20483
It's up to batch count: 20000
Batch data commit finished. Time cost: 19768
It's up to batch count: 20000
Batch data commit finished. Time cost: 20136
It's up to batch count: 20000
Batch data commit finished. Time cost: 19958
…….
java.sql.BatchUpdateException: The table 'bigdata_cluster' is full

无语……表满了。共写入了88w条数据。每次batch写入时间稳定。再测试条件查询耗时：

/**
  * 查询特定的一个或者一组数据，打印查询耗时
  *
  * @param conn
  * @param tableName
  * @author lihzh
  * @throws SQLException
  * @date 2013-1-17 下午4:46:20
  */
private void searchData(Connection conn, String tableName) throws SQLException {
long start = System.currentTimeMillis();
String sql = "select * from " + tableName + " where name = ?";
PreparedStatement statement = conn.prepareStatement(sql);
statement.setString(1, "300");
ResultSet resultSet = statement.executeQuery();
resultSet.first();
System.out.println("Name is: " + resultSet.getObject("name"));
long end = System.currentTimeMillis();
System.out.println("Query one row from 88w record cost time: " + (end - start));
}

通过另一个sql节点，根据没有索引的name字段查询耗时约1.4s，有索引的id查询耗时20ms左右。

再新建一个表，发现什么数据再也无法写入，看来是数据节点全局容量限制导致的。修改config.ini文件中的

DataMemory=80M    # How much memory to allocate for data storage
IndexMemory=18M   # How much memory to allocate for index storage
                  # For DataMemory and IndexMemory, we have used the
                  # default values. Since the "world" database takes up
                  # only about 500KB, this should be more than enough for
                  # this example Cluster setup.

分别改为1400和384M。重启集群。再通过

ndb_mgm> all report memoryusage

命令查看使用情况，

似乎恢复了正常。再向新表写入数据，成功。

测试删除数据，又遇到提示：

ERROR 1297 (HY000): Got temporary error 233 'Out of operation records in transaction coordinator (increase MaxNoOfConcurrentOperations)' from NDBCLUSTER

看来真的得调整MaxNoOfConcurrentOperations参数的大小了。根据虚拟机内存情况（据说1约需要1kb内存。因此10w，大约100m内存），调整如下：

MaxNoOfConcurrentOperations=300000
MaxNoOfLocalOperations=330000

重启，测试删除11w数据，通过。同时，再次测试向新表写入100w条数据，以20w为一组，也顺利通过了。

It's up to batch count: 200000
Batch data commit finished. Time cost: 268642
It's up to batch count: 200000
Batch data commit finished. Time cost: 241301
It's up to batch count: 200000
Batch data commit finished. Time cost: 209329
It's up to batch count: 200000
Batch data commit finished. Time cost: 207634
It's up to batch count: 200000
Batch data commit finished. Time cost: 241746
All data insert finished. Total time cost: 1168703

目前的使用情况大致如此，接下来OneCoder打算测试一下集群节点添加和数据自动分区读写情况。等有了结论在与大家分享。

实验需要，OneCoder打算亲自部署一下MySQL Cluster环境。VMware环境中，虚拟化三台CentOS5.4 x64虚拟机。

10.4.44.201 SQL
10.4.44.202 Data
10.4.44.203 Manager

用于部署。

官方文档自然是最好的部署手册，先简单了解一下。

MySQL Cluster构成

Each MySQL Cluster host computer must have the correct executable programs installed. A host running an SQL node must have installed on it a MySQL Server binary (mysqld). Management nodes require the management server daemon (ndb_mgmd); data nodes require the data node daemon (ndbd or ndbmtd). It is not necessary to install the MySQL Server binary on management node hosts and data node hosts. It is recommended that you also install the management client (ndb_mgm) on the management server host.

SQL节点，必须部署MySQL Server binary(mysqld)；管理(Management) 节点，需要部署management server daemon(ndb_mgmd)；数据(data)节点，需要部署data node daemon(ndbd 或者 ndbmtd)。无需在管理和数据节点上部署MySQL Server binary。推荐在管理节点上，也部署management client(ndb_mgm)。

MySQL Cluster配置（翻译自官方文档）

每个data和SQL节点都需要一个my.cnf文件，其中包含了两条重要的信息：一个链接串指明management节点位置，一条针对data节点，告诉MySQL服务器开启NDBCLUSTER存储引擎。
management节点需要config.ini配置文件，里面保存着它需要管理的集群节点的信息、保存数据和各data节点数据索引所需的内存信息，data节点的位置信息，
有了这些理论基础，下面我们来动手操作一下

先部署data和SQL节点， 下载MysQL Cluster压缩包 ，通过putty自带的pscp工具，拷贝到各个节点linux虚拟机中。

解压。

先配置SQL和Data节点。在/etc下放置my.cnf配置文件。内容如下：

[ndbcluster]
ndb-connectstring=10.4.44.203
[mysql_cluster]
ndb-connectstring=10.4.44.203

再配置Manager

同样先将压缩包拷贝，然后在/var/lib/mysql-cluster/config.ini 配置：[ndbd default]

# Options affecting ndbd processes on all data nodes:
NoOfReplicas=1    # Number of replicas
DataMemory=80M    # How much memory to allocate for data storage
IndexMemory=18M   # How much memory to allocate for index storage
                  # For DataMemory and IndexMemory, we have used the
                  # default values. Since the "world" database takes up
                  # only about 500KB, this should be more than enough for
                  # this example Cluster setup.

[ndb_mgmd]
# Management process options:
hostname=10.4.44.203           # Hostname or IP address of MGM node
datadir=/var/lib/mysql-cluster  # Directory for MGM node log files

[ndbd]
# Options for data node "A":
                                # (one [ndbd] section per data node)
hostname=10.4.44.202          # Hostname or IP address
datadir=/usr/local/mysql/data   # Directory for this data node's data files

[mysqld]
# SQL node options:
hostname=10.4.44.201          # Hostname or IP address
                                            # (additional mysqld connections can be
                                        # specified for this node for various
                                                # purposes such as running ndb_restore)

启动MySQL Cluster：

先启动Management节点:

shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini

再启动data

shell>ndbd

和SQL节点shell> groupadd mysql

shell> useradd -r -g mysql mysql
shell> cd /usr/local
shell> tar zxvf /path/to/mysql-VERSION-OS.tar.gz
shell> ln -s full-path-to-mysql-VERSION-OS mysql
shell> cd mysql
shell> chown -R mysql .
shell> chgrp -R mysql .
shell> scripts/mysql_install_db
shell> bin>mysqld

成功。在management节点，利用./ndb_mgm查看状态。

ndb_mgm>show.

部署成功。

OneCoder注：这里一开始有一个误区，就是我根据文档误以为SQL节点部署的MySQL Server版本而不是Cluster版本，导致耽误了很多时间。今天看一个错误出神的时候，才突然醒悟，我是不是搞错了。连忙替换了版本，这才成功。