目 录回顾与导读从是什么到怎么工作第一章 NDB 标准三层架构总览1.1 一个集群 三类角色1.2 一张拓扑图读懂三层架构1.3 一次查询的完整旅程第二章 管理节点 ndb_mgmd集群的大脑2.1 管理节点的角色定位2.2 五大核心职能2.3 管理节点的容错设计第三章 数据节点 ndbd核心数据存储层3.1 数据节点的角色定位3.2 内存 磁盘双存储体系3.3 自动分片数据如何打散到多节点3.4 数据冗余主副本与备份副本3.5 冗余如何保证可用性第四章 SQL 节点 mysqld业务接入层4.1 SQL 节点的角色定位4.2 SQL 节点的核心工作4.3 无数据存储能力4.4 多 SQL 节点与连接路由第五章 三种典型部署架构5.1 最低生产部署架构5.2 标准高可用架构5.3 扩容架构第六章 无单点故障的底层原理6.1 第一层节点冗余——数据处处有备份6.2 第二层心跳机制——健康状态实时感知6.3 第三层自动容错切换——故障后业务无感知6.4 网络分区与仲裁机制读者收获与下一步7.1 读完本篇你应该带走什么7.2 下一步建议回顾与导读从是什么到怎么工作第一篇我们建立了 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 节点为例业务应用只与 SQL 节点通信SQL 节点与管理节点、数据节点通信管理节点与所有节点通信。数据节点之间则通过专用的内部网络NDB transport高速互联完成同步复制。整个集群通过标准 TCP/IP 互联也可在节点间使用共享内存或高速互连如 InfiniBand进一步提升性能。1.3 一次查询的完整旅程为了直观理解三层分工这里先给出一次典型读请求的流转过程后续章节会逐一详解各环节步骤 1应用向任意 SQL 节点发起 SELECT 语句。步骤 2SQL 节点解析并优化 SQL根据分区规则定位数据所在的数据节点将请求拆分为针对具体分区的内部操作。步骤 3数据节点执行操作读取内存中的数据主副本或备份副本由引擎自动选择返回结果。步骤 4SQL 节点汇总各分区结果组装成标准结果集返回应用。管理节点在这一过程中不参与数据面只负责看护整个集群的健康状态。这种管控与数据分离的设计正是 NDB 高可用架构的基石。第二章 管理节点 ndb_mgmd集群的大脑2.1 管理节点的角色定位管理节点运行 ndb_mgmdNDB 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 个节点。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 个节点想容忍更多故障需要提高副本数如 NoOfReplicas4或增加节点组数量。第四章 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 最低生产部署架构满足可对外提供生产级服务的最低配置要点至少 2 个数据节点才能构成双副本这是 NDB 高可用的底线——任一数据节点故障另一个仍持有全部数据副本。此架构适合业务初期的起步阶段但管理节点为单点集群生命周期管理存在风险。5.2 标准高可用架构面向生产关键业务的标准配置要点数据节点构成 2×2 布局后任意每个节点组挂 1 台的组合都不会中断服务管理节点双活消除管控面单点SQL 节点多实例配合负载均衡消除接入面单点。这是官方推荐的生产级高可用形态也是本系列后续部署篇章的目标架构。5.3 扩容架构当容量或吞吐逼近上限时NDB 支持在线扩容——无需停机、无需导出导入数据1横向加数据节点向集群在线添加新的数据节点形成新的节点组数据自动重新分布容量与写入吞吐近乎线性增长。2纵向加 SQL 节点随时增加 SQL 节点实例提升接入并发能力配合负载均衡即可。3提高副本数通过调整 NoOfReplicas 提升数据冗余度换取更高的故障容忍能力代价是写入开销增加。扩容架构的关键优势在于在线业务不停、数据不动手搬运集群自动完成数据再平衡。这也是 NDB 相比传统主从方案在扩展性上的根本差异。第六章 无单点故障的底层原理NDB 宣称无单点故障这不是营销话术而是由三层机制从架构层面保证的。这一章把底层逻辑彻底拆开。6.1 第一层节点冗余——数据处处有备份NDB 的可用性根基是多副本 交叉摆放数据按分区打散到各节点组组内每个节点都保存一份片段副本且主副本位置在各分区间轮换避免热点。由此带来的容错能力是数学上可证明的只要每个节点组至少有一个节点存活集群就能提供全部数据的完整访问。副本数越高、节点组越多可容忍的故障数量越多。6.2 第二层心跳机制——健康状态实时感知集群内所有节点数据节点、SQL 节点定期向管理节点发送心跳信号同时数据节点之间也存在心跳检测。一旦某个节点超过阈值未上报心跳即被判定为失联。心跳机制的价值在于及时性故障发现无需等待人工介入而是秒级自动触发为后续的容错切换赢得时间。6.3 第三层自动容错切换——故障后业务无感知当数据节点故障被感知后集群自动完成以下动作故障节点所属节点组内的存活节点立即接管其主副本职责——读请求自动路由到备份副本写入切换到存活节点。涉及该节点的未完成事务被回滚或由其他节点重新执行保证一致性。集群记录故障事件并持续监控故障节点恢复后可通过滚动重启重新加入集群数据自动重新同步补齐。整个过程由引擎自动完成应用层无感知。这正是 NDB 达到 99.999% 可用性目标的机制基础。6.4 网络分区与仲裁机制集群故障还有一个棘手场景网络分区脑裂即节点间网络中断但节点本身都活着。此时节点组内成员互相失联各自都认为自己才是幸存方若双方同时对外提供写入就会产生数据分裂。NDB 通过仲裁Arbitration机制解决脑裂发生分歧时节点组向仲裁者通常由 SQL 节点或管理节点担任请求裁决只有获得仲裁者支持的一方继续提供服务。仲裁者保持中立且不存储数据它的一票用于打破平局确保集群在任何时刻只有一个权威视图。理解无单点故障的正确姿势不是每个组件都有备份这么简单而是冗余 心跳 自动切换 仲裁四者协同构成一个完整的自愈闭环。