MySQL Cluster NDB vs Standard MySQL Instance

This article explores the architectural and operational differences between a MySQL Cluster running the NDB (Network Database) storage engine and a standard MySQL database instance. While a standard MySQL instance relies on local storage engines like InnoDB for single-server operations, a MySQL Cluster leverages the NDB storage engine to distribute data across a shared-nothing network of multiple nodes, enabling auto-sharding, synchronous replication, and continuous uptime.

Shared-Nothing Distributed Architecture vs. Single-Server Storage

The fundamental difference lies in how data is stored and accessed.

• Standard MySQL Instance: Typically utilizes the InnoDB storage engine. It runs as a single monolithic process where the SQL processing layer and the storage engine share the same physical server and local disk resources. Even in replication setups, each server holds a complete copy of the database.
• MySQL Cluster (NDB): Utilizes a “shared-nothing” architecture where data is automatically partitioned (sharded) and distributed across multiple physical servers called Data Nodes. The SQL processing layer is completely decoupled from the storage layer, allowing you to scale query processing and data storage independently.

Synchronous Replication vs. Asynchronous Replication

How data consistency and high availability are achieved differs significantly between the two setups.

• Standard MySQL Instance: Achieves high availability primarily through primary-replica replication. This replication is traditionally asynchronous or semi-synchronous. If the primary node fails, there is a risk of data loss (replication lag) and a manual or scripted failover process is required to promote a replica.
• MySQL Cluster (NDB): Uses synchronous replication internally among the data nodes. When a transaction is committed, the data is written to multiple data nodes simultaneously. If a data node fails, the cluster continues to read and write data from surviving nodes with zero downtime and zero data loss, requiring no manual intervention.

Memory-Centric vs. Disk-Centric Performance

The underlying storage medium and indexing mechanisms are optimized for different workloads.

• Standard MySQL Instance (InnoDB): Designed as a disk-centric storage engine. It uses a buffer pool in RAM to cache frequently accessed data and indexes, but the authoritative data structure is optimized for disk storage.
• MySQL Cluster (NDB): Designed primarily as an in-memory database engine. By default, all table data and indexes are stored in the RAM of the data nodes to provide real-time, predictable sub-millisecond response times. While NDB supports storing non-indexed data on disk, its core architecture is optimized for in-memory operations.

Query Execution and Scalability

The path a query takes and how the system scales differs based on the storage engine.

• Standard MySQL Instance: Scale-up (vertical scaling) is the primary method to handle larger workloads, requiring larger CPUs and more RAM on a single machine. Scale-out (horizontal scaling) is limited to read-only replicas.
• MySQL Cluster (NDB): Scales horizontally for both reads and writes. Applications connect to SQL Nodes (standard MySQL servers acting as stateless frontends). The SQL nodes translate queries and route them directly to the correct Data Nodes holding the specific partition of data. This allows the cluster to handle massive write volumes by simply adding more data nodes to the network.