mysql cluster 的分组问题

首先是关于mysql cluster中三种节点角色名词解释：

管理(MGM)节点：这类节点的作用是管理MySQL簇内的其他节点，如提供配置数据、启动并停止节点、运行备份等。由于这类节点负责管理其他节点的配置，应在启动其他节点之前首先启动这类节点，MGM节点是用命令ndb_mgmd启动的。

数据节点：这类节点用于保存簇的数据。数据节点的数目与副本的数目相关，是片段的倍数。例如，对于两个副本，每个副本有两个片段，那么就有4个数据节点。没有必要有一个以上的副本。数据节点是用命令ndbd启动的。

SQL节点：这是用来访问簇数据的节点。对于MySQL簇，客户端节点是使用NDB簇存储引擎的传统MySQL服务器。典型情况下，SQL节点是使用命令mysqld –ndbcluster启动的，或将ndbcluster添加到my.cnf后使用mysqld启动。

开始对于 “数据节点的数目与副本的数目相关，是片段的倍数”这句不太理解，后来经过试验慢慢清楚了。

首先是整个cluster架构中节点的数目（这说的节点都是data节点），我的节点数目开始刚好是四个：175，179，180,181。

管理节点的文件config.ini文件里设置的副本数据是：2。（NoOfReplicas=2）

节点的数目和副本的数据 决定了nodegroup 的数目和每个nodegroup 里data节点的数目。
当我的节点都启动的时候，自动会分成两组：nodegroup
0 和nodegroup 1。

（group的数目=节点数目/副本数），至于两个节点分在同一个组、分在nodegroup 0 里，完全取决于“节点启动”顺序，就是ndbd --initial在各个节点执行的顺序。最开始启动的两个节点分到第一个nodegroup，也就是nodegroup 0 里。



如下图：

（下面的sql节点可以不用管。）



此时，节点数目为4，副本数目为2，片段数目为2。同一份数据，分两半保存，称为片段。

在nodegroup 0 里是一半，175和180数据一样；在nodegroup 1 里也保存另一半，181和179的数据一样。

但是在nodegroup 0 里保存的片段和nodegroup 1 里保存的片段不一样。

就好比一个表数据分段，一个nodegroup 0的节点+一个nodegroup 1的节点，合起来刚好是一份完整的数据。

还有一个点：关于预留的节点的处理：

在config.ini文件里可以添加 nodegroup

预留节点分组，以便在添加额外节点的时候，不用重启其他节点，使当前新启动的节点自动分组。

设置方式如下：

186和185，是预留的ip，分配给以后需要用到的data节点的，写写到这里，并将nodegroup值设置为最大：65536。



当安装了节点185和186之后，启动它们，在管理节点可以看到它们，

如下图：

已经自动分配到no nodegroup 中了。



<补充节点node id>

在管理节点的config.ini文件里可以指定每个节点的id，知道每个节点的ID，方便直接根据ID编号，对相应的节点进行管理操作。

不配置节点的时候，根据节点开启的顺序，节点id编号自动递增生成。



处于多种考虑，如果需要对每个节点指定node id编号，直接编辑管理节点的config.ini文件。

配置方式很简单，只需要在相应的[ndbd] 或者[mysqld]的标签下加上“Id=n” 即可。合理的id号范围是1~255，为了方便记忆，是可以将节点ip的第四位做node ID。

如下图：



我的规律是：管理节点为1；data节点都是1n，sql节点都是2n（n=1,2,3,4，……）。

修改文件之后，保存。在管理节点重启所有。

重启所有节点过程中：



等所有节点再次完成连接后：



每个节点id都编程指定的数字了。

这样做一方面是方便记忆每个机器对应的节点id，另一方面是：如果没有在配置文件里指定节点的ID，那么如果再次重启这些节点的时候，如果顺序与之前不一致，那么它们会重新生成一系列id相关的文件。

如下图：



我的第二个sql节点，最开始没有指定ID，启动的时候，按照顺序，id=7，修改文件congfig.ini强制指定id=15之后，又生成了一些文件。

主要差别就在这两个地方了。

不过这样正常情况下是不会影响使用的。实际应用环境中各项配置是需要预先规划好的，一旦节点启动，也不会再轻易修改文件重启了。