为什么我们会选择NDB引擎呢？
我想可能有这么两点需求：
1.我们需要高可用，传说中的FIVE NINE
2.我们需要高性能，多SQL节点提供更好的并发服务
由此出发，看起来NDB引擎都能满足。可是为啥真正使用CLUSTER之后，发现，其实并不是像想象中的那么美好？我们从MYSQL CLUSTER的架构上来看看。
MySQL Cluster 由三类节点组成：
1、 数据节点（Data Nodes） 存储所有属于 MySQL Cluster 的数据。这些数据在数据
节点之间被复制以保证在一个或多个节点出现故障时集群仍然持续可用。 而且数据节点也管
理数据库的事务处理。 随着数据复制份数的增加整个系统的数据冗余性相应提高。 应用程序
使用 NDB API 直接访问数据节点，而不是通过 MySQL 服务器。
2、 管理节点(Management Server Nodes) 控制系统启动时的初始配置，在集群设置
发生改变时又被重新利用。通常只需配置一个管理节点；然而为了排除单点故障需要，有可
能的话，请增加管理节点的数量。以提供管理操作的高可用性。
管理节点只在集群启动和系统重配置后起作用， 集群启动以后， 无论管理节点处于什么状态，
整个集群都将保持其在线和可用状态。
3、 MySQL 节点(MySQL Server Nodes) 用于存取集群数据节点上的数据，给软件开
发者提供了一个标准的 SQL 语言编程接口。MySQL 服务节点负责向数据节点传送访问请
求，这使 MySQL 使用者无需知道具体的集群过程，也无需进行数据库操作的底层编程。特
别是通过增加 MySQL 服务节点数量，就可以提高集群系统性能。这种设计给 MySQL 增
加可扩展性、数据规模和系统性能提供了更广的方法和措施。
应用程序如果对实时性能要求较高， 请直接使用 NDB API， 而不是通过 MySQL 节点。
现在可以使用 C++,Java,HTTP 版本的 NDB API， 这给开发人员提供了极大的方便， 并且使
得 MySQL 集群可以应用于广泛的 web 和企业级应用。
数据库在内部被分割为一个个分区， 这些分区分布于数据节点之间。 为了避免单点故
障，至少会有两个以上的节点会用于存储特定分区的数据，这些节点组成一个节点组。
