MySQL Cluster is designed around a distributed, multi-master ACID compliant architecture with no single point of failure.
MySQL Cluster uses automatic sharding (partitioning) to scale out read and write operations on commodity hardware and can be accessed via SQL and Non-SQL (NoSQL) APIs.
Unlike standard MySQL replication, MySQL Cluster's geographic replication uses optimistic concurrency control and the concept of Epochs to provide a mechanism for conflict detection and resolution,[4] enabling active/active clustering between data centers.
This allows developers to add “distribution awareness” to applications by partitioning based on a sub-key that is common to all rows being accessed by high running transactions.
This ensures that data used to complete transactions is localized on the same shard, thereby reducing network hops.
As the Redo logs are written asynchronously with respect to transaction commit, some small number of transactions can be lost if the full cluster fails, however this can be mitigated by using geographic replication or multi-site cluster discussed above.
As these writes are sequential and limited random access patterns are involved, MySQL Cluster can achieve higher write throughput rates with limited disk hardware compared to a traditional disk-based caching RDBMS.
This checkpointing to disk of in-memory table data can be disabled (on a per-table basis) if disk-based persistence isn't needed.
It can be used independently of a MySQL Server with users accessing the Cluster via the NDB API (C++).
From the MySQL Server perspective the NDB Cluster is a Storage engine for storing tables of rows.
NDB Cluster can concurrently support access from other types of API processes including Memcached, JavaScript/Node.JS, Java, JPA and HTTP/REST.
All API processes can operate on the same tables and data stored in the NDB Cluster.
[16] Book written by Jesper Wisborg Krogh and Mikiya Okuno, support engineers of MySQL.