Carrier-Grade MySQL Clustering

MySQL NDB Cluster Services

In short: MySQL NDB Cluster is a distributed, shared-nothing database that uses the in-memory NDB storage engine to spread data and automatic hash-based sharding across multiple data nodes. With no single point of failure, sub-millisecond latency, and synchronous replication, it is designed for carrier-grade, five-nines availability in real-time, high-throughput workloads.

Deploy carrier-grade MySQL NDB Cluster with in-memory real-time performance, automatic sharding, and shared-nothing architecture for mission-critical applications with five-nines availability requirements.

Get Started Today View Architecture

Executive Direct Answer · MySQL NDB Cluster Production Architecture

JusDB architects carrier-grade MySQL NDB Cluster deployments for workloads with five-nines availability requirements. Our DBREs configure shared-nothing in-memory data nodes, dual-redundant network transporters, automatic fragment partitioning, and online schema changes, designed for sub-millisecond p99 latencies and sub-second failover.

Response Targets: Per Agreement·Availability: Defined in Your Plan·Latency: <1ms Reads & Writes·Topology: Shared-Nothing Data Nodes·ISO 27001 & SOC 2 Type II: aligned, certification in progress

2–4

Replicas per Node Group

<1ms

Latency

144

Max Data Nodes

NDB Cluster Architecture

Management Nodes

ndb_mgmd

Data Nodes

ndbd / ndbmtd

SQL Nodes

mysqld

API Nodes

NDB API / ClusterJ

Shared-Nothing, In-Memory Architecture

Comprehensive MySQL NDB Cluster Services

From initial deployment to advanced optimization, we provide end-to-end MySQL NDB Cluster solutions for carrier-grade environments.

NDB Cluster Deployment

Complete setup and configuration of MySQL NDB Cluster with data, SQL, and management nodes

Management node (ndb_mgmd) setup
Data node (ndbd/ndbmtd) configuration
SQL node (mysqld with NDB) integration
config.ini and my.cnf optimization

Auto-Sharding & Partitioning

Automatic data distribution and partitioning across data nodes for linear scalability

Hash-based partition key design
Node group planning and balancing
Table schema optimization for NDB
Online repartitioning and rebalancing

High Availability & Failover

Carrier-grade availability design with no single point of failure and sub-second failover

Automatic node failure detection
Sub-second failover orchestration
Node group redundancy planning
Split-brain prevention strategies

Performance Optimization

In-memory tuning, batch operations, and NDB API for maximum throughput and minimal latency

In-memory vs disk data configuration
Batch operation optimization
NDB API and ClusterJ tuning
Adaptive send and receive thread tuning

Geo-Replication

Multi-site NDB Cluster replication for disaster recovery and geographic data distribution

NDB Cluster Replication setup
Active-active conflict resolution
Cross-datacenter DR planning
Epoch-based conflict detection

Monitoring & Management

Comprehensive monitoring, alerting, and ongoing cluster management with MySQL Cluster Manager

ndb_mgm and ndbinfo monitoring
MySQL Cluster Manager (MCM) setup
Performance metrics and dashboards
Automated alerting and agreed incident response

Why Choose MySQL NDB Cluster?

MySQL NDB Cluster delivers carrier-grade availability with in-memory performance, automatic sharding, and a shared-nothing architecture designed for zero downtime.

In-Memory Real-Time Performance

All data is stored in-memory across data nodes, delivering sub-millisecond read and write latency. Disk-based data tables are available for larger datasets that don't require in-memory speed.

Shared-Nothing Architecture

No shared disks or storage — each data node owns its partition of the data. This eliminates single points of failure and enables linear horizontal scaling by adding more data nodes.

Automatic Failover (<1 Second)

When a data node fails, the cluster automatically promotes replicas and reroutes traffic in under 1 second. Applications experience no interruption thanks to transparent failover.

Linear Horizontal Scaling

Add data nodes online to increase both capacity and throughput linearly. NDB Cluster supports up to 144 data nodes with automatic data redistribution across the expanded cluster.

NDB Cluster Key Metrics

Availability Design(Oracle's design target)

Five nines

Read Latency(In-memory access)

<1ms

Failover Time(Automatic recovery)

<1s

Max Data Nodes(Linear scaling)

144

Max Replicas(Per node group)

Online Operations(Schema changes, upgrades)

Yes

NDB Cluster vs InnoDB Cluster

Choose the right MySQL clustering solution based on your workload characteristics and availability requirements.

Recommended for Real-Time

MySQL NDB Cluster

In-memory, shared-nothing, carrier-grade

In-memory storage engine (NDB)

Automatic hash-based sharding

Five-nines availability design

Sub-millisecond latency

Up to 144 data nodes

NDB API for direct node access

Online rolling upgrades

Built-in geo-replication

Best for: Telecom, real-time billing, fraud detection, gaming

Recommended for OLTP

MySQL InnoDB Cluster

Disk-based, Group Replication, general-purpose

InnoDB storage engine (disk-based)

Group Replication consensus

Automatic primary failover

Millisecond latency

Up to 9 nodes

Standard MySQL protocol

MySQL Shell AdminAPI

MySQL Router integration

Best for: General OLTP, web applications, e-commerce

NDB Cluster Architecture Components

Understanding the node types that make up a production MySQL NDB Cluster deployment.

Management Nodes

ndb_mgmd

Manage cluster configuration and orchestrate node startup, shutdown, and failover. Stores and distributes config.ini to all nodes.

Cluster configuration management
Node arbitration
Online config changes
Backup coordination

Data Nodes

ndbd / ndbmtd

Store and replicate data in-memory. Handle data partitioning, transaction execution, and checkpointing to disk.

In-memory data storage
Synchronous replication
Local checkpoints (LCP)
Global checkpoints (GCP)

SQL Nodes

mysqld (NDB)

Standard MySQL servers with the NDB storage engine. Provide SQL interface for applications to access cluster data.

Standard MySQL protocol
Query parsing and optimization
Join pushdown to data nodes
Connection pooling

API Nodes

NDB API / ClusterJ

Direct programmatic access to data nodes bypassing SQL overhead. Used for maximum performance in latency-sensitive applications.

Direct data node access
C++ NDB API
Java ClusterJ API
Node.js ndb adapter

Our NDB Cluster Implementation Process

A proven methodology for deploying production-ready MySQL NDB Cluster with comprehensive testing and validation.

Architecture Planning

Analyze workload patterns, data model requirements, and availability targets. Design node topology, node group layout, and partition key strategy.

Cluster Deployment

Deploy management, data, and SQL nodes. Configure config.ini, memory allocation, data node replicas, and network transporter settings.

Integration & Testing

Migrate data to NDB tables, validate application compatibility, perform failover testing, and benchmark throughput and latency.

Production Go-Live

Cut over to production with monitoring, alerting, backup procedures, and runbooks. Provide training and ongoing support, with 24x7 on-call available.

NDB Cluster Use Cases

Industries and workloads where MySQL NDB Cluster delivers the greatest impact.

Telecommunications

Subscriber databases (HLR/HSS), real-time billing and charging, network element management, and session data stores for millions of concurrent users.

Financial Services

Real-time fraud detection, payment authorization, risk scoring, and high-frequency transaction processing with guaranteed data consistency.

Gaming

Player session state, real-time leaderboards, matchmaking engines, and in-game inventory management with sub-millisecond response times.

IoT & Edge

High-velocity sensor data ingestion, device state management, real-time analytics on device telemetry, and edge-to-cloud data pipelines.

How JusDB NDB Cluster Architecture compares to alternative models.

Generic cloud database providers and legacy IT agencies lack specialized NDB storage engine mastery, fragment replica distribution, high-speed transporter tuning, and carrier-grade availability engineering. Here is how our DBREs compare:

NDB Architecture Vector	JusDB NDB Specialists	Cloud Native Default	Traditional Agency	In-House / DIY
In-Memory Data Node Partitioning & Fragment Replica Distribution	Automatic hash-based partitioning across distributed data nodes (ndbd/ndbmtd) with multi-threaded fragment replica distribution across node groups, ensuring balanced RAM utilization and zero single point of failure.	Basic managed replication (RDS read replicas or Aurora storage) without true shared-nothing in-memory sharding; cannot scale write throughput linearly across RAM data nodes.	Generic master-replica replication script templates that collapse under high-concurrency writes and lack fragment distribution awareness.	Manual application-level database sharding with fragile cross-shard join logic, hot-spot skew, and complex manual resharding scripts.
Carrier-Grade Availability Design & Synchronous Sub-Millisecond Replication	Architecture for carrier-grade availability targets, with synchronous two-phase commit replication between data node fragments, tuned heartbeat-based node failure detection, and dual management node arbitration.	Asynchronous or semi-sync replication with 30–120s multi-AZ failovers, DNS propagation delays, and intermittent replication lag spikes during write bursts.	Unverified HA setups without quorum arbitration; failovers often lead to split-brain data corruption or extended downtime.	Manual intervention during node failure, waking DBAs at 3 AM to assess logs, resulting in 30–60+ minutes of unplanned business downtime.
Dual-Redundant High-Speed Interconnect & Transporter Sizing	Tuned dual-bonded 10/25/100GbE interconnects with custom TCP/IP and shared-memory (SHM) transporters, calibrated buffer sizes, and kernel socket buffer tuning to eliminate heartbeat drops.	Shared cloud network fabric subject to noisy-neighbor packet jitter, transient disconnects, and unconfigurable kernel network transport parameters.	Standard single-NIC network configurations with default OS MTU sizes, causing packet fragmentation and dropped cluster heartbeat nodes.	Unoptimized standard network stacks that drop cluster connections under heavy packet bursts, triggering false-positive node evictions.
Online Schema Upgrades & Live Data Node Expansion	Rolling online schema upgrades, live online table reorganization, and dynamic data node cluster expansion without interrupting real-time client transaction traffic.	Maintenance-window schema changes requiring table-level read locks or costly instance recreations that interrupt active application connections.	Risky maintenance windows with long outages; schema change failures often corrupt metadata and force full restore drills.	Fear of online DDL changes leading to years of technical debt and deferred schema optimizations.
Disk Data Tablespace Architecture for Cold Data Tiering	Architected Disk Data storage engines mapping non-indexed columns to high-IOPS NVMe tablespaces while retaining hot transactional rows in RAM, cutting overall memory costs.	All-or-nothing disk storage tiers (EBS/gp3) that fail to leverage distributed RAM for real-time reads and writes.	Unfamiliarity with NDB Disk Data mechanics, pushing all data into costly RAM until servers suffer from out-of-memory kernel panics.	Ad-hoc archiving scripts that copy records to cold tables, introducing data discrepancies and query complexities.
Initial-Response Targets & Senior DBRE Escalation	Named MySQL NDB DBREs on a live incident bridge, with active telemetry and deep engine diagnostics. Initial-response targets: 2 to 4 hours in covered business hours; 30 minutes for P1 incidents with 24x7 on-call. Targets, not resolution guarantees.	1–4 hour ticket queues with generic cloud support reps reading scripted triage checklists without NDB kernel internals mastery.	Next-business-day response with junior generalist administrators who have never managed a production NDB cluster.	Single-engineer on-call burnout, knowledge silos, and panic-driven troubleshooting during catastrophic telecommunications outages.

Critical NDB Cluster Outage Modes We Eliminate

Operating real-time distributed shared-nothing in-memory databases introduces unique availability failure modes under dual node failures, DataMemory exhaustion, and transporter packet loss. Our DBREs resolve these breakdown vectors:

P1 Critical

Node Group Double Failure Causing Cluster Crash

If two data nodes belonging to the exact same node group crash simultaneously before fragment replication finishes, the entire cluster halts immediately to protect data integrity, causing catastrophic downtime.

JusDB Engineering Mitigation:

JusDB sizes isolated node groups across physically separated power and rack failure domains with dual management server arbitration and automated fast-recovery runbooks.

P1 Critical

DataMemory Exhaustion Freezing Write Transactions

When transactional tables exceed configured DataMemory limits, the NDB storage engine refuses all further INSERT and UPDATE statements, throwing Error 708 and freezing active application flows.

JusDB Engineering Mitigation:

JusDB configures proactive memory threshold alarms at 75% capacity, calibrates Disk Data tablespaces for cold attributes, and automates online data node expansion.

P2 High

Interconnect Packet Loss Triggering Node Eviction

Transient packet congestion or MTU mismatches on cluster interconnect switches trigger missed heartbeat signals, causing management nodes to falsely evict healthy data nodes.

JusDB Engineering Mitigation:

JusDB tunes dedicated bonded private network interfaces, adjusts HeartbeatIntervalDataNode thresholds, and optimizes OS socket buffer kernel parameters.

Telemetry Runbooks · Non-Blocking MySQL NDB Diagnostics

Our NDB DBREs execute non-blocking CLI telemetry inspections to evaluate cluster membership, node group distribution, and memory utilization without impacting active client queries:

Management Client: Cluster Topology & Node Group State

ndb_mgm

// Inspect live cluster connection status, data nodes, and management node state

# 1. Check full cluster node connectivity and node group status
ndb_mgm -e "SHOW"

# 2. Inspect cluster memory utilization across all active data nodes
ndb_mgm -e "ALL REPORT MEMORYUSAGE"

# 3. Verify transporter buffer states and packet drop counters
ndb_mgm -e "ALL DUMP 1000"

SQL Telemetry: ndbinfo Diagnostics & Operations

mysql

// Query ndbinfo virtual tables for memory allocation, cluster nodes, and transporter lag

# 1. Query detailed RAM page usage per data node
mysql -e "SELECT node_id, memory_type, used, total, percentage FROM ndbinfo.memoryusage;"

# 2. Inspect node status, uptime, and communication status
mysql -e "SELECT node_id, status, uptime, address FROM ndbinfo.cluster_nodes;"

# 3. Check live thread activity and send/receive buffer contention
mysql -e "SELECT * FROM ndbinfo.transporters WHERE status != 'CONNECTED';"

MySQL NDB Cluster — Frequently Asked Questions

Common questions about MySQL NDB Cluster deployment, architecture, and management.

What is MySQL NDB Cluster and how does it differ from InnoDB Cluster?

MySQL NDB Cluster uses the NDB (Network DataBase) storage engine with a shared-nothing architecture where data is stored in-memory across distributed data nodes. Unlike InnoDB Cluster which uses Group Replication over InnoDB, NDB Cluster provides automatic sharding, sub-millisecond latency, and a carrier-grade, five-nines availability design. NDB is ideal for real-time, high-throughput workloads like telecom and financial services, while InnoDB Cluster is better suited for general-purpose OLTP applications.

What uptime does MySQL NDB Cluster provide?

Oracle designs MySQL NDB Cluster for carrier-grade, five-nines availability through its shared-nothing architecture with no single point of failure, automatic failover in under 1 second, online schema changes, rolling upgrades, and node-level redundancy with synchronous replication across data node groups. The availability a deployment achieves depends on its topology, hardware and operations; JusDB's availability and response commitments are defined in your service agreement.

How does auto-sharding work in MySQL NDB Cluster?

NDB Cluster automatically partitions (shards) data across all data nodes using a hash-based distribution on the primary key. Each partition is stored with one or more replicas on different data nodes for redundancy. This happens transparently — applications interact with SQL nodes using standard MySQL queries and the cluster handles data distribution, rebalancing, and replica management automatically.

What are the hardware requirements for MySQL NDB Cluster?

NDB Cluster data nodes require sufficient RAM to hold the entire dataset in memory (plus indexes and overhead). A minimum of 2 data nodes is required for redundancy, plus at least 1 management node and 1 SQL node. For production deployments, we recommend dedicated servers with 64GB+ RAM for data nodes, fast local storage for disk-based data and checkpoints, and low-latency networking (10GbE or better) between all nodes.

Can MySQL NDB Cluster handle geographic replication?

Yes, MySQL NDB Cluster supports geographic replication through NDB Cluster Replication, which uses asynchronous MySQL replication between two or more NDB Cluster deployments. This enables active-passive and active-active multi-site configurations for disaster recovery and geographic data distribution. Conflict detection and resolution functions are built in for active-active setups.

What industries benefit most from MySQL NDB Cluster?

MySQL NDB Cluster is widely used in telecommunications (subscriber databases, real-time billing, HLR/HSS), financial services (real-time fraud detection, payment processing), gaming (session state, leaderboards, matchmaking), IoT (sensor data ingestion, device management), and any industry requiring sub-millisecond response times, continuous availability, and high write throughput.

Related MySQL Services

Explore complementary MySQL high availability and clustering solutions from JusDB.

MySQL High Availability

Architect resilient MySQL with replication, automated failover, and zero-downtime topologies.

Learn more

MySQL InnoDB Cluster

Deploy Group Replication with MySQL Shell AdminAPI and MySQL Router for general-purpose OLTP HA.

Learn more

Aurora MySQL

Run managed, cloud-native MySQL on Amazon Aurora with auto-scaling storage and fast failover.

Learn more

Ready to Deploy Carrier-Grade MySQL Clustering?

Let our experts implement MySQL NDB Cluster for your mission-critical applications, designed for five-nines availability and sub-millisecond latency.

Start Your Project Schedule Consultation