NDB Cluster Architecture, Distribution, Availability, and When It Fits

Learning outcomes

ServiceHub already knows how to make an ordinary InnoDB deployment highly available with replication and InnoDB Cluster. A new requirement now appears: very high write concurrency, fast node failure recovery, and horizontal storage distribution. The tempting response is “use NDB because it is clustered.” That is not an architecture decision. NDB Cluster is a different distributed storage system with different transaction, indexing, network, schema, and operational behavior. This lesson builds the mental model needed to reject or accept it for the right reasons.

NDB changes the storage architecture, not just one configuration flag

In an ordinary ServiceHub server, mysqld executes SQL and InnoDB stores the table on that server. In NDB Cluster, SQL nodes still run mysqld, but tables using the NDB storage engine are held by a distributed set of data nodes. A management node provides cluster configuration and management services. Applications may connect through one or more SQL nodes, while the durable table state is partitioned and replicated across data nodes.

Application clients      |      +---- SQL/X/API ----> SQL node A (mysqld + NDB engine)      |                    SQL node B (mysqld + NDB engine)      |      +-------------------- optional native NDB APIsManagement node (ndb_mgmd)      |      +---- cluster configuration / status      |Data-node group 1                 Data-node group 2+--------------------+           +--------------------+| data node 1        |           | data node 3        || fragment replica A |           | fragment replica B |+--------------------+           +--------------------+| data node 2        |           | data node 4        || replica of A       |           | replica of B       |+--------------------+           +--------------------+The SQL node is not the sole owner of NDB table data.

A partition is a horizontal subset of rows. NDB divides table data into fragments and keeps redundant fragment replicas according to the cluster configuration. That internal synchronous redundancy is different from the binary-log flow used by conventional MySQL source/replica replication. NDB can also replicate between NDB clusters asynchronously, but that is another layer.

Why NDB can fit—and why it can surprise an InnoDB team

NDB is attractive for some telecom, session-management, high-volume OLTP, and low-latency availability workloads. It is not automatically better for a relational application with wide transactions, complex joins, large analytical scans, or an operational team optimized around InnoDB. The network becomes part of the storage system, so network topology and latency are first-class design inputs.

Mandatory lab: prove what your current server can actually provide

DROP DATABASE IF EXISTS servicehub_special_lab;CREATE DATABASE servicehub_special_lab  CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;USE servicehub_special_lab;CREATE TABLE architecture_decisions (  decision_id BIGINT AUTO_INCREMENT PRIMARY KEY,  capability VARCHAR(64) NOT NULL,  workload_need VARCHAR(240) NOT NULL,  chosen_boundary VARCHAR(160) NOT NULL,  evidence VARCHAR(500) NOT NULL,  recorded_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP) ENGINE=InnoDB;SELECT ENGINE,SUPPORT,TRANSACTIONS,XA,SAVEPOINTSFROM information_schema.ENGINESWHERE ENGINE IN ('InnoDB','NDBCLUSTER','NDB')ORDER BY ENGINE;SELECT @@version AS server_version,       @@version_comment AS edition,       @@default_storage_engine AS default_engine;

On the standard Community Server package, you should expect InnoDB to be available and NDB not to be a normal usable engine. That observation is not an NDB limitation; it proves the packaging boundary. NDB Cluster is downloaded as its own distribution. If a future machine shows NDB available, record the exact distribution and version rather than assuming it matches a generic MySQL Server installation.

Intentionally wrong approach: force ENGINE=NDBCLUSTER on the ordinary server

USE servicehub_special_lab;CREATE TABLE ndb_assumption_test (  id BIGINT PRIMARY KEY,  payload VARCHAR(100) NOT NULL) ENGINE=NDBCLUSTER;-- On a normal Community Server where NDB is unavailable, expect-- an unknown/unavailable storage-engine error.-- Do not "fix" this by changing production packages in place.SHOW WARNINGS;

The correct response is architectural: verify that the requirement justifies a separate NDB topology, then test that topology independently. The wrong response is to treat an unavailable engine error as a package nuisance and replace a production MySQL installation without a migration plan.

Optional NDB topology exercise: read the configuration before you deploy it

[ndb_mgmd]NodeId=1HostName=mgmt1DataDir=/var/lib/mysql-cluster[ndbd default]NoOfReplicas=2DataMemory=1024M[ndbd]NodeId=2HostName=data1DataDir=/var/lib/mysql-cluster[ndbd]NodeId=3HostName=data2DataDir=/var/lib/mysql-cluster[mysqld]NodeId=4HostName=sql1[mysqld]NodeId=5HostName=sql2

This sample exists to identify roles, not to prescribe memory or host counts. Production NDB sizing depends on row/index footprint, replicas, failure domains, networking, checkpoints/backups, API concurrency, and operational requirements. A two-data-node educational cluster can demonstrate roles; it does not prove a production design.

Failure domains, node groups, and what “available” actually means

NDB availability comes from placing fragment replicas on different data nodes and arranging those nodes into node groups. That is not the same thing as saying “two copies exist, therefore the service survives any two failures.” Which nodes fail together matters. A pair of data nodes in the same node group represents replicas of the same partitions; losing every replica for one partition makes the affected data unavailable even if other data nodes are still alive. Management nodes coordinate configuration and cluster membership, while SQL nodes are MySQL Server processes that expose SQL; neither substitutes for a missing data replica.

Before selecting NDB, map the physical failure domains—hosts, racks, availability zones, power, network paths—and place replicas so one credible failure does not remove all copies of a fragment. Also budget for rolling maintenance: a topology that is technically redundant can become fragile while one node is intentionally offline. Production acceptance therefore includes failure injection, restart/recovery timing, backup/restore, schema-change behavior, and application retry semantics, not only a successful CREATE TABLE ... ENGINE=NDBCLUSTER.

# Run only against an optional disposable NDB Cluster deployment.ndb_mgm -e show# From an SQL node:SHOW ENGINES;SELECT TABLE_SCHEMA,TABLE_NAME,ENGINEFROM information_schema.TABLESWHERE ENGINE='NDBCLUSTER';

Record the decision, including the reasons not to choose NDB

INSERT INTO architecture_decisions(capability,workload_need,chosen_boundary,evidence)VALUES('distributed OLTP storage', 'ServiceHub wants HA and possible future horizontal write scale', 'retain InnoDB/Group Replication until NDB workload fit is proven', 'current mandatory lab is InnoDB; NDB requires separate topology; joins, transaction semantics, network and operational model must be tested');SELECT * FROM architecture_decisions ORDER BY decision_id;

A good decision record can say “not yet.” If future load testing shows that the dominant transactions are short, key-oriented, distributable, and constrained by the single-writer architecture, NDB can be evaluated using representative data and failure tests. If the dominant problem is reporting, search, or analytical scans, NDB is solving the wrong problem.

Authoritative references

• MySQL Community Server 8.4 Downloads
• MySQL NDB Cluster 8.4 Downloads
• MySQL 8.4 — NDB Cluster
• MySQL 8.4 — InnoDB Compared with NDB Cluster
• MySQL 8.4 — Using MySQL as a Document Store
• MySQL Shell 8.4
• MySQL X DevAPI User Guide
• MySQL 8.4 — Spatial Analysis Functions
• MySQL 8.4 — Full-Text Search