MySQL 分布式集群系列 · 第二篇：架构深度拆解--NDB 三大核心节点

回顾与导读：从"是什么"到"怎么工作"

第一篇我们建立了 NDB 的整体认知：它是 MySQL 内置的分布式集群存储引擎，具备高可用、低延迟、多主写入、横向扩容四大能力。但"为什么能做到"才是硬核问题------NDB 究竟由哪些部分组成？每个部分在承担什么职责？数据如何在节点之间流转？故障发生时系统如何自动恢复？

这一篇将深入 NDB 集群的物理与逻辑骨架，拆解三大核心节点的完整工作机制，并讲清楚"无单点故障"到底是如何从架构层面实现的。读完这一篇，你将对 NDB 有一个工程师级别的整体认知，为后续的部署实操与运维调优篇章打下坚实基础。

第一章 NDB 标准三层架构总览

1.1 一个集群 = 三类角色

NDB Cluster 由三种不同类型的节点进程组成，它们分工明确、各司其职，共同对外提供完整的分布式数据库服务：

管理节点（ndb_mgmd）：集群的"大脑"，负责配置管理、节点注册、心跳监控与故障协调。
数据节点（ndbd / ndbmtd）：集群的"躯干"，实际存储数据，承担分片、复制与事务执行。
SQL 节点（mysqld）：集群的"脸面"，面向业务提供标准 MySQL 接口，解析 SQL 并转发给数据节点。

这三类角色可以部署在同一台物理机上（开发环境），但在生产环境中，官方推荐将不同类型节点部署在不同主机上，尤其是数据节点，每个应独占一台服务器。

1.2 一张拓扑图读懂三层架构

一个典型的 NDB 集群拓扑如下（以 2 个管理节点、4 个数据节点、2 个 SQL 节点为例）：

|------------|---------------------|--------------|----------------------|
| 层级 | 节点进程 | 典型数量 | 核心职责 |
| 接入层 | mysqld（SQL 节点） | 2+ 台 | 接收业务 SQL，解析优化，对接数据节点 |
| 管控层 | ndb_mgmd（管理节点） | 1~2 台 | 配置分发、心跳监控、节点调度、故障仲裁 |
| 存储层 | ndbd / ndbmtd（数据节点） | 2~4+ 台 | 数据分片存储、多副本复制、事务执行 |

业务应用只与 SQL 节点通信，SQL 节点与管理节点、数据节点通信，管理节点与所有节点通信。数据节点之间则通过专用的内部网络（NDB transport）高速互联，完成同步复制。整个集群通过标准 TCP/IP 互联，也可在节点间使用共享内存或高速互连（如 InfiniBand）进一步提升性能。

1.3 一次查询的完整旅程

为了直观理解三层分工，这里先给出一次典型读请求的流转过程（后续章节会逐一详解各环节）：

步骤 1：应用向任意 SQL 节点发起 SELECT 语句。
步骤 2：SQL 节点解析并优化 SQL，根据分区规则定位数据所在的数据节点，将请求拆分为针对具体分区的内部操作。
步骤 3：数据节点执行操作，读取内存中的数据（主副本或备份副本，由引擎自动选择），返回结果。
步骤 4：SQL 节点汇总各分区结果，组装成标准结果集返回应用。

管理节点在这一过程中不参与数据面，只负责"看护"整个集群的健康状态。这种"管控与数据分离"的设计，正是 NDB 高可用架构的基石。

第二章管理节点 ndb_mgmd：集群的"大脑"

2.1 管理节点的角色定位

管理节点运行 ndb_mgmd（NDB Management Server Daemon）进程，是集群的控制平面。它不存储任何业务数据，也不参与 SQL 处理，但所有节点在启动时都必须先向管理节点注册，并从管理节点获取集群配置。

可以这样理解：数据节点和 SQL 节点是"干活的人"，管理节点是"HR + 监工 + 调度台"------负责登记谁加入了集群、谁还活着、配置是什么、出了问题怎么协调。

2.2 五大核心职能

集群统一管控：维护集群成员列表，新节点启动时完成注册与身份确认，节点状态变化实时同步给集群内其他成员。
配置同步：保存并分发全局配置文件（config.ini）。所有节点启动时从管理节点拉取配置，确保整个集群使用一致的参数体系，避免因配置漂移导致的运行异常。
心跳检测：持续接收各数据节点、SQL 节点上报的心跳信号，实时掌握每个节点的存活状态。
故障监控：检测到节点失联或异常时，立即触发集群级事件（如日志告警、故障转移协调），并在必要时启动仲裁流程。
节点调度：在集群启动、节点加入/退出、在线扩容等场景下，协调各节点的初始化顺序与状态迁移。

2.3 管理节点的容错设计

管理节点本身也是集群的一部分，同样遵循"无单点故障"原则。生产环境中通常部署两个管理节点形成冗余：一个作为主管理节点，另一个作为热备。主管理节点故障时，备用管理节点自动接管管控职责。

需要澄清一个常见误区：管理节点短暂不可用，并不会导致正在运行的数据节点和 SQL 节点立即停摆。已注册的节点仍可继续提供数据服务；但集群重启、新节点加入、配置变更等"依赖管理面"的操作会暂时无法进行。因此，双管理节点冗余的意义在于保证集群生命周期管理能力不中断。

第三章数据节点 ndbd：核心数据存储层

3.1 数据节点的角色定位

数据节点运行 ndbd（单线程守护进程）或 ndbmtd（多线程守护进程），是 NDB 集群真正存放数据的地方。所有业务数据的存储、读取、复制、事务执行都在数据节点上完成。官方强烈建议每个数据节点部署在独立的物理服务器上。

数据节点是 NDB 的"核心资产"------它们的数量决定了集群的容量上限与写入吞吐；它们的健康状态直接决定了集群能否对外服务。

3.2 内存 + 磁盘双存储体系

内存存储（主存储）：NDB 是内存优先引擎，表数据主要驻留在数据节点内存中，读写路径不经过磁盘，从而获得极低延迟。每个数据节点的内存容量直接决定其能承载的数据量。
磁盘存储（补充层）：NDB 支持磁盘数据表（Disk Data Tables），将一部分不常访问或体量较大的数据落到磁盘，作为内存容量的延伸。重做日志（Redo Log）、备份文件等也落盘保存，保证内存数据可恢复。

理解双存储的关键：内存提供速度，磁盘提供容量与持久性兜底。两者结合，使 NDB 在"低延迟"与"数据规模"之间获得平衡。

3.3 自动分片：数据如何打散到多节点

NDB 表创建后，数据会按分区键自动切分成多个分区（Partition）。分区数量由数据节点数与 LDM 线程数决定：分区数 = 数据节点数 × LDM 线程数。

每个分区会被分配到一个"节点组"（Node Group）上。节点组是 NDB 高可用的基本单元，其数量 = 数据节点数 ÷ 副本数（NoOfReplicas）。例如：4 个数据节点、副本数为 2，则形成 2 个节点组，每组 2 个节点。

|-----------------------|--------------------|------------------|
| 概念 | 官方定义 | 通俗理解 |
| 分区 Partition | 集群存储数据的一部分，按分区键切分 | 把一张大表切成若干"数据块" |
| 片段副本 Fragment Replica | 分区的副本，节点组内每个节点各存一份 | 每个"数据块"在每个组员各存一份 |
| 节点组 Node Group | 存放一组分区副本的节点集合 | 一个"互为备份的小分队" |

3.4 数据冗余：主副本与备份副本

以 4 数据节点（节点组 0 含节点 1、2；节点组 1 含节点 3、4）、副本数 2 的经典 2×2 布局为例：

分区 0 存放在节点组 0：主副本在节点 1，备份副本在节点 2。
分区 1 存放在节点组 1：主副本在节点 3，备份副本在节点 4。
分区 2 存放在节点组 0，但主备互换：主副本在节点 2，备份副本在节点 1。
分区 3 存放在节点组 1，同样主备互换：主副本在节点 4，备份副本在节点 3。

这种"主备交叉"的摆放策略非常关键：它让负载均匀分布在各节点上，任何一个数据节点都不会成为所有分区的主副本所在地，从而避免热点。

3.5 冗余如何保证可用性

官方文档给出了一个极简而有力的结论：只要每个节点组至少有一个节点存活，集群就拥有全部数据的完整副本，可以继续对外服务。

以上面的 2×2 集群为例：节点组 0 挂了 1 个、节点组 1 挂了 1 个，集群依然完整可用；但如果某个节点组内的两个节点同时故障，该组负责的分区就彻底丢失，集群将无法再提供完整数据访问。

因此，副本数 2 的集群最多容忍"每个节点组各挂 1 个节点"；想容忍更多故障，需要提高副本数（如 NoOfReplicas=4）或增加节点组数量。

第四章 SQL 节点 mysqld：业务接入层

4.1 SQL 节点的角色定位

SQL 节点运行标准 mysqld 进程，是业务应用访问集群的唯一入口。它对外提供完全标准的 MySQL 协议与 SQL 语法------应用连接 SQL 节点，就像连接一台普通 MySQL 服务器一样，无需任何特殊驱动或中间件。

4.2 SQL 节点的核心工作

承接 SQL 请求：监听标准 MySQL 端口（默认 3306），接收应用的连接与查询。
SQL 解析与优化：执行词法/语法解析、语义分析、查询优化，生成执行计划。
请求分发：根据分区规则，将针对某分区的操作路由到对应的数据节点，并行下发。
结果汇总：收集各数据节点返回的分区结果，组装成完整结果集，返回给应用。
事务协调：作为事务的发起方与协调者，向数据节点提交事务操作，并汇总提交结果。

4.3 无数据存储能力

这是理解 NDB 架构的关键一点：SQL 节点自身不存储任何 NDB 表数据，它是纯粹的计算与转发层。这意味着：

SQL 节点宕机不影响数据安全------数据全部在数据节点上。
SQL 节点可以随时增删------集群中可部署多个 SQL 节点，业务连接任一节点即可，天然支持负载均衡与水平扩展。
SQL 节点之间无状态（对 NDB 数据而言），可以理解为"集群的只读门面"（对数据面而言）。

4.4 多 SQL 节点与连接路由

生产环境通常部署多个 SQL 节点：业务层通过负载均衡器（如 MySQL Router、HAProxy 或应用层连接池）把请求分散到各 SQL 节点，任何一个 SQL 节点故障，流量自动转移到其他节点，业务无感知。

此外，NDB 集群还支持 NoSQL 风格的直接访问方式------应用可通过 NDB API / ClusterJ 等原生接口绕过 SQL 节点直连数据节点，获得更低的访问延迟（本系列后续篇章会展开）。

第五章三种典型部署架构

根据业务规模与可用性要求，NDB 集群存在三种典型的部署形态。理解它们的差异，有助于在真实场景中做出正确的容量规划。

5.1 最低生产部署架构

满足"可对外提供生产级服务"的最低配置：

|---------------|------------|----------------------|
| 节点类型 | 数量 | 说明 |
| 管理节点 ndb_mgmd | 1 台 | 承担集群管控 |
| 数据节点 ndbd | 2 台 | 形成 1 个节点组，副本数 2，互为备份 |
| SQL 节点 mysqld | 1~2 台 | 业务接入 |

要点：至少 2 个数据节点才能构成"双副本"，这是 NDB 高可用的底线------任一数据节点故障，另一个仍持有全部数据副本。此架构适合业务初期的起步阶段，但管理节点为单点，集群生命周期管理存在风险。

5.2 标准高可用架构

面向生产关键业务的标准配置：

|---------------|------------|--------------------------|
| 节点类型 | 数量 | 说明 |
| 管理节点 ndb_mgmd | 2 台 | 主备冗余，管控面无单点 |
| 数据节点 ndbd | 4 台 | 2 个节点组 × 每组 2 节点，双副本交叉存放 |
| SQL 节点 mysqld | 2+ 台 | 配合负载均衡，接入面无单点 |

要点：数据节点构成 2×2 布局后，任意"每个节点组挂 1 台"的组合都不会中断服务；管理节点双活消除管控面单点；SQL 节点多实例配合负载均衡消除接入面单点。这是官方推荐的生产级高可用形态，也是本系列后续部署篇章的目标架构。

5.3 扩容架构

当容量或吞吐逼近上限时，NDB 支持在线扩容------无需停机、无需导出导入数据：

横向加数据节点：向集群在线添加新的数据节点（形成新的节点组），数据自动重新分布，容量与写入吞吐近乎线性增长。
纵向加 SQL 节点：随时增加 SQL 节点实例，提升接入并发能力，配合负载均衡即可。
提高副本数：通过调整 NoOfReplicas 提升数据冗余度，换取更高的故障容忍能力（代价是写入开销增加）。

扩容架构的关键优势在于"在线"：业务不停、数据不动手搬运，集群自动完成数据再平衡。这也是 NDB 相比传统主从方案在扩展性上的根本差异。

|--------------|------------------------|----------------|
| 架构形态 | 关键配置 | 适用阶段 |
| 最低生产部署 | 1 管理 + 2 数据 + 1~2 SQL | 业务起步、POC 验证 |
| 标准高可用 | 2 管理 + 4 数据 + 2+ SQL | 生产关键业务、多活诉求 |
| 扩容架构 | 在标准架构上在线加节点 | 业务增长、容量/吞吐逼近上限 |

第六章无单点故障的底层原理

NDB 宣称"无单点故障"，这不是营销话术，而是由三层机制从架构层面保证的。这一章把底层逻辑彻底拆开。

6.1 第一层：节点冗余------数据处处有备份

NDB 的可用性根基是"多副本 + 交叉摆放"：数据按分区打散到各节点组，组内每个节点都保存一份片段副本，且主副本位置在各分区间轮换，避免热点。

由此带来的容错能力是数学上可证明的：只要每个节点组至少有一个节点存活，集群就能提供全部数据的完整访问。副本数越高、节点组越多，可容忍的故障数量越多。

6.2 第二层：心跳机制------健康状态实时感知

集群内所有节点（数据节点、SQL 节点）定期向管理节点发送心跳信号，同时数据节点之间也存在心跳检测。一旦某个节点超过阈值未上报心跳，即被判定为失联。

心跳机制的价值在于"及时性"：故障发现无需等待人工介入，而是秒级自动触发，为后续的容错切换赢得时间。

6.3 第三层：自动容错切换------故障后业务无感知

当数据节点故障被感知后，集群自动完成以下动作：

故障节点所属节点组内的存活节点，立即接管其主副本职责------读请求自动路由到备份副本，写入切换到存活节点。
涉及该节点的未完成事务被回滚或由其他节点重新执行，保证一致性。
集群记录故障事件并持续监控，故障节点恢复后可通过滚动重启重新加入集群，数据自动重新同步补齐。

整个过程由引擎自动完成，应用层无感知。这正是 NDB 达到 99.999% 可用性目标的机制基础。

6.4 网络分区与仲裁机制

集群故障还有一个棘手场景：网络分区（脑裂），即节点间网络中断但节点本身都活着。此时节点组内成员互相"失联"，各自都认为自己才是幸存方，若双方同时对外提供写入，就会产生数据分裂。

NDB 通过仲裁（Arbitration）机制解决脑裂：发生分歧时，节点组向仲裁者（通常由 SQL 节点或管理节点担任）请求裁决，只有获得仲裁者支持的一方继续提供服务。
仲裁者保持中立且不存储数据，它的"一票"用于打破平局，确保集群在任何时刻只有一个"权威视图"。

理解无单点故障的正确姿势：不是"每个组件都有备份"这么简单，而是"冗余 + 心跳 + 自动切换 + 仲裁"四者协同，构成一个完整的自愈闭环。

|------------|-------------|------------------|
| 机制 | 作用 | 失败场景下的表现 |
| 节点冗余 | 数据多副本交叉存放 | 单节点故障，副本立即接管 |
| 心跳检测 | 秒级感知节点失联 | 故障被快速发现并触发切换 |
| 自动容错切换 | 主副本职责自动迁移 | 读写在存活节点间重新路由 |
| 仲裁机制 | 网络分区时裁定权威视图 | 避免脑裂导致数据分裂 |