MySQL NDB Cluster FAQ

A: MySQL NDB Cluster is built on the NDB storage engine and provides a highly scalable, real-time, ACID-compliant transactional database, combining 99.999% availability with the low TCO of open source. Designed around a distributed, multi-master architecture with no single point of failure, MySQL NDB Cluster scales horizontally on commodity hardware to serve read and write intensive workloads, accessed via SQL and NoSQL interfaces.

MySQL NDB Cluster's real-time design delivers predictable, millisecond response times with the ability to service millions of operations per second. Support for in-memory and disk-based data, automatic data partitioning (sharding) with load balancing and the ability to add nodes to a running cluster with zero downtime allows linear database scalability to handle the most unpredictable web-based workloads.

A: MySQL NDB Cluster Carrier Grade Edition (CGE) includes tools for the management, monitoring security and auditing of the MySQL NDB Cluster database, coupled with access to Oracle Premier Support. MySQL NDB Cluster CGE is available under a choice of subscription or commercial license and support.

• Learn more about MySQL NDB Cluster CGE

A: See https://www.mysql.com/customers/cluster/.

A: The current GA version is MySQL NDB Cluster 8.0. MySQL 8.0 is integrated and bundled with MySQL NDB Cluster.

A: No, MySQL NDB Cluster is designed to run on commodity hardware. Using specialized hardware such as Infiniband network interconnects one can achieve even higher levels of performance, especially over large clusters with many nodes.

A: If you answer "YES" to any of the following questions, then you should consider MySQL NDB Cluster as an option for your application's database:

• Do you need to shard your database to meet growing volumes of write (UPDATE, INSERT, DELETE) operations?
• Do you need to ensure results from SELECT operations are consistent, regardless of which node they are returned from?
• Would a failure of your database result in application downtime that would cause business disruption, including loss of revenue, loss of reputation, etc?
• Would data loss (even if just several seconds worth) during a failover cause business disruption?
• Is your user experience sensitive to response times?
• Do you need to replicate your database across geographic regions, with each region serving both read and write operations?
• Are you running a diverse range of applications that would benefit from direct access to data, without always relying on SQL (ie JavaScript with node.js, memcached API, Java and JPA applications, HTTP/REST web services and C++ apps)?
• Does your application primarily consist of "short" transactions (ie 10s of operations per transaction versus 1000s) executed in parallel?
• Does your application mainly consist of:
  • Primary key database access, with some JOIN operations
  • versus
  • Regular execution of full table scans and JOINs returning 10s of thousands of rows?

A: Ideal applications include:

• High volume OLTP
• Real time analytics
• Ecommerce and financial trading with fraud detection
• Mobile and micro-payments
• Session management & caching
• Feed streaming, analysis and recommendations
• Content management and delivery
• Massively Multiplayer Online Games
• Communications and presence services
• Subscriber/user profile management and entitlements

See a full list of MySQL NDB Cluster user case studies and applications.

A: Yes. MySQL NDB Cluster is tested and certified on Oracle VM.

A:

• Availability
  • 99.999% (<5 min downtime/year)
• Performance
  • Response Time: sub 5 millisecond (with synchronous replication and access via SQL). Faster response times can be achieved using one of the NoSQL access methods.
  • Throughput of 600,000+ replicated UPDATE operations/sec on a dual-socket Intel server equipped with 64GB RAM. 1 Billion UPDATE operations per minute across a cluster of 30 x Intel Servers.
• Failover
  • Sub-second failover enables you to deliver service without interruption
• Scalability
  • Scale out, scale up and scale dynamically
  • For cost-effective scale-out:
    • Add more application and data nodes per cluster, or
    • Add more CPU threads (16, 32, 64, etc.) or
    • Add more Memory (32GB, 64GB, etc.) per data node

A: For evaluation and development purposes, you can run all nodes on a single host. For full redundancy and fault tolerance, you would need a minimum 6 x physical hosts:

• 2 x data nodes
• 2 x SQL/NoSQL Application Nodes
• 2 x Management Nodes

Many users co-locate the Management and Application nodes which reduces the number of nodes to four.

A: Yes

MySQL NDB Cluster has long offered Geographic Replication, distributing clusters to remote data centers to reduce the affects of geographic latency by pushing data closer to the user, as well as providing a capability for disaster recovery.

Geographic replication is asynchronous and can be implemented as an Active / Active or Active / Passive cluster.

Geographic replication is the recommended deployment model for cross data center deployments.

A: Applications can be developed using any MySQL Connectors. MySQL NDB Cluster additionally provides native NoSQL connectivity via JavaScript, Memcached, C++, Java, JPA and HTTP/REST.

A: No, the interfaces are the same.

A: Yes, MySQL NDB Cluster is often used as an embedded database by ISVs and Network Equipment Providers (NEPs). Customer List »

A: Geographic replication enables asynchronous replication across active / active geographically separate clusters. This is often used for the scale-out of global services, data locality and disaster recovery.

A: Yes, unidirectional and bi-directional replication are supported in MySQL NDB Cluster. Transaction conflict detection and resolution is provided when using bi-directional geographic replication.

A: MySQL NDB Cluster configurations will typically have at least 2 copies of all data, held on different hosts. To cover total system failure, transaction logs and checkpoint files are persisted on disk with configurable frequency. Additionally, non-indexed data may be stored on disk.

A: MySQL NDB Cluster has a diskless option as well as a no-logging option.

For the Diskless option the following restrictions apply:

1. No disk data
2. Loss of data in case of Cluster failure
3. No backup

For the no logging option, Cluster will still create log files, but data will not be checkpointed to disk.

A: No. MySQL NDB Cluster Manager is available only as a part of the commercial MySQL NDB Cluster Carrier Grade Edition (CGE) database. To purchase subscriptions or licenses for MySQL NDB Cluster CGE, please contact the MySQL Sales Team.

A: MySQL NDB Cluster Manager is software which simplifies the creation and management of the MySQL NDB Cluster database by automating common management tasks.

A: By using MySQL NDB Cluster Manager, Database Administrators (DBAs) and Systems Administrator are more productive, enabling them to focus on strategic IT initiatives and respond more quickly to changing user requirements. At the same time, risks of database downtime that previously resulted from manual configuration errors, are significantly reduced.

A: As an example, management operations requiring rolling restarts of a MySQL NDB Cluster database that previously demanded 46 manual commands¹ and which consumed 2.5 hours of DBA time² can now be performed with a single command, and are fully automated with MySQL NDB Cluster Manager, serving to reduce:

• Management complexity and overhead;
• Risk of downtime through the automation of configuration and change management processes;
• Custom scripting of management commands or developing and maintaining in-house management tools.

A: Administrators are able to create and delete entire clusters and start, stop and restart the cluster with a single command, as well as add nodes on-line. As a result, administrators no longer need to manually restart each data node in turn, in the correct sequence, or to create custom scripts to automate the process.

MySQL NDB Cluster Manager automates on-line management operations, including the upgrade, downgrade and reconfiguration of running clusters, without interrupting applications or clients accessing the database. Administrators no longer need to manually edit configuration files and distribute them to all other cluster nodes, or to determine if rolling restarts are required. MySQL NDB Cluster Manager handles all of these tasks, thereby enforcing best practices and making on-line operations significantly simpler, faster and less error-prone.

A: It can do both. MySQL NDB Cluster Manager provides the ability to control the entire cluster as a single entity, while also supporting very granular control down to individual processes within the cluster itself.

A: MySQL NDB Cluster Manager is able to monitor cluster health at both an Operating System and per-process level by automatically polling each node in the cluster. It can detect if a process or server host is alive, dead or has hung, allowing for faster problem detection, resolution and recovery.

A: MySQL NDB Cluster Manager integrates and extends existing management functionality by automating tasks that were previously performed manually by an administrator. As demonstrated in the example above, a process that required 46 manual commands is now reduced to a single command, with each process step being fully automated.

In terms of scripting or even developing a custom management system, it is time consuming, costly and potentially error-prone to manually develop, test and maintain such projects. For many maintenance activities, the need for this type of activity is eliminated with MySQL NDB Cluster Manager.

Through automation, MySQL NDB Cluster Manager simplifies cluster management, while reducing cost, risk and effort.

A: Yes. MySQL NDB Cluster itself has the capability to self-heal from failures by automatically restarting failed Data Nodes, without manual intervention. MySQL NDB Cluster Manager extends this functionality by also monitoring and automatically recovering SQL and Management Nodes. This supports a more seamless and complete self-healing of the Cluster to fully restore operations and capacity to applications.

A: Yes, with the exception of application nodes using the native NDB API (i.e nodes accessing the Cluster via the C++, Cluster Connector for Java, OpenLDAP, etc direct interfaces).

A: No. To ensure high availability operation, MySQL NDB Cluster Manager is decoupled from the actual database processes, so if a management agent stops or is upgraded, it does not impact the running database in any way. MySQL NDB Cluster Manager continues to operate across surviving nodes when any given agent or the associated host is not available.

A: MySQL NDB Cluster Manager is implemented as a set of agents – one running on each physical host that will contain MySQL NDB Cluster nodes (processes) to be managed. The administrator connects the regular mysql client to any one of these agents and then the agents each communicate and work with each other to perform operations across the nodes making up the Cluster.

A: When using MySQL NDB Cluster Manager to manage a MySQL NDB Cluster deployment, the administrator no longer edits the configuration files (for example config.ini and my.cnf); instead, these files are created and maintained by the agents. In fact, if those files are manually edited, the changes will be overwritten by the configuration information which is held within the agents.

All processes making up the MySQL NDB Cluster deployment are started, restarted and stopped by MySQL NDB Cluster Manager. This includes the data nodes, management nodes and MySQL Server nodes.

Similarly when using MySQL NDB Cluster Manager, management actions must not be performed by the administrator using the ndb_mgm command (which directly connects to the management node meaning that the agents themselves would not have visibility of any operations performed with it).

A: The introduction of MySQL NDB Cluster Manager does not remove the need for management nodes; in particular they continue to perform a number of critical roles:

• When data nodes start up (or are restarted) they connect to the management node(s) to retrieve their configuration data (the management node in turn fetches that data from the configuration files created by the agents);
• When stopping or restarting a data node through MySQL NDB Cluster Manager, the state change is actually performed by the management node;
• The management node(s) can continue to act as arbitrators (avoiding a split-brain scenario). For this reason, it is important to continue to run those processes on separate hosts from the data nodes;
• Some reporting information (for example, memory usage) is not yet available in MySQL NDB Cluster Manager and can still be performed using the ndb_mgm tool.

A: There is no angel process for the agents themselves and so for the highest levels of availability, the administrator may choose to use a process monitor to detect the failure of an agent and automatically restart it; for example by creating a script in /etc/init.d

A: Yes. As management agents restart, they are automatically re-synchronized with the other running management agents to ensure configuration consistency across the entire cluster, without administrator intervention.

A: Yes. All MySQL NDB Cluster configuration information and process identifiers are persisted to disk, enabling them to survive system failures or re-starts of the MySQL NDB Cluster Manager.

A: MySQL NDB Cluster Manager supports asynchronous communication between each management agent in order to reliably propagate reconfiguration requests. As a result, configurations remain consistent across all nodes in the cluster.

Any changes are only committed when all nodes confirm they have received the re-configuration request. If one or more nodes fail to receive the request, then an error is reported back to the client. By automating the coordination of re-configuration requests, opportunities for errors resulting from manually distributing configuration files are eliminated.

A: Please refer to the Supported Platforms page.

A: MySQL NDB Cluster 6.3 and above.

A: From the resources as follows:

• MySQL NDB Cluster Manager