如果集群中的一个或者多个节点出现故障，则可能并非所有集群节点都无法“看到”彼此。
事实上，在网络分区中，两组节点可能会彼此隔离，也称为“裂脑”场景。
这种情况是不可取的，因为每组节点都试图表现得好像它是整个集群一样。

当集群节点宕机时，有两种可能。
如果剩余的 50% 以上的节点可以相互通信，那么我们就有了有时称为“多数规则”的情况，这组节点被认为是集群。
当节点数为偶数时仲裁器开始发挥作用：在这种情况下，仲裁器所属的节点集被认为是集群，不属于该集的节点将被关闭。

以上信息有些简化，考虑到节点组的更完整解释如下：

当至少一个节点组中的所有节点都处于活动状态时，网络分区不是问题，因为集群的任何部分都不能形成功能集群。
当没有一个节点组的所有节点都处于活动状态时，就会出现真正的问题，在这种情况下，网络分区（“裂脑”场景）成为可能。
然后需要一个仲裁员。
所有集群节点都识别与仲裁器相同的节点，通常是管理服务器；但是，可以将集群中的任何 MySQL 服务器配置为充当仲裁者。
仲裁器接受第一组集群节点与它联系，并告诉其余的组关闭。
仲裁器选择由 MySQL 服务器和管理服务器节点的 ArbitrationRank 配置参数控制。
（详情见页边的外部资源链接。
）还需要注意的是，仲裁员的角色本身并没有对指定的主机提出任何苛刻的要求，因此仲裁主机不需要特别快或者有另外的内存，特别是为此目的。

仲裁员(Arbitrator)在失败情况下扮演什么角色？

只要有可能出现网络分区情况，就需要仲裁员。
它用于决定允许哪些幸存的数据节点设置继续运行。
任何未经仲裁员批准的数据节点都将关闭，以防止发生“裂脑”。

仲裁器可以是 SQL 节点或者管理服务器节点，管理节点是更常见的选择。
任何时候都只能有一名仲裁员处于活动状态。
如果仲裁员本身失败，则集群将自动选举新的仲裁员。
然而，这个新的选举不能在另一个节点故障期间发生，而是在节点故障解决后发生。

我们可以通过 config.ini 文件中的设置来影响仲裁员的选择。
[mysqld] 和 [mgm] 组都可以使用 ArbitrationRank 设置，这将更改仲裁员选择的排名。
该设置可以是三个可能的值之一：

• 0 : 该节点永远不会被用作仲裁者。
• 1：节点优先级高；也就是说，它比低优先级节点更适合作为仲裁员。
• 2 ：表示低优先级节点，仅当具有更高优先级的节点不可用时才用作仲裁器。

示例配置文件如下：

[MGM]
ArbitrationRank = 1
[NDBD DEFAULT]
NoOfReplicas = 2
Datadir = /var/lib/mysql-cluster
[NDBD]
Hostname = ndbd_host1
[NDBD]
Hostname = ndbd_host2
[MYSQLD]
Hostname = mysqld_host1
ArbitrationRank = 2
[MYSQLD]
Hostname = mysqld_host2
ArbitrationRank = 1

在上述情况下，mysqld_host2 上的 mysqld 服务器或者 MGMD 节点将是最高优先级，因此是普通仲裁员。
如果它们都失败，则将选择主机 mysqld_host1 上的第一个 mysqld。
在大多数正常情况下，如果可能，我们会希望仲裁器是一个独立于数据节点的系统。
这将有助于防止数据节点和仲裁器同时失败的可能性。