ndbinfo成员表
该membership
表描述了每个数据节点在集群中其他所有节点中所具有的视图,包括节点组成员身份,主席节点,仲裁者,仲裁者后继者,仲裁者连接状态以及其他信息。
下表提供有关表中各列的信息membership
。该表为每一列显示名称,数据类型和简要说明。可以在表格后面的注释中找到其他信息。
成员资格表的列
栏名 | 类型 | 描述 |
---|---|---|
node_id | 整数 | 该节点的节点ID |
group_id | 整数 | 该节点所属的节点组 |
left node | 整数 | 前一个节点的节点ID |
right_node | 整数 | 下一个节点的节点ID |
president | 整数 | 总裁的节点ID |
successor | 整数 | 总裁的后继节点ID |
succession_order | 整数 | 该节点成功担任主席的顺序 |
Conf_HB_order | 整数 | -- |
arbitrator | 整数 | 仲裁者的节点ID |
arb_ticket | string | 内部标识符,用于跟踪仲裁 |
arb_state | 枚举(见文字) | 仲裁状态 |
arb_connected | Yes 要么No | 此节点是否连接到仲裁器 |
connected_rank1_arbs | 节点ID列表 | 等级1的关连仲裁员 |
connected_rank2_arbs | 节点ID列表 | 等级1的关连仲裁员 |
节点ID和节点组ID与ndb_mgm -e“ SHOW”报告的相同。
left_node
并right_node
根据将所有数据节点按其节点ID的顺序连接成一个圆圈的模型进行定义,类似于钟盘上的数字顺序,如下所示:
NDB群集节点的循环排列

在此示例中,我们有8个数据节点,分别编号为5、6、7、8、12、13、14和15,按顺时针方向排列成一个圆圈。我们从圆的内部确定“左”和“右”。节点5左侧的节点是节点15,节点5右侧的节点是节点6。您可以通过运行以下查询并观察输出来参见所有这些关系:
mysql>SELECT node_id,left_node,right_node ->FROM ndbinfo.membership; +--------- +----------- +------------ + | node_id | left_node | right_node | +--------- +----------- +------------ + | 5 | 15 | 6 | | 6 | 5 | 7 | | 7 | 6 | 8 | | 8 | 7 | 12 | | 12 | 8 | 13 | | 13 | 12 | 14 | | 14 | 13 | 15 | | 15 | 14 | 5 | +--------- +----------- +------------ + 8 rows in set (0.00 sec)
在事件日志中以相同的方式使用名称“ left ”和“ right ”。
该president
节点是当前节点视为负责设置仲裁程序的节点(请参见 NDB群集启动阶段)。如果总裁失败或断开连接,则当前节点希望其ID在successor
列中显示的节点成为新总裁。该succession_order
列显示了当前节点认为自己具有的在继承队列中的位置。
在普通的NDB群集中,所有数据节点都应与其看到相同的节点president
,并看到相同的节点(除President之外)successor
。此外,现任总裁应将自己视为1
连续的顺序,successor
节点应将自己视为2
,依此类推。
所有节点应显示相同的arb_ticket
值以及相同的arb_state
值。可能的arb_state
值是ARBIT_NULL
,ARBIT_INIT
,ARBIT_FIND
,ARBIT_PREP1
,ARBIT_PREP2
,ARBIT_START
,ARBIT_RUN
,ARBIT_CHOOSE
,ARBIT_CRASH
,和UNKNOWN
。
arb_connected
显示此节点是否连接到显示为该节点的的节点arbitrator
。
的connected_rank1_arbs
和connected_rank2_arbs
列,每列显示具有一个0以上仲裁列表ArbitrationRank
分别等于1,或至2,。
管理节点和API节点都有资格成为仲裁者。