概述

本章，您将学习到有关 MySQL NDB Cluster 启动方面的内容。

启动

由前面的文章可知，若要将 MySQL NDB Cluster 启动，您需要按照顺序依次启动各个节点：

• 首先启动管理节点（在 192.168.100.10 上 执行 ndb_mgmd --configdir=/etc/mysql-cluster/ -f /etc/mysql-cluster/config.ini 命令）
• 然后启动数据节点（在 192.168.100.12 和 192.168.100.14 上分别执行 ndbd 命令）
• 最后启动 SQL 节点（在 192.168.100.16 上执行 /usr/local/mysql/support-files/mysql.server start 命令）

停止

要停止整个 MySQL NDB Cluster，您需要按照顺序依次关闭各个节点：

• 首先停止 SQL 节点（在 192.168.100.16 上执行 /usr/local/mysql/support-files/mysql.server stop 命令）
• 关闭所有的管理节点和数据节点（在任意一个管理节点上执行 ndb_mgm -e shutdown 命令，这会关闭所有的管理节点和数据节点）

滚动重启

Q：什么是滚动重启？

在生产环境下通常不允许完全关闭集群环境，即使是在对配置进行更改或对集群硬件/软件升级的情况下，在 Mysql NDB Cluster 中，引入了 「滚动重启」（Rolling Restart） 的概念。之所以被称为 「滚动重启」，是因为涉及到轮流停止和启动（或重启）每个节点，以使集群环境本身保持正常的运行（集群环境本身的高可用是强制性的，不允许整个集群环境完全停止）。

要使用滚动重启的原因有很多，例如：

• 配置文件内容更改。比如在已有的集群环境中添加新的 SQL 节点，这涉及到管理节点全局配置文件的内容变更，也涉及到新 SQL 节点的配置。
• NDB Cluster 软件的升级或降级。这通常被称为滚动升级（rolling upgrade）与滚动降级（rolling downgrade）。
• 集群主机的硬件变更。
• 集群重置。因集群环境目前的状态不符合实际需要，所以需要重置，在这种情况下通常需要重新加载一个或多个数据节点的数据和元数据。
• 资源恢复。释放先前通过连续的 insert 和 delete 操作分配给表的内存，以供给其他 NDB Cluster 表重新使用。

滚动重启的步骤如下：

1. 停止所有管理节点的 ndb_mgmd 进程，这可以通过 kill 或 killall 命令来实现

2. 更新所有管理节点的全局配置文件 config.ini。一个管理节点就需要一个对应的 config.ini 文件。若集群环境中存在多个管理节点，则全局配置文件 config.ini 的内容需要一样

3. 依次在对应的管理节点上执行 ndb_mgmd 命令的 --reload 或者 --initial 选项。--initial 选项会强制管理节点删除任何现有的缓存文件，并从 config.ini 文件中重新读取配置构建一个新的缓存，当 config.ini 文件与缓存的内容不一致时，使用 --reload 选项。需要注意：

   • 若您在首个管理节点上使用 --initial 选项启动了 ndb_mgmd 进程，则剩余的其他管理节点也必须使用 --initial 选项启动 ndb_mgmd 进程
   • 若您在首个管理节点上使用了任何其他的选项启动了 ndb_mgmd 进程，则剩余的其他管理节点都不应该使用 --reload 选项启动 ndb_mgmd 进程

4. 完成集群环境中每个数据节点的滚动重启，单个数据节点的步骤如下：

   • 停止 ndbd 进程（通过 kill 或 killall 命令来实现）
   • 重新配置 /etc/my.cnf 文件
   • 使用 ndbd 命令（注意！该命令不需要 --initial 选项）启动 ndbd 进程

   在执行滚动重启的过程中，您可以通过 ndbinfo.nodes 表的列来追踪哪些数据节点已经使用新配置且成功启动，该表包含以下列：

   • node_id - 数据节点在集群环境中的唯一 ID
   • uptime - 数据节点成功启动以来的时间（以秒为单位）
   • status - 数据节点的状态
   • start_phase - 启动的阶段，会用不同的数字进行表示。下文中会说明
   • config_generation - 此数据节点使用集群配置的版本

5. 完成集群环境中每个 SQL 节点的滚动重启，单个 SQL 节点的步骤如下：

   • 停止 mysqld 进程（通过 kill 或 killall 命令来实现）
   • 重新配置 /etc/my.cnf 文件
   • 使用 mysql.server start 命令启动 mysqld 进程

启动阶段

在说明启动阶段之前，先了解下启动类型，有这么几种：

• 初始化启动（Initial start） - 这通常出现在一个全新安装的集群环境中，所有的数据节点都有一个干净的文件系统
• 系统重启（System restart） - 集群启动并读取存储在数据节点的数据。这种情况发生在集群在使用一段时间后被关闭，以及当需要让集群从上次停止的位置继续运行时出现
• 节点重启（Node restart） - 当集群正在运行时，对集群中的节点进行在线重启
• 初始化节点且重启（Initial node restart） - 与节点重启相同，不同之处在于节点会被重新初始化并使用一个干净的文件系统启动

下面说明启动的各个阶段（不同的数字即 ndbinfo.nodes 表的 start_phase 列数据）：

• 阶段 -1 - 这一阶段主要对整个集群进行设置与初始化。在整个集群正常运行之前，每个数据节点（ndbd 进程）必须进行初始化，初始化的步骤包括：

  • 获取节点 ID
  • 获取配置数据
  • 分配用于节点间的通信端口
  • 根据配置文件中获得的设置分配内存

  当数据节点或 SQL 节点首次连接到管理节点时，它（数据节点或 SQL 节点）会保留一个集群的节点 ID。为了确保没有其他节点分配相同的节点 ID，该 ID 将一直被保留，直到该节点成功连接到了集群。

• 阶段 0 - NDBFS 块和 NDBCNTR 块启动。若要清除对应数据节点上的文件系统，请在对应的数据节点使用 ndbd 命令的 --initial 选项。

• 阶段 1 - 在该阶段，所有剩余的 NDB 内核块启动。NDB 集群的连接被建立，块之间的通信得以实现，启动心跳机制。若节点重启，还会检查 API 节点连接。

• 阶段 2 - NDBCNTR 内核块会检查所有节点的状态。在此阶段，还会选出数据节点中的主节点，并初始化集群的模式文件（schema file）

• 阶段 3 - DBLQH 和 DBTC 内核块之间建立了通信连接。确定启动类型；如果是重新启动，则 DBDIH 块会获取执行重新启动的权限。

• 阶段 4 - 对于节点重启以及初始化节点且重启这两种启动类型，将创建 Redo Log 日志文件。这些文件的数量等于 config.ini 的配置项 NoOfFragmentLogFiles

• 阶段 5 - 数据节点启动过程中与与数据库相关的大部分操作都在此阶段完成。对于初始化启动或系统重启而言，都会先执行本地检查点，随后执行全局检查点。在此阶段，系统将开始定期检查内存使用情况，并执行任何必要的节点接管操作。

• 阶段 6 - 在此阶段，定义和设置节点组。节点组是相对于数据节点来说的。

• 阶段 7 - 仲裁者节点被选择且开始运行。设置下一个备份 ID 以及备份磁盘的写入速度。进入此阶段的节点会被标记为 "Started"。此时 SQL 节点可以连接到集群。

• 阶段 8 - 若是系统重启这种启动类型，则由 DBDIH 重建所有索引。

• 阶段 9 - 重置节点内部与启动相关的系统变量。

• 阶段 100 - 已过时。

• 阶段 101 - 对于节点重启和初始化节点且重启而言，事件交付职责将移交至加入集群的新节点。该新节点将接管向订阅者分发其主数据的责任。此阶段亦称为 SUMA 交接阶段。

Q：什么是仲裁者节点（Arbitrator Node）？

「脑裂」（split-brain）的概念：在集群中，因网络分区或通信中断或其他原因，导致原本统一的集群被分割为两个或多个相互无法通信的子集，每个子集独立选举出自己的主节点（Leader/Master），并继续对外提供服务。此时，系统中出现多个 「决策中心」，如同大脑分裂，引发数据写入冲突、状态不一致、服务混乱等严重问题。

在 MySQL NDB Cluster 中，若集群中的一个或多个数据节点失效或故障，可能并非所有数据节点都能 "看到" 彼此。事实上，在「脑裂」场景中，两组数据节点可能会彼此隔离，这种情况是不希望看到的，因为每组数据节点都会试图表现得仿佛自己是整个集群。此时就需要一名仲裁者来裁决这两组相互竞争的数据节点。

当至少一个节点组中的所有数据节点均处于活动可用状态时，则不会发生「脑裂」，因为集群中的任何单一子集都无法单独形成一个可运行的集群。但是，若没有任何一个节点组中的所有数据节点均处于活动可用状态时，可能会发生「脑裂」，此时就需要引入一名仲裁者。通常而言，由一个管理服务器（管理节点）来充当仲裁者节点，但也允许集群中任意一个 MySQL 服务器（SQL 节点）充当仲裁者节点，但‌不推荐在生产环境中使用‌。

• 0 - 该节点不参与决策
• 1（默认值） - 节点优先级高
• 2 - 节点优先级低，只有当节点优先级高的节点不可用时，节点优先级低的节点才会充当仲裁者节点

赞赏