Germany: +49 89 143 01280
France: +33 1 57 60 83 57
Italy: +39 02 249 59 120
UK: +44 207 553 8447
Brazil: +55 11 5189-1097
1. What is MySQL Cluster?
A: MySQL Cluster is a write-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 Cluster scales horizontally on commodity hardware to serve read and write intensive workloads, accessed via SQL and NoSQL interfaces.
MySQL 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.
2. What is MySQL Cluster Carrier Grade Edition?
A: MySQL Cluster Carrier Grade Edition (CGE) includes tools for management and monitoring of the MySQL Cluster database, coupled with access to Oracle Premier Support. MySQL Cluster CGE is available under a choice of subscription or commercial license and support.
3. Who are the customer references for MySQL Cluster?
4. What is the current version of MySQL Cluster?
A: The current GA version is MySQL Cluster 7.2. MySQL 5.5 is integrated and bundled with MySQL Cluster.
5. Does MySQL Cluster require any special hardware or software?
A: No, MySQL Cluster is designed to run on commodity hardware. Using specialized hardware such as SCI network interconnects one may achieve even higher levels of performance.
6. What are the system requirements for MySQL Cluster?
|OS:||See current list of Supported Platforms »|
|CPU:||Intel/AMD x86, UltraSPARC|
|Memory:||Minimum 1GB RAM|
|Network:||1+ nodes (Gigabit Ethernet - TCP/IP)|
7. How do I qualify a workload as being a good fit for MySQL Cluster?
A: If you answer "YES" to any of the 10 following questions, then you should consider MySQL Cluster as an option for your application's database:
8. What are the ideal applications for MySQL Cluster?
A: Ideal applications include:
See a full list of MySQL Cluster user case studies and applications.
9. Is MySQL Cluster supported on Virtual Machine environments?
A: Yes. MySQL Cluster is tested and certified on Oracle VM.
10. What are the typical performance metrics for MySQL Cluster?
11. How many physical servers are needed to create a minimum Cluster configuration?
A: For evaluation and evelopment 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:
Many users co-locate the Management and Application nodes which reduces the number of nodes to four.
12. Can Data Nodes be split geographically?
A: Yes, as long as your network has the characteristics discussed here
MySQL 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.
13. What data access APIs exist for MySQL Cluster?
A: Applications can be developed using any MySQL Connectors. MySQL Cluster additionally provides native NoSQL connectivity via Memcached, C++, Java, JPA and HTTP/REST.
14. Are the interfaces for 32-bit applications different from 64-bit?
A: No, the interfaces are the same.
15. Is MySQL Cluster suitable as an embedded database?
A: Yes, MySQL Cluster is often used as an embedded database by ISVs and Network Equipment Providers (NEPs). Customer List »
16. What is Geographic Replication for MySQL Cluster?
A: Geographic replication enables asynchronous replication across geographically separate clusters. This is often used for disaster recovery.
17. Is Replication bi-directional?
A: Yes, unidirectional and bi-directional replication are supported in MySQL Cluster. Transaction collision detection and resolution is provided when using bi-directional geographic replication.
18. When using MySQL Cluster as an in-memory database, does MySQL Cluster risk losing data?
A: MySQL 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.
19. Does MySQL Cluster include a diskless option?
A: MySQL Cluster has a diskless option as well as a no-logging option.
For the Diskless option the following restrictions apply:
For the no logging option, Cluster will still create log files, but data will not be checkpointed to disk.
20. Is MySQL Cluster Manager open source software?
A: No. MySQL Cluster Manager is available only as a part of the commercial MySQL Cluster Carrier Grade Edition (CGE) database. To purchase subscriptions or licenses for MySQL Cluster CGE, please contact the MySQL Sales Team.
21. What is MySQL Cluster Manager?
A: MySQL Cluster Manager is software which simplifies the creation and management of the MySQL Cluster database by automating common management tasks.
22. What are the benefits of MySQL Cluster Manager?
A: By using MySQL 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.
23. Can you give me a practical example of where MySQL Cluster Manager would help with productivity and reduce risk of downtime?
A: As an example, management operations requiring rolling restarts of a MySQL Cluster database that previously demanded 46 manual commands1 and which consumed 2.5 hours of DBA time2 can now be performed with a single command, and are fully automated with MySQL Cluster Manager, serving to reduce:
24. What sort of management functionality does MySQL Cluster Manager provide?
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 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 Cluster Manager handles all of these tasks, thereby enforcing best practices and making on-line operations significantly simpler, faster and less error-prone.
25. Does MySQL Cluster Manager manage the entire cluster or just individual nodes within it?
A: It can do both. MySQL 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.
26. What sort of monitoring functionality does MySQL Cluster Manager provide?
A: MySQL 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.
27. Many of the capabilities of MySQL Cluster Manager are already available or can be scripted, so what is the benefit?
A: MySQL 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 Cluster Manager.
Through automation, MySQL Cluster Manager simplifies cluster management, while reducing cost, risk and effort.
28. Can MySQL Cluster Manager recover failed nodes in a cluster?
A: Yes. MySQL Cluster itself has the capability to self-heal from failures by automatically restarting failed Data Nodes, without manual intervention. MySQL 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.
29. So MySQL Cluster Manager can manage, monitor and recover all nodes within a cluster?
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).
30. Will the failure of a MySQL Cluster Manager agent impact the availability of the MySQL Cluster database?
A: No. To ensure high availability operation, MySQL 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 Cluster Manager continues to operate across surviving nodes when any given agent or the associated host is not available.
31. How is MySQL Cluster Manager implemented with the MySQL Cluster database?
A: MySQL Cluster Manager is implemented as a set of agents – one running on each physical host that will contain MySQL 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.
32. How does MySQL Cluster Manager impact previous approaches to managing MySQL Cluster?
A: When using MySQL Cluster Manager to manage a MySQL 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 Cluster deployment are started, restarted and stopped by MySQL Cluster Manager. This includes the data nodes, management nodes and MySQL Server nodes.
Similarly when using MySQL 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).
33. Do I still need management nodes within my cluster?
A: The introduction of MySQL Cluster manager does not remove the need for management nodes; in particular they continue to perform a number of critical roles:
34. Can MySQL Cluster Manager automatically restart failed agents?
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
35. Can recovered MySQL Cluster Manager agents automatically resynchronize with other agents?
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.
36. Can MySQL Cluster Manager persist configuration data across restarts?
A: Yes. All MySQL Cluster configuration information and process identifiers are persisted to disk, enabling them to survive system failures or re-starts of the MySQL Cluster Manager.
37. How does MySQL Cluster Manager ensure the cluster configuration remains consistent across all nodes in the cluster?
A: MySQL 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.
38. Which platforms are supported by MySQL Cluster Manager?
A: Please refer to the Supported Platforms page.
39. Which releases of the MySQL Cluster database are supported by MySQL Cluster Manager?
A: MySQL Cluster 6.3 and above.
40. Where can I learn more about MySQL Cluster Manager?
A: From the resources as follows: