前言

本文，主要是介绍一下如何利用  MySQL Cluster 的特性来提高我们系统的整体可用性。

由于  MySQL Cluster 本身就是一个完整的分布式架构的系统，而且支持数据的 多点冗余存放， 数据实时同步等特性。所以可以说他天生就已经具备了实现高可靠性的条件了，是否能够在实际应用中满足要求，主要就是在系统搭建配置方面的合理设置了。

由于  MySQL Cluster 的架构主要由两个层次两组集群来组成，包括  SQL 节点（ mysqld） 和  NDB 节点（数据节点），所有两个层次都需要能够保证高可靠性才能保证整体的可靠性。下面我们从两个方面分别来介绍  MySQL Cluster 的高可靠性。

一、SQL 节点的高可靠性保证

MySQL Cluster 中的  SQL 节点实际上就是一个多节点的  mysqld 服务，并不包含任何数据。所以， SQL 节点集群就像其他任何普通的应用服务器一样，可替代性很高，只要安装了支持  MySQL Cluster 的  MySQL Server 端即可。

当该集群中的一个  SQL 节点  crash 掉之后，由于只是单纯的应用服务，所以并不会造成任何的数据丢失。只需要前端的应用数据源配置兼容了集群中某台主机  crash 之后自动将该主机从集群中去除就可以了。实际上，这一点对于应用服务器来说是非常容易做到的，无论是通过自行开发判断功能的代理还是通过硬件级别的负载均衡设备，都可以非常容易做到。当然，前提自然也是剩下的  SQL 节点能够承担整体负载才行。

如上图，当  SQL 1 crash 之后，实际上仅仅只是访问到数据的很多条途径中的某一条中断了，实际上仍然还有很多条途径可以获取到所需要的数据。而且，由于  SQL 的可替代性很高，所以更换也非常简单，即使更换整台主机，也可以在短时间内完成。

二、NDB 节点的高可靠性保证

MySQL Cluster 的数据冗余是有一个前提条件的，首先必须要保证有足够的节点，实际上是至少需要 2 个节点才能保证数据有冗余，因为， MySQL Cluster 在保存冗余数据的时候 ，是比需要确保同一份数据的冗余存储在不同的节点之上。在保证了冗余的前提下， MySQL Cluster 才会将数据进行分区。

假设我们存在 4 个  NDB 节点，数据被分成 4 个  partition 存放，数据冗余存储，每份数据存储 2 份，也就是说  NDB 配置中的  NoOfReplicas 参数设置为 2，4 个节点将被分成 2 个  NDB Group。

所有数据的分布类似于下图所示：

在这样的配置中，假设我们  NDB Group 0 这一组中的某一个  NDB 节点（假如是 NDB 1）出现问题，其中的部分数据（假设是 part 1）坏了，由于每一份数据都存在一个 冗余拷贝，所以并不会对系统造成任何的影响，甚至完全不需要人为的操作， MySQL 就可以继续正常的提供服务。

假如我们两个节点上面都出现部分数据损坏的情况，结果会怎样？如下图：

如果像上图所示，如果两个损坏部分数据的节点属于同一个  NDB Group，只要损坏部分并没有包含完全相同的数据，整个  MySQL Cluster 仍然可以正常提供服务。但是，如果损坏数据中存在相同的数据，即使只有很少的部分，都会造成  MySQL Cluster 出现问题，不能完全正常的提供服务。此外，如果损坏数据的节点处于两个不同的  NDB Group，那么非常幸运，不管损坏的是哪一部分数据，都不会影响  MySQL Cluster 的正常服务。

可能有朋友会说，那假如我们的硬件出现故障，整个  NDB 都  crash 了呢？是的，确实很可能存在这样的问题，不过我们同样不用担心，如图所示：

假设我们整个  NDB 节点由于硬件（或者软件）故障而  crash 之后，由于  MySQL Cluster保证了每份数据的拷贝都不在同一台主机上，所以即使整太主机都  crash 了之后， MySQL Cluster 仍然能够正常提供服务，就像上图所示的那样，即使整个  NDB 1 节点都  crash 了 ，每一份数据都还可以通过  NDB 2 节点找回。

那如果是同时  crash 两个节点会是什么结果？首先可以肯定的是假如我们  crash 的两个节点处于同一个  NDB Group 中的话，那  MySQL Cluster 也没有办法了，因为两份冗余的数据都丢失了。但是只要  crash 的两个节点不在同一个  NDB Group 中， MySQL Cluster就不会受到任何影响，还是能够继续提供正常服务。如下图所示的情况：

从上面所列举的情况我们可以知道， MySQL Cluster 确实可以达到非常高的可靠性，毕竟同一时刻存放相同数据的两个  NDB 节点都出现大故障的概率实在是太小了，要是这也能够被遇上，那只能自然倒霉了。

当然，由于  MySQL Cluster 之前的老版本需要将所有的数据全部  Load 到内存中才能正常运行，所有由于受到内存空间大小的限制，使用的人非常少。现在的新版本虽然已经支持仅仅只需要所有的索引数据  Load 到内存中即可，但是由于实际的成功案例还并不是很多，而且发展时间也还不是太长，所以很多用户朋友对于  MySQL Cluster 目前还是持谨慎态度，大部分还处于测试阶段。