MySQL NDB 集群常见问题解答

A: MySQL NDB 集群建立在 NDB 存储引擎之上，提供了一个高度可扩展、实时、符合 ACID 规范的事务型数据库，将 99.999% 的可用性与开源的低 TCO 相结合。MySQL NDB 集群围绕分布式、多主架构设计，没有单点故障，可在商品硬件上横向扩展，以服务读写密集型工作负载，可以通过 SQL 和 NoSQL 接口访问。

MySQL NDB 集群的实时设计提供可预测的毫秒级响应时间，并能够每秒处理数百万次操作。对内存和磁盘数据的支持、带有负载均衡的自动数据分区（分片）以及在运行的集群中添加节点而无需停机，使得数据库能够线性扩展，以处理最不可预测的基于 Web 的工作负载。

A: MySQL NDB 集群运营商级版 (CGE) 包含用于管理、监控、安全性和审计 MySQL NDB 集群数据库的工具，以及对 Oracle Premier Support 的访问权限。MySQL NDB 集群运营商级版可通过订阅或商业许可和支持获得。

• 了解更多关于 MySQL NDB 集群运营商级版

A: 请参阅 https://www.mysqlserver.cn/customers/cluster/.

A: 当前 GA 版本为 MySQL NDB 集群 8.0。MySQL 8.0 与 MySQL NDB 集群集成并捆绑在一起。

A: 不需要。MySQL NDB 集群旨在运行在商品硬件上。使用专门的硬件，例如 Infiniband 网络互连，可以实现更高的性能水平，尤其是在具有许多节点的大型集群中。

A: 如果你对以下任何问题回答“是”，那么你应该考虑将 MySQL NDB 集群作为应用程序数据库的选项。

• 你需要对数据库进行分片以满足不断增长的写操作（UPDATE、INSERT、DELETE）量吗？
• 你需要确保从 SELECT 操作返回的结果一致，无论它们是从哪个节点返回的？
• 数据库故障会导致应用程序停机，从而造成业务中断，包括收入损失、信誉损失等吗？
• 在故障转移期间数据丢失（即使只是几秒钟）会导致业务中断吗？
• 用户的体验对响应时间敏感吗？
• 你需要将数据库复制到不同的地理区域，每个区域都提供读写操作？
• 你是否运行各种应用程序，这些应用程序可以从直接访问数据中获益，而不总是依赖于 SQL（例如使用 node.js 的 JavaScript、memcached API、Java 和 JPA 应用程序、HTTP/REST Web 服务和 C++ 应用程序）？
• 你的应用程序主要由并行执行的“短”事务（例如每个事务 10 次操作而不是 1000 次）组成吗？
• 你的应用程序主要由以下操作组成吗？
  • 主键数据库访问，以及一些 JOIN 操作
  • 与
  • 定期执行完整表扫描和 JOIN 操作，返回数万行？

A: 理想的应用程序包括：

• 高容量 OLTP
• 实时分析
• 具有欺诈检测功能的电子商务和金融交易
• 移动和微支付
• 会话管理和缓存
• 馈送流、分析和推荐
• 内容管理和交付
• 大型多人在线游戏
• 通信和存在服务
• 用户配置文件管理和授权

查看完整的 MySQL NDB 集群用户案例研究和应用程序列表.

A: 是的。MySQL NDB 集群已在 Oracle VM 上经过测试和认证。

A

• 可用性
  • 99.999%（每年不到 5 分钟的停机时间）
• 性能
  • 响应时间：低于 5 毫秒（使用同步复制和通过 SQL 访问）。使用 NoSQL 访问方法之一可以实现更快的响应时间。
  • 吞吐量：在一台配备 64GB RAM 的双路 Intel 服务器上，每秒 600,000 次以上复制的 UPDATE 操作。在一个包含 30 台 Intel 服务器的集群中，每分钟 10 亿次 UPDATE 操作。
• 故障转移
  • 亚秒级故障转移使你能够不间断地提供服务
• 可扩展性
  • 横向扩展、纵向扩展和动态扩展
  • 为了实现经济高效的横向扩展
    • 每个集群添加更多应用程序和数据节点，或者
    • 每个数据节点添加更多 CPU 线程（16、32、64 等），或者
    • 每个数据节点添加更多内存（32GB、64GB 等）

A: 为了评估和开发目的，你可以在一台主机上运行所有节点。为了获得完整的冗余性和容错性，你需要至少 6 台物理主机。

• 2 个数据节点
• 2 个 SQL/NoSQL 应用程序节点
• 2 个管理节点

许多用户会将管理节点和应用程序节点共置，这会将节点数量减少到 4 个。

A: 是的

MySQL NDB 集群长期以来一直提供地理复制，将集群分布到远程数据中心，通过将数据推送到用户附近以减少地理位置延迟的影响，以及提供灾难恢复功能。

地理复制是异步的，可以实现为主动/主动或主动/被动集群。

地理复制是跨数据中心部署的推荐部署模式。

A: 应用程序可以使用任何 MySQL 连接器进行开发。MySQL NDB 集群还通过 JavaScript、Memcached、C++、Java、JPA 和 HTTP/REST 提供原生 NoSQL 连接。

A: 不，接口是相同的。

A: 是的。MySQL NDB 集群经常被 ISV 和网络设备提供商 (NEP) 用作嵌入式数据库。 客户列表 »

A: 地理复制支持在主动/主动地理位置分离的集群之间进行异步复制。这通常用于扩展全球服务、数据本地化和灾难恢复。

A: 是的，MySQL NDB 集群支持单向和双向复制。使用双向地理复制时，会提供事务冲突检测和解决功能。

A: MySQL NDB 集群配置通常会在不同的主机上至少保存 2 个数据副本。为了覆盖整个系统故障，事务日志和检查点文件会以可配置的频率持久化到磁盘。此外，非索引数据可能会存储在磁盘上。

A: MySQL NDB Cluster 同时提供无盘选项和无日志选项。

对于无盘选项，以下限制适用：

1. 无磁盘数据
2. 集群故障时数据丢失
3. 无备份

对于无日志选项，集群仍然会创建日志文件，但数据不会被检查点到磁盘。

A: 否。MySQL NDB Cluster Manager 仅作为商业版 MySQL NDB Cluster Carrier Grade Edition (CGE) 数据库的一部分提供。要购买 MySQL NDB Cluster CGE 的订阅或许可证，请联系 MySQL 销售团队。

A: MySQL NDB Cluster Manager 是一种软件，通过自动化常见的管理任务，简化了 MySQL NDB Cluster 数据库的创建和管理。

A: 通过使用 MySQL NDB Cluster Manager，数据库管理员 (DBA) 和系统管理员能够提高工作效率，使他们能够专注于战略性 IT 举措并更快地响应不断变化的用户需求。同时，以前由于手动配置错误导致的数据库停机风险也大大降低。

A: 例如，以前需要 46 个手动命令¹ 并消耗 DBA 2.5 小时² 的时间的 MySQL NDB Cluster 数据库滚动重启管理操作现在可以通过单个命令执行，并且使用 MySQL NDB Cluster Manager 实现完全自动化，从而降低

• 管理复杂性和开销；
• 通过配置和变更管理流程的自动化降低停机风险；
• 管理命令的自定义脚本编写或内部管理工具的开发和维护。

A: 管理员能够使用单个命令创建和删除整个集群，启动、停止和重启集群，以及在线添加节点。因此，管理员不再需要按顺序手动重启每个数据节点，也不需要创建自定义脚本来自动化此过程。

MySQL NDB Cluster Manager 自动执行在线管理操作，包括升级、降级和重新配置运行中的集群，而不会中断访问数据库的应用程序或客户端。管理员不再需要手动编辑配置文件并将其分发到所有其他集群节点，也不需要确定是否需要滚动重启。MySQL NDB Cluster Manager 处理所有这些任务，从而强制执行最佳实践，使在线操作变得更加简单、快速和不易出错。

A: 两者都可以。MySQL NDB Cluster Manager 提供了将整个集群视为单个实体进行控制的能力，同时还支持非常细粒度的控制，直至集群本身内的单个进程。

A: MySQL NDB Cluster Manager 能够通过自动轮询集群中的每个节点，在操作系统和每个进程级别监控集群运行状况。它可以检测进程或服务器主机是存活、死亡还是挂起，从而更快地进行问题检测、解决和恢复。

A: MySQL NDB Cluster Manager 通过自动化以前由管理员手动执行的任务，集成了并扩展了现有的管理功能。如上例所示，以前需要 46 个手动命令的过程现在减少到一个命令，每个过程步骤都实现完全自动化。

在脚本编写甚至开发自定义管理系统方面，手动开发、测试和维护此类项目非常耗时、成本高且容易出错。对于许多维护活动，使用 MySQL NDB Cluster Manager 可以消除对这种类型活动的需要。

通过自动化，MySQL NDB Cluster Manager 简化了集群管理，同时降低了成本、风险和工作量。

A: 是的。MySQL NDB Cluster 本身具有自我修复功能，通过自动重启失败的数据节点，无需手动干预。MySQL NDB Cluster Manager 通过监控和自动恢复 SQL 和管理节点扩展了此功能。这支持对集群进行更无缝、更完整的自我修复，以完全恢复应用程序的运行和容量。

A: 是的，但使用原生 NDB API 的应用程序节点除外（即通过 C++、Cluster Connector for Java、OpenLDAP 等直接接口访问集群的节点）。

A: 不会。为了确保高可用性操作，MySQL NDB Cluster Manager 与实际数据库进程分离，因此，如果管理代理停止或升级，它不会以任何方式影响正在运行的数据库。当任何给定代理或关联的主机不可用时，MySQL NDB Cluster Manager 继续在剩余节点上运行。

A: MySQL NDB Cluster Manager 实施为一组代理，每个代理都在将包含要管理的 MySQL NDB Cluster 节点（进程）的每个物理主机上运行。管理员将常规 mysql 客户端连接到这些代理中的任何一个，然后每个代理相互通信并协同工作，以跨组成集群的节点执行操作。

A: 使用 MySQL NDB Cluster Manager 管理 MySQL NDB Cluster 部署时，管理员不再编辑配置文件（例如 config.ini 和 my.cnf）；相反，这些文件由代理创建和维护。实际上，如果手动编辑这些文件，更改将被代理中保存的配置信息覆盖。

组成 MySQL NDB Cluster 部署的所有进程都由 MySQL NDB Cluster Manager 启动、重启和停止。这包括数据节点、管理节点和 MySQL Server 节点。

类似地，使用 MySQL NDB Cluster Manager 时，管理员不得使用 ndb_mgm 命令执行管理操作（该命令直接连接到管理节点，这意味着代理本身无法看到使用该命令执行的任何操作）。

A: MySQL NDB Cluster Manager 的引入并没有消除对管理节点的需求；特别地，它们继续执行许多关键角色

• 当数据节点启动（或重启）时，它们连接到管理节点以检索其配置数据（管理节点反过来从代理创建的配置文件中获取该数据）；
• 通过 MySQL NDB Cluster Manager 停止或重启数据节点时，状态更改实际上是由管理节点执行的；
• 管理节点可以继续充当仲裁器（避免脑裂场景）。因此，重要的是继续在与数据节点不同的主机上运行这些进程；
• 一些报告信息（例如，内存使用情况）在 MySQL NDB Cluster Manager 中尚不可用，仍然可以使用 ndb_mgm 工具执行。

A: 代理本身没有守护进程，因此，为了获得最高级别的可用性，管理员可以选择使用进程监控器来检测代理的失败并自动重启它；例如，通过在 /etc/init.d 中创建脚本

A: 是的。当管理代理重启时，它们会自动与其他正在运行的管理代理重新同步，以确保整个集群的配置一致性，无需管理员干预。

A: 是的。所有 MySQL NDB Cluster 配置信息和进程标识符都持久化到磁盘，使它们能够在系统故障或 MySQL NDB Cluster Manager 的重启中幸存。

A: MySQL NDB Cluster Manager 支持每个管理代理之间的异步通信，以便可靠地传播重新配置请求。因此，配置在集群中的所有节点上保持一致。

任何更改只有在所有节点确认已收到重新配置请求后才会提交。如果一个或多个节点未能收到请求，则会向客户端报告错误。通过自动协调重新配置请求，消除了由于手动分发配置文件而导致的错误机会。

A: 请参阅 支持平台页面。

A: MySQL NDB Cluster 6.3 及更高版本。

A: 从以下资源中获取：

• MySQL NDB 集群管理器