LVS+Keepalived

LVS负载集群：

IPVS:工作在内核

ipvsadm:管理IPVS

keepalived和ipvsadm并行的，都可以直接管理内核ipvs。

keepalived和LVS亲密无间，keepalived就是为LVS诞生。

LVS技术小结：

1真正实现调度的工具是IPVS，工作在linux内核层面。

2LVS自带的IPVS管理工具是ipvsadm。

3keepalived实现管理IPVS及负载均衡器的高可用。

4Red hat工具Piranha WEB管理实现调度的工具IPVS。

LVS术语：

VIP：虚拟IP；

RIP:真是IP;

DIP:Director IP;

CIP:客户端主机IP;

LVS集群的四种模式：

NAT

DR

TUN

FULLNAT

ARP协议：

全称"Address Resolution Protocol"：地址解析协议；IP地址转换成相应的物理地址（MAC地址）；

ARP小结：

1ARP全称

2实现局域网把IP地址转换为MAC地址

3MAC 48位主机的物理地址，局域网内唯一

4ARP协议和DNS有点相似之处。不同点是：DNS是在域名和IP之间的解析，另外，ARP协议不需要配置服务

，而DNS要配置服务才行。

5ARP协议是三层协议

LVS DR模式：

1通过更改数据包的目标MAC地址实现数据包转发的。注意源IP地址仍是CIP，目的IP地址仍是VIP。

2请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此，并发访问量大时使用效率很高（和NAT模式比）

3因DR模式是通过MAC地址的改写机制实现的转发，所有节点和LVS要处于一个局域网

4需要注意RS节点的VIP的绑定（lo：vip/32,lo1:vip/32）和ARP抑制问题

5RS节点的默认网关不需要是调度器LB的DIP，而直接是IDC机房分配的上级路由器的IP（这是RS带有外网IP

地址的情况），理论讲：只要RS可以出网即可，不是必须要配置外网IP。

6目的MAC地址的改写，调度器LB无法该变请求的报文的目的端口（和NAT的区别）

7调度器LB支持几乎所有的UNIX，LINUX系统，不支持WINDOWS系统。真实服务器RS节点可以是WINDOWS系统。

8DR模式效率高，配置麻烦，访问量不大的情况，可以用haproxy、nginx，日1000-2000w PV或1万以下

9直接对外的访问业务，例如：web服务做RS节点，RS最好用公网IP地址。如果不直接对外的业务，例如：MySQL，

存储系统RS节点，最好用内部IP地址。

NAT模式：入站DNAT，出站SNAT，入站出站都经过LVS，可以修改端口

DR模式：修改数据包的目的MAC地址，入站经过LVS，出站不经过LVS，直接返回客户，不能改端口，适合局域网LAN。

TUN模式：不改变数据包内容，数据包外部封装一个IP头，入站经过LVS，出站不经过LVS，直接返回客户，不能改端口，适合局域网LAN/WAN。

LVS和节点之间通过隧道通信。

LVS调度算法：

固定算法： rr（轮询）， wrr（权重轮询），dh（目标地址哈希），sh（源地址哈希）

动态算法：wlc（加权最小连接），lc（最小连接），lblc，lblcr，SED，NQ

WEB

LB01(nginx+keepalived) 10013

VIP:100131

LB02(nginx+keepalived) 10015

VIP:100132

WEB1 10016 LAMP RS1(真实服务器)

WEB2 10019 LNMP RS2(真实服务器)

安装LVS

安装准备命令：lsmod|grep ip_vs（验证keepalived是否安装）

安装LVS：①yum install ipvsadm -y3、②命令：ipvsadm(有则安装成功)

配置IP

1ping IP，起初选的IP是ping不通。以100131为例（IP随意分配），添加这个IP

2lb01:添加一个IP-->ip addr add 100131/24 dev eth0 label eth0:1

LB01（LVS的配置过程）

第一步：

新安装,清除列表,重头再来

ipvsadm -C

第二步：

添加IP（虚拟服务）/V server

指定IP：

ipvsadm -A -t 100131:80 -s rr

查看IP：

ipvsadm -LN

// TCP 100131:80 rr(V server,但没有节点)

添加RS1节点：

ipvsadm -a -t 100131:80 -r 10016:80 -g

查看：

ipvsadm -Ln

// TCP 100131:80 rr

// --> 10016:80 Route 1 0 0 (新增加了一个节点)

添加RS2节点：

ipvsadm -a -t 100131:80 -r 10019:80 -g

查看：

ipvsadm -Ln

// TCP 100131:80 rr

// --> 10016:80 Route 1 0 0

// --> 10019:80 Route 1 0 0 (新增加了一个节点)

##如果节点导错了，可以删除，重新导

ipvsadm -d -t 100131:80 -r 10019:80

ipvsadm -Ln

// TCP 100131:80 rr

// --> 10016:80 Route 1 0 0

&&可以增加会话保持

-p (会话保持时间)

ipvsadm -A -t 100131:80 -s rr -p 300

&&设置超时参数

ipvsadm --set 30 5 60

第三步：

在负载均衡上做一个host解析：

vi /etc/hosts

10016 wwwetiantianorg bbsetiantianorg( 以此为例，对其他的IP也要验证)

测试VIP，RIP1,RIP2能不能访问：

①ping wwwetiantianorg

②curl wwwetiantianorg

注意：对VIP测试，要特别注意，一般不要再负载均衡器上测试，要选择别的客户端（真正的客户端）来验证。

第四步

RS绑定VIP

ip addr add 100131/32 dev lo label lo:1 临时生效

route add -host 100131 dev lo

第五步

对RS抑制ARP响应方法如下：

echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore

echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce

echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore

echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce

LVS缺点：只能手工配置，没有健康检查

健康检查功能：

如果其中一台服务器停止了，LVS没有健康检查功能，所以ipvsadm -Ln列表中还有这台服务器。

LVS裂脑问题？？？

LVS故障排查：

熟悉LVS的工作原理

1调度器上LVS调度规则及IP的正确性

2RS节点上VIP绑定和arp抑制的检查

生产处理思路：

1）对RS绑定的VIP做实时监控；

2）RS绑定的VIP做成配置文件

keepalived解决了几个问题：a管理的问题；b健康检查的问题；cLVS的高可用

Keepalived配置

1vi keepalivedconf

2ip addr del 100132/24 dev eth0

3ipvsadm -C

ES支持集群模式，是一个分布式系统，其好处主要有两个∶

es集群由多个ES 实例组成。不同集群通过集群名字来区分，可通过 clustername 进行修改，默认为elasticsearch。每个ES实例本质上是一个 JVM 进程，且有自己的名字，通过 nodename 进行修改

ES集群相关的数据称为 cluster state ，主要记录如下信息∶节点信息，比如节点名称、连接地址等；索引信息，比如索引名称、配置等

可以修改 cluster state 的节点称为master节点，一个集群只能有一个 cluster state 存储在每个节点上，master维护最新版本并同步给其他节点

master节点是通过集群中所有节点选举产生的，可以被选举的节点称为 master-eligible 节点 ，相关配置如下: nodemaster: true

处理请求的节点即为coordinating节点，该节点为所有节点的默认角色，不能取消。路由请求到正确的节点处理，比如创建索引的请求到master节点

存储数据的节点即为data节点，默认节点都是data类型，相关配置如下∶ nodedata: true

谈及副本和分片两个概念之前，我们先说一下这两个概念存在的意义： 解决系统可用性和增大系统容量

我们想象这样一个场景，我们的数据只存放在一台ES服务器上，那么一旦这台ES出现宕机或者其他不可控因素影响的话，我们除了丧失了服务的可用性外，可能还存在着数据丢失的可能。同时，单机服务的存储容量也无法应对项目对大数据量的要求。

系统可用性可以分为 服务可用性 和 数据可用性

服务可用性 含义为：当前服务挂掉后，是否有其他服务器顶替当前节点提供服务支持。

数据可用性 含义为：当前服务挂掉后，存储在当前服务器上的数据，是否还可以对外提供访问和修改的服务。

副本可以理解为是某个数据的复制体，副本和源数据内容一致。副本的存在可以有效地满足系统可用性的需求，比如说，我们可以在原有节点的基础上复制一个和源节点一模一样的节点，这样一旦原有节点挂掉了，另外一个节点也还是可以替代源节点提供服务，而且复制出来的节点拥有和源节点一样的数据，这样也保障了数据可用性。

我们在上一小节讲到可以使用副本来解决系统可用性的问题，但是这里存在一个问题，不管存在多少个副本（节点），都无法增大源节点的存储空间。在这个问题上，ES引入了Shard分片这个概念来解决问题。

看完分片的特点后可能还有人不太清楚到底什么是分片，其实分片是n/1个源节点数据。比如说原ES集群中只有一个主节点，所有的索引数据都存储在这个节点上。现在我们将某个索引数据分成3份，分别存放在3个ES节点上，那么每台ES服务器上就各自有1个分片shard。该索引的所有节点Shard分片的集合，就是索引的全部数据。

下面我们来演示一下：

为了更好的了解ES的分片机制，大家不妨在上面的案例上进一步思考两个问题：

答案是不能。原因是我们创建索引时定义的分片数量只有3个，且都已经落在了3个节点上。所以即使再增加多一个节点，也不会有对应的Shard分片可以落在新的节点上，并不能扩大 test_shard_index 的数据容量。

答案是不能。因为新增的副本也是分布在这3个节点上，还是利用了同样的资源。如果要增加吞吐量，还需要新增节点。

通过上面两个问题，相信大家已经可以认识到分片的重要性，分片数过小，会导致后续无法通过增加节点实现水平扩容；（副本）分片数过大会导致一个节点上分布过多分片，造成资源浪费，同时会影响查询性能

集群健康状况，包括以下三种: green健康状态，指所有主副分片都正常分配； yellow指所有主分片都正常分配，但是有副本分片未正常分配； red表示有主分片未分配

我们可以通过这个api查看集群的状态信息： GET _cluster/health

我们也可以通过cerebro或者head插件来直接获取当前集群的状态

需要注意的是，即使当前集群的状态为 red ，也并不代表当前的ES丧失了提供服务的能力。只是说未被分配主分片的索引无法正常存储和操作而已。

这里故障转移的意思是，当ES集群出现某个或者多个节点宕机的情况，ES实现服务可用性的应对策略。

这里我们新建一个分片为3，副本为1的索引，分片分别分布在三个节点，此时集群为 green

当master节点所在机器宕机导致服务终止，此时集群会如何处理呢

我们可以看到，从node1主节点宕机到ES恢复集群可用性的过程中，ES有着自己的故障转移机制，保障了集群的高可用性。我们也可以在自己的本地上去进行试验，建好索引后，kill掉主节点，观察集群状态就行。

同时，此时就算node2宕机了，那么node3也能够很快的恢复服务的提供能力。

我们知道，我们创建的文档最终会存储在分片上，那么在分布式集群的基础上，ES集群是怎么判断当前该文档最终应该落在哪一个分片上呢？

很显然，我们需要一个可以实现文档均匀分布到各个分片上的映射算法，那么常见的随机算法和round-robin（轮询）算法可以满足需要吗？答案是不可以，这两个算法虽然可以实现文档均匀分布分片的存储需要，但是当我们通过 DocumentId 查询文档时，ES并不能知道这个文档ID到底存储在了哪个节点的分片上，所以只能够从所有分片上检索，时间长。如果我们为这个问题建立一个文档和分片映射关系的表，虽然确实可以快速定位到文档对应的存储分片，但是当文档的数据量很大的时候，那么检索的效率也会随之变低。

对于上面这个问题，ES提供的解决方法是 建立文档到分片的映射算法

es 通过如下的公式计算文档对应的分片：

hash算法 保证可以将数据均匀地分散在分片中

routing 是一个关键参数，默认是文档id，也可以自行指定

number_of_primary_shards 是主分片数

我们可以看到，该算法与主分片数相关， 这也是分片数一旦确定后便不能更改的原因

我们已经知道了ES是如何将文档映射到分片上去了，下面我们就来详细讲解一下文档创建、读取的流程。

脑裂问题，英文为 split-brain ，是分布式系统中的经典网络问题，如下图所示:

3个节点组成的集群，突然node1的网络和其他两个节点中断

解决方案为 仅在可选举master-eligible节点数大于等于quorum时才可以进行master选举

在讲文档搜索实时性之前，先讲一下倒排索引的不可变更特性。由于倒排索引一旦生成，不可变更的特定，使得其有着以下3点好处：

下面，将针对Lucene实现文档实时性搜索的几个动作进行讲解，分析其是如何在新增文档后实现ES的搜索实时性的。

我们从上面的描述中知道，当我们新增了一个文档后会新增一个倒排索引文件 segment ，但是 segment 写入磁盘的时间依然比较耗时（难以实现实时性），所以ES借助文件系统缓存的特性， 先将 segment 在缓存中创建并开放查询来进一步提升实时性 ，该过程在es中被称为refresh。

在refresh之前文档会先存储在一个buffer中，refresh时将 buffer中的所有文档清空并生成 segment

es默认每1秒执行一次refresh，因此文档的实时性被提高到1秒 ，这也是es被称为近实时(Near Real Time)的原因

reflush虽然通过 将文档存放在缓存中 的方式实现了秒级别的实时性，但是如果在内存中的segment还没有写入磁盘前发生了宕机，那么其中的文档就无法恢复了，如何解决这个问题呢

ES 引入 translog 机制。写入文档到 buffer 时，同时将该操作写入 translog 中。

translog文件会即时写入磁盘(fsync)，在ES 6x中，默认每个请求都会落盘，我们也可以修改为每5秒写一次，这样风险便是丢失5秒内的数据，相关配置为indextranslog。同时ES每次启动时会检查translog 文件，并从中恢复数据。

flush 负责将内存中的segment写入磁盘，主要做如下的工作:

Reflush和Flush执行的时机

ES的做法是 首先删除文档，然后再创建新文档

我们上面提到，新增文档是通过新建segment来解决，删除文档是通过维护del文件来进行的，假如现在我们设置的 reflush 时间间隔为1秒，那么一小时单个ES索引就会生成3600个segment，一天下来乃至一个月下来会产生的segment文件数量更是不可想象。为了解决Segment过多可能引起的性能下降问题，ES中采用了Segment Merging（即segment合并）的方法来减少segment的数量。

执行合并操作的方式有两种，一种是ES定时在后台进行 Segment Merging 操作，还有一种是我们手动执行 force_merge_api 命令来实现合并操作。

Keepalived软件起初是专为LVS负载均衡软件设计的，用来管理并监控LVS集群系统中各个服务节点的状态，后来又加入了可以实现高可用的VRRP功能。因此，Keepalived除了能够管理LVS软件外，还可以作为其他服务（例如：Nginx、Haproxy、MySQL等）的高可用解决方案软件。

Keepalived采用是模块化设计，不同模块实现不同的功能。

keepalived主要有三个模块，分别是core、check和vrrp。

core ：是keepalived的核心，负责主进程的启动和维护，全局配置文件的加载解析等

check ： 负责healthchecker(健康检查)，包括了各种健康检查方式，以及对应的配置的解析包括LVS的配置解析；可基于脚本检查对IPVS后端服务器健康状况进行检查

vrrp ：VRRPD子进程，VRRPD子进程就是来实现VRRP协议的

keepalived 配置文件：

Keepalived 配置文件为：keepalivedconf；

主要有三个配置区域，分别是：全局配置(Global Configuration)、VRRPD配置、LVS配置 

全局配置又包括两个子配置： 全局定义(global definition) 静态IP地址/路由配置(static

ipaddress/routes)

Keepalived服务VRRP的工作原理：

Keepalived高可用对之间是通过 VRRP进行通信的， VRRP是通过竞选机制来确定主备的，主的优先级高于备，因此，工作时主会优先获得所有的资源，备节点处于等待状态，当主宕机的时候，备节点就会接管主节点的资源，然后顶替主节点对外提供服务

在Keepalived服务对之间，只有作为主的服务器会一直发送 VRRP广播包,告诉备它还活着，此时备不会抢占主，当主不可用时，即备监听不到主发送的广播包时，就会启动相关服务接管资源，保证业务的连续性接管速度最快

出现脑裂的原因：

高可用服务器对之间心跳线链路发生故障，导致无法正常通信。

因心跳线坏了（包括断了，老化）。

因网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）

因心跳线间连接的设备故障（网卡及交换机）

因仲裁的机器出问题（采用仲裁的方案）

高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。

高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败

其他服务配置不当等原因，如心跳方式不同，心跳广插冲突、软件Bug等。

如何解决脑裂：

① 同时使用串行电缆和以太网电缆连接，同时用两条心跳线路，这样一条线路坏了，另一个还是好的，依然能传送心跳消息。

② 当检测到裂脑时强行关闭一个心跳节点（这个功能需特殊设备支持，如Stonith、feyce）。相当于备节点接收不到心跳消患，通过单独的线路发送关机命令关闭主节点的电源。

③ 做好对裂脑的监控报警（如邮件及手机短信等或值班）在问题发生时人为第一时间介入仲裁，降低损失。管理员可以通过手机回复对应数字或简单的字符串操作返回给服务器让服务器根据指令自动处理相应故障这样解决故障的时间更短。

一、实验环境

操作系统：CentOS72 Minial

###################

serverA：

eno16777736    1921681104

eno33554984    1921681105

##########################

serverB：

eno16777736    1921681109

eno33554984    1921681106

###########################

vip01:1921681111

vip02：1921681112

二、设置防火墙

/usr/bin/firewall-cmd --direct

--permanent --add-rule ipv4 filter INPUT 0 --in-interface eth0 --destination ${组播地址} --protocol vrrp -jACCEPT

/usr/bin/firewall-cmd --reload

三、软件安装

在serverA和serverB上

# rpm -ivh --force libnl3-3228-4el7x86_64rpm

# rpm -ivh --forcelm_sensors-libs-340-420160601gitf9185e5el7x86_64rpm

# rpm -ivh --force net-snmp-agent-libs-572-32el7x86_64rpm

# rpm -ivh --force net-snmp-libs-572-32el7x86_64rpm

# rpm -ivh --force ipset-libs-638-3el7_6x86_64rpm

# rpm -ivh --force keepalived-135-6el7x86_64rpm

四、配置keepalived

如果不使用 VRRP Sync Groups 如果keepalived 主机有两个网段，每个网段开启一个VRRP 实例，如果对外的网段出现问题，VRRPD认为自己仍然认为健康，因此 Master和Backup 相互切换，从而导致服务不能正常使用，同时高可用集群也不能正常运行，Sync group 就是为了解决该问题，可以把两个实例放进同一个Sync Group 中！

serverA

# vim /etc/keepalived/keepalivedconf

######################################

! Configuration File for keepalived

global_defs {

router_id LVS_DEVEL

}

vrrp_sync_group VG1 {

group {

VI_1

VI_2

}

}

vrrp_instance VI_1 {

state BACKUP

interface eno16777736

virtual_router_id 51

priority 100

nopreempt

advert_int 1

authentication {

auth_type PASS

auth_pass 1111

}

track_interface {

eno16777736

eno33554984

}

virtual_ipaddress {

1921681111

}

}

vrrp_instance VI_2 {

state BACKUP

interface eno33554984

virtual_router_id 52

priority 100

nopreempt

advert_int 1

authentication {

auth_type PASS

auth_pass 2222

}

track_interface {

eno16777736

eno33554984

}

virtual_ipaddress {

1921681112

}

}

serverB

# vim /etc/keepalived/keepalivedconf

######################################

! Configuration File for keepalived

global_defs {

router_id LVS_DEVEL

}

vrrp_sync_group VG1 {

group {

VI_1

VI_2

}

}

vrrp_instance VI_1 {

state BACKUP

interface eno16777736

virtual_router_id 51

priority 90

nopreempt

advert_int 1

authentication {

auth_type PASS

auth_pass 1111

}

track_interface {

eno16777736

eno33554984

}

virtual_ipaddress {

1921681111

}

}

vrrp_instance VI_2 {

state BACKUP

interface eno33554984

virtual_router_id 52

priority 90

nopreempt

advert_int 1

authentication {

auth_type PASS

auth_pass 2222

}

track_interface {

eno16777736

eno33554984

}

virtual_ipaddress {

1921681112

}

}

五、测试

在serverA 和 serverB上

# systemclt start  keepalived

在serverA

本篇文章的目的在于介绍MySQL Cluster——也就是MySQL的一套内存内、实时、可扩展且具备高可用性的版本。在解决标题中所提到的每秒2亿查询处理能力问题之前，我们先对MySQL集群的背景信息及其架构进行一番回顾，这将有助于大家理解上述目标的实现过程。

MySQL Cluster介绍

MySQL Cluster是一套具备可扩展能力、实时、内存内且符合ACID要求的事务型数据库，其将99999%高可用性与低廉的开源总体拥有成本相结合。在设计思路方面，MySQL Cluster采用一套分布式多主架构并借此彻底消灭了单点故障问题。MySQL Cluster能够横向扩展至商用硬件之上，能够通过自动分区以承载读取与写入敏感型工作负载，并可通过SQL与NoSQL接口实现访问。

作为一套最初被设计为嵌入式电信数据库、用于实现内网应用运营商级可用性及实时性能的解决方案，MySQL Cluster已经通过众多新型功能集的强化而得到快速发展，从而将用例范围扩展到Web、移动以及企业级应用程序等部署在内部或者云环境下的实例当中，具体包括：大规模OLTP(实时分析)电子商务、库存管理、购物车、支付处理、订单追踪、在线游戏、金融交易与欺诈检测、移动与微支付、会话管理与缓存、数据流供应、分析与建议、内容管理与交付、通信与呈现服务、订阅/用户配置管理与补贴等等。

MySQL Cluster架构概述

在面向应用程序的事务流程背后，存在着三种负责将服务交付至应用程序的节点类型。下图所示为一套简单的示例型MySQL Cluster架构，其由十二套被划分为六个节点组的Data Node构成。

Data Node属于MySQL Cluster当中的主节点。它们负责提供以下功能：内存内与基于磁盘数据的存储与管理、表的自动化与用户定义型划分(即分区)、在不同数据节点间进行数据副本同步、事务与数据检查、自动故障转移以及用于实现自我修复的故障后自动重新同步。

各种表会在多个数据节点当中进行自动分区，而且每个数据节点作为一个写入操作的接收主体，这就使其能够轻松将写入敏感型工作负载分布至多个商用节点之上，同时保证应用程序的完全透明化。

通过将数据保存并分发至一套无共享架构——也就是不使用任何共享磁盘——当中，并至少为数据同步至一套副本内，MySQL Cluster能够保证在单一Data Node出现故障时、用户至少还拥有另一个存储有相同信息的Data Node。如此一来，请求与事务处理流程将以无中断方式继续提供令人满意的运作效果。任何由于Data Node故障所引发的短暂故障转移窗口(时间在秒以下)而无法正常完成的事务流程都将被回滚并重新执行。

我们可以为数据选择存储方式，包括全部保存在内存内或者将一部分数据只在在磁盘之上(仅限于非索引数据)。内存内存储对于那些需要经常进行变更的数据(也就是活跃工作组)而言意义重大。保存在内存内的数据会定期进行指向本地磁盘的检查，并与全部Data Node进行协调，这样MySQL Cluster就能够在整体系统发生故障时——例如供电中断——得以全面恢复。基于磁盘的数据能够被用于存储对性能要求较低的数据，而这类数据集往往大于可用内存空间。正如其它大部分数据库服务器一样，MySQL Cluster会利用页面缓存机制将基于磁盘且访问频率较高的数据缓存在Data Node的内存当中，从而增加其实际性能表现。

Application Node负责提供由应用程序逻辑到数据节点的连接。应用程序可以利用SQL访问该数据库，具体而言通过一台或者多台MySQL服务器向处于同一套MySQL Cluster内的存储数据执行SQL接口功能。在MySQL Server当中，我们可以使用任何一种标准化MySQL连接机制，这意味着大家拥有非常丰富的访问技术可供选择。另外，一套名为NDB API的高性能(基于C++)接口可被用于实现附加控制、改善实时行为并带来更理想的吞吐能力。NDB API的层能够帮助额外NoSQL接口绕过SQL层而直接访问该集群，如此一来不仅延迟有所降低、开发人员也有获得更理想的灵活性水平。现有接口包括Java、JPA、Memcached、JavaScript with Nodejs以及HTTP/REST(通过一套Apache Module实现)。所有Application Node都能够访问到来自任意Data Node的数据，所以即使出现故障、它们也不会导致任何服务丢失——因为各应用程序能够继续使用其它尚能正常运转的节点。

Management Node的职责在于该集群的配置方案发布到集群内的所有节点当中以实现节点管理。Management Node的起效时间点分别为集群启动时、某个节点希望加入集群时以及系统进行重新配置时。Management Node能够在不影响到当前正在进行的Data及Application Node执行操作的前提下进行中止以及重启。在默认情况下，Management Node同时提供裁定服务，例如某种网络故障引发“裂脑(即split-brain)”或者某信集群开始进行网络划分的情况。

通过透明化划分实现可扩展性

来自任何给定表的行都会以透明化方式被拆分成多个分区/片段。在每个片段中会包含一个单独数据节点，负责保留全部数据内容并处理指向该数据的所有读取及写入操作。每个数据节点还拥有一套搭档体系，二者共同构成一个节点组; 搭档节点中保存有该数据片段的辅助副本，但同时也拥有着自己的主片段。MySQL Cluster利用两步式提交协议实现数据同步，从而确保当某项事务被提交之后、所引发的变更将被同时存储在两个数据节点当中。

在默认情况下，表的主键会被作为分片键使用，而MySQL Cluster将对该分片键执行MD5散列处理、从而选择需要保存哪个片段/分区。如果某一事务或者查询需要访问来自多个数据节点的数据，那么其中一个数据节点会充当事务协调方的角色，并将具体工作分配给其它相关数据节点; 接下来访问结果会得到整合，并最终提供给应用程序。请注意，我们同样可以让多个事务或者查询访问来自多个分区及表的数据——相较于利用分片机制保存数据的典型NoSQL，这无疑成为MySQL Cluster的一大显著比较优势。

要实现最理想的(线性)规模缩放效果，我们需要确保将高强度查询/事务只需运行在单独一套数据节点之上(因为这能够大大降低由数据节点间通信所带来的网络延迟)。为了实现这个目标，我们可以让应用程序获得分布识别能力——具体而言，这意味着由管理员定义的规划能够涵盖分片键所需要使用的任意列。举例来讲，上图所示为一套配备有由用户ID与服务名称组成的复合主键的表; 通过将用户ID选定为分片键，表内与给定用户相关的所有行将始终被容纳在同一片段当中。更为强大的是，如果我们在其它表中使用同样的用户ID列并将其设定为分片键，那么该给定用户在所有表内的全部数据都会被容纳在同一片段之内——换言之，指向该用户的查询/事务都将在单一数据节点内进行处理。