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 节点都有资格成为仲裁器。