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
用于跟踪仲裁的内部标识符
arb_state
仲裁状态
arb_connected
此节点是否连接到仲裁器;
是
或否
connected_rank1_arbs
已连接的等级 1 仲裁器
connected_rank2_arbs
已连接的等级 1 仲裁器
注意
节点 ID 和节点组 ID 与 ndb_mgm -e "SHOW" 报告的相同。
left_node
和 right_node
是根据将所有数据节点按其节点 ID 顺序连接成圆形的模型定义的,类似于时钟表盘上的数字顺序,如下所示
在此示例中,我们有 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)
事件日志中以相同的方式使用 “左” 和 “右” 的含义。
president
节点是当前节点视为负责设置仲裁器的节点(请参阅 NDB 集群启动阶段)。如果总裁节点发生故障或断开连接,则当前节点希望其 ID 显示在 successor
列中的节点成为新的总裁节点。succession_order
列显示当前节点认为自己在继任队列中的位置。
在正常的 NDB 集群中,所有数据节点应将同一个节点视为 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 节点都有资格成为仲裁器。