2. <Insert Picture Here>
MySQL Cluster for Real Time, HA Services
Bill Papp (bill.papp@oracle.com)
Principal MySQL Sales Consultant
Oracle
3. Agenda
• Overview of MySQL Cluster
• Design Goals, Evolution, Workloads, Users
• Architecture and Core Technology
• Deep Dive, New Features & Capabilities
• MySQL Cluster 7.1
• MySQL Cluster Manager
• Resources to Get Started
<Insert Picture Here>
4. MySQL Cluster Goals
• High Performance: Write Scalability & Low Latency
• 99.999% Availability
• Low TCO
5. MySQL Cluster - Key Advantages
High Throughput
Reads & Writes
Carrier-Grade
Availability
Distributed, Parallel architecture
Transactional, ACID-compliant relational database
Shared-nothing design, synchronous data replication
Sub-second failover & self-healing recovery
Real-Time
Responsiveness
Data structures optimized for RAM. Real-time extensions
Predictable low latency, bounded access times
On-Line, Linear
Scalability
Incrementally scale out, scale up and scale on-line
Linearly scale with distribution awareness
Low TCO,
Open platform
GPL & Commercial editions, scale on COTS
Flexible APIs: SQL, C++, Java, OpenJPA, LDAP & HTTP
6. MySQL Cluster Highlights
Distributed Hash Table backed by an ACID Relational Model
Shared-Nothing Architecture, scale-out on commodity
hardware
Implemented as a pluggable storage engine for the MySQL
Server with additional direct access via embedded APIs.
Automatic or user configurable data partitioning across nodes
Synchronous data redundancy
7. MySQL Cluster Highlights (cont.)
Sub-second fail-over & self-healing recovery
Geographic replication
Data stored in main-memory or on disk (configurable percolumn)
Logging and check pointing of in-memory data to disk
Online operations (i.e. add-nodes, schema updates,
maintenance, etc)
8. MySQL Cluster – Users & Applications
HA, Transactional Services: Web & Telecoms
• Telecoms
•
•
•
•
•
•
•
Subscriber Databases (HLR/HSS)
Service Delivery Platforms
VoIP, IPTV & VoD
Mobile Content Delivery
On-Line app stores and portals
IP Management
Payment Gateways
• Web
•
•
•
•
•
User profile management
Session stores
eCommerce
On-Line Gaming
Application Servers
http://www.mysql.com/customers/cluster/
9. MySQL Cluster Architecture
Parallel Database with no SPOF: High Read & Write Performance &
99.999% uptime
Clients
MySQL Cluster Application Nodes
MySQL
Cluster
Mgmt
MySQL
Cluster
Mgmt
MySQL Cluster Data Nodes
10. Example Configuration
mysql
client
7. mysqld
8. mysqld
1. ndb_mgmd
2. ndb_mgmd
agent
agent
192.168.0.10
192.168.0.11
3. ndbd
4. ndbd
5. ndbd
6. ndbd
agent
agent
192.168.0.12
n. mysqld
n. ndb_mgmd
n. ndbd
agent
192.168.0.13
MySQL Server (ID=n)
Management Node (ID=n)
Data Node (ID=n)
MySQL Cluster Manager agent
• MySQL Cluster Manager agent
runs on each physical host
• No central process for Cluster
Manager – agents co-operate,
each one responsible for its
local nodes
• Agents are responsible for
managing all nodes in the
cluster
• Management responsibilities
• Starting, stopping & restarting
nodes
• Configuration changes
• Upgrades
• Host & Node status reporting
• Recovering failed nodes
11. Creating & Starting a Cluster
mysql
client
1. Define the site:
Mysql> create site --hosts=192.168.0.10,192.168.0.11,
-> 192.168.0.12,192.168.0.13 mysite;
7. mysqld
8. mysqld
1. ndb_mgmd
2. ndb_mgmd
agent
agent
192.168.0.10
3. ndbd
192.168.0.11
4. ndbd
5. ndbd
6. ndbd
agent
agent
192.168.0.12
192.168.0.13
2. Expand the MySQL Cluster tar-ball(s)
from mysql.com to known directory
3. Define the package(s):
Mysql> add package --basedir=/usr/local/mysql_6_3_26 6.3;
Mysql> add package --basedir=/usr/local/mysql_7_0_7 7.0;
Note that the basedir should match the
directory used in Step 2.
4. Create the Cluster
Mysql> create cluster --package=6.3
-> --processhosts=ndb_mgmd@192.168.0.10,ndb_mgmd@192.168.0.11,
-> ndbd@192.168.0.12,ndbd@192.168.0.13, ndbd@192.168.0.12,
-> ndbd@192.168.0.13,mysqld@192.168.9.10,mysqld@192.168.9.11
-> mycluster;
This is where you define what
nodes/processes make up the Cluster and
where they should run
5. Start the Cluster:
Mysql> start cluster mycluster;
12. Upgrade Cluster
mysql
client
7. mysqld
8. mysqld
1. ndb_mgmd
2. ndb_mgmd
agent
agent
192.168.0.10
192.168.0.11
3. ndbd
4. ndbd
5. ndbd
6. ndbd
agent
agent
192.168.0.12
192.168.0.13
• Upgrade from MySQL Cluster 6.3.26 to 7.0.7:
mysql> upgrade cluster --package=7.0 mycluster;
• Automatically upgrades each node and restarts
the process – in the correct order to avoid any
loss of service
• Without MySQL Cluster Manager, the
administrator must stop each process in turn,
start the process with the new version and wait
for the node to restart before moving onto the
next one
13. Out of the Box Scalability: Data Partitioning
• Data partitioned across Data Nodes
• Rows are divided into partitions, based on a hash of all or part of the primary
key
• Each Data Node holds primary fragment for 1 partition
• Also stores secondary fragment of another partition
• Records larger than 8KB stored as BLOBs
16. On-Line Scaling & Maintenance
1. New node group added
2. Data is re-partitioned
3. Redundant data is deleted
4. Distribution is switched to share
load with new node group
•
Can also update schema online
•
Upgrade hardware &
software with no downtime
•
Perform back-ups on-line
17. Geographic Replication
Cluster 1
MyISAM
Synchronous
replication
Asynchronous
replication
Cluster 2
MyISAM
InnoDB
Synchronous replication
within a Cluster node group
for HA
Bi-Direction asynchronous
replication to remote Cluster
for geographic redundancy
Asynchronous replication to
non-Cluster databases for
specialised activities such as
report generation
Mix and match replication
types
18. High Throughput, Low Latency Transactional
Performance
DBT2 Benchmark, 4-MySQL Cluster Data Nodes
300000
Transactions Per Minute
250000
200000
MySQL Cluster 7.0
MySQL Cluster 6.3
150000
100000
50000
0
1
4
8
12
16
20
24
28
32
36
40
Number of MySQL Server Nodes
http://www.mysql.com/why-mysql/benchmarks/mysql-cluster/
• MySQL Cluster delivered:
– 250k TPM, 125k operations per second
– Average 3ms response time
– 4.3x higher throughput than previous MySQL Cluster 6.3 release
19. MySQL Cluster vs MySQL MEMORY:
30x Higher Throughput / 1/3rd the Latency on a single node
•
•
•
Table level locking inhibits MEMORY scalability beyond a single
client connection
Check-pointing & logging enabled, MySQL Cluster still delivers
durability
4 socket server, 64GB RAM, running Linux
20. MySQL Cluster CGE 7.1 – Key Enhancements
Reducing Cost of Operations
• Simplified Management &
Monitoring:
• NDBINFO
• MySQL Cluster Manager (part of CGE
only)
• Faster Restarts
Delivering up to 10x higher
Java Throughput
• MySQL Cluster Connector for
Java:
• Native Java API
• OpenJPA Plug-In
21. Real-Time Metrics w/ ndbinfo
mysql> use ndbinfo
mysql> show tables;
+-------------------+
| Tables_in_ndbinfo |
+-------------------+
| blocks
|
| config_params
|
| counters
|
| logbuffers
|
| logspaces
|
| memoryusage
|
| nodes
|
| resources
|
| transporters
|
+-------------------+
• New database (ndbinfo) which
presents real-time metric data in
the form of tables
• Exposes new information
together with providing a simpler,
more consistent way to access
existing data
• Examples include:
• Resource usage (memory, buffers)
• Event counters (such as number of
READ operations since last restart)
• Data node status and connection
status
22. Real-Time Metrics w/ ndbinfo (cont.)
• Example 1: Check memory usage/availability
mysql> select * from memoryusage;
+---------+--------------+------+------+
| node_id | DATA_MEMORY | used | max |
+---------+--------------+------+------+
|
3 | DATA_MEMORY | 594 | 2560 |
|
4 | DATA_MEMORY | 594 | 2560 |
|
3 | INDEX_MEMORY | 124 | 2336 |
|
4 | INDEX_MEMORY | 124 | 2336 |
+---------+--------------+------+------+
• Note that there is a DATA_MEMORY and INDEX_MEMORY row for
each data node in the cluster
• If the Cluster is nearing the configured limit then increase the
DataMemory and/or IndexMemory parameters in config.ini and
then perform a rolling restart
23. Real-Time Metrics w/ ndbinfo (cont.)
• Example 2: Check how many table scans performed on each data
node since the last restart
mysql> select node_id as 'data node', val as 'Table Scans'
from counters where counter_name='TABLE_SCANS';
+-----------+-------------+
| data node | Table Scans |
+-----------+-------------+
|
3 |
3 |
|
4 |
4 |
+-----------+-------------+
• You might check this if your database performance is lower than
anticipated
• If this figure is rising faster than you expected then examine your
application to understand why there are so many table scans
24. MySQL Cluster 7.1: ndbinfo
• Example 3: Check if approaching the point at which the undo log completely
fills up between local checkpoints (which could result in delayed transactions
or even a database halt if not addressed):
mysql> select node_id as 'data node', total as 'configured undo log
buffer size', used as 'used buffer space' from logbuffers where
log_type='DD-UNDO‘;
+-----------+---------------------------------+-------------------+
| data node | configured undo log buffer size | used buffer space |
+-----------+---------------------------------+-------------------+
|
3 |
2096128 |
0 |
|
4 |
2096128 |
0 |
+-----------+---------------------------------+-------------------+
• If log buffer is almost full then increase size of log buffer
25. MySQL Cluster Connector for Java
• New Domain Object Model
Persistence API (ClusterJ) :
• Java API
• High performance, low latency
• Feature rich
Network
• JPA interface built upon this new
Java layer:
• Java Persistence API compliant
• Implemented as an OpenJPA plugin
Data Nodes
• Uses ClusterJ where possible, reverts
to JDBC for some operations
• Higher performance than JDBC
• More natural for most Java designers
• Easier Cluster adoption for web
applications
26. ClusterJPA
• Removes ClusterJ limitations:
•
•
•
•
•
Persistent classes
Relationships
Joins in queries
Lazy loading
Table and index creation from object model
• Implemented as an OpenJPA plugin
• Better JPA performance for insert, update, delete
28. Beyond 7.1: SPJ – Push Down Joins
mysqld
Data Nodes
SPJ
• A linked operation is formed by the
MySQL Server from the SQL query
and sent to the data nodes
• For a linked operation, first part of
query can be a scan but should
result in primary key lookups for the
next part
• More complex queries could be sent
as multiple linked operations
• Reduces latency and increases
throughput for complex joins
• Qualifies MySQL Cluster for new classes
of applications
mysqld
Data Nodes
• Also possible directly through NDB
API
• Up to 42x performance gain in PoC!
The existence, content and timing of future releases described here is included
for information only and may be changed at Oracles discretion.
30. MySQL Cluster Manager 1.0 Features
Automated Management
• Cluster-Wide
Management
• Process Management
• On-Line Operations
(Upgrades /
Reconfiguration)
Monitoring
• Status Monitoring &
Recovery
HA Operations
• Disk Persistence
• Configuration
Consistency
• HA Agent Operation
31. MySQL Cluster Manager
Current Development Projects
33
31
mysqld
Data
Node
Mgmt
Node
34
32
mysqld
Mgmt
Node
Data
Node
33
mysqld
31
Data
Node
mysqld
32
Mgmt
Node
34
Data
Node
•35
mysqld
Data
Node
mysqld
36
Mgmt
Node
Data
Node
• On-line add-node
mysql> add hosts --hosts=192.168.0.35,192.168.0.36 mysite;
mysql> add package --basedir=/usr/local/mysql_7_0_7 –
hosts=192.168.0.35,192.168.0.36 7.0;
mysql> add process
--processhosts=mysqld@192.168.0.33,mysqld@192.168.0.34,ndbd
@192.168.0.35,ndbd@192.168.0.36 mycluster;
mysql> start process --added mycluster;
• Restart optimizations
• Fewer nodes restarted on some parameter changes
32. • Application: Service Delivery Platform
– Roaming platform to support 7m roaming subscribers per day FIFA World Cup 2010
– Database supports AAA, routing, billing, messaging, signalling, payment processing
– MySQL Cluster 7.1 delivered 1k TPS on 1TB data with carrier-grade availability
• Key business benefits
– Local carriers to monetize new subscribers
– Users enjoy local pricing with full functionality of their home network
– Reduced deployment time by 75%
”MySQL Cluster 7.1 gave us the perfect combination of extreme levels of transaction
throughput, low latency & carrier-grade availability. We also reduced TCO by being able
to scale out on commodity server blades and eliminate costly shared storage”
- Phani Naik, Head of Technology at Pyro Group
32
33. Shopatron: eCommerce Platform
• Applications
– Ecommerce back-end, user authentication,
order data & fulfilment, payment data &
inventory tracking. Supports several
thousand queries per second
• Key business benefits
– Scale quickly and at low cost to meet
demand
– Self-healing architecture, reducing TCO
• Why MySQL?
– Low cost scalability
– High read and write throughput
– Extreme availability
“Since deploying MySQL Cluster as our eCommerce database, we have had
continuous uptime with linear scalability enabling us to exceed our most stringent SLAs”
— Sean Collier, CIO & COO, Shopatron Inc
33
34. Resources to Get Started
MySQL Cluster Quick Start Guides
http://www.mysql.com/products/database/cluster/get-started.html#quickstart
MySQL Cluster 7.1, Architecture and New Features
http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster7_architecture.php
MySQL Cluster on the Web
http://www.mysql.com/products/database/cluster/
35. The preceding is intended to outline our general
product direction. It is intended for information
purposes only, and may not be incorporated into any
contract. It is not a commitment to deliver any
material, code, or functionality, and should not be
relied upon in making purchasing decisions.
The development, release, and timing of any
features or functionality described for Oracle’s
products remains at the sole discretion of Oracle.
Design goals for MySQL Cluster: - everything we do in dev of the product is designed to enhance 1 or more of these core design goals:
High Perf, specifically write scalability: how do we deliver without app developers having to modify their apps. Other dimension is low latency, to deliver real time responsivenss
- 5 x 9s avail – handle both scheduled maintenace and failiers, so planned and unplanned downtime with less than 5 mins downtime per year
- Low TCO –acquistion and operation of the s/w, as well as optimising perf and avail on commodity h/w, so keep overall projext costs down
This slide shows the key capabilities of MySQL Cluster
Very high read/write th/put: Data is distributed across multiple nodes, so you have multi-master db with parallel architecture so perform multiple write ops concurrently, with any changes instantly available to all clients accessing the cluster. Recent tests on 4 nodes cluster using DBT2 BM – 125k op/s with average latency of 3ms
Availability, delivers 99.999% – There are no SPOFs, it is shared nothing arch
Within the Cluster, all updates are syncrhonously replicated so written to at least 2 nodes before TX commited , so if 1 node fails, up to date copy of data on another node. You can fail over typically in less than 1 sec – as there is no shared disk or lock managers to worry about. Self healing, node can auto rejoin and resynchronize with the cluster. Developers don't have to care about this in their apps - which is a massive gain
RT – indexes in memory (also data in memory or on disk) + RT extensions, all CP of in-mem data to disk happens in backround so no slow down for disk i/o. Typically 2-5 ms latency with sync replication across multiple data nodes – so you get low response time, but also predictable latency.
Linear scale – scale horizontaly, vertically -also scale on-line with no downtime to app
Core database is open source, multi- platform and multi-access methods
So, look at how we deliver against those goals
- distributed hash table backed by an ACID relational model
- As name suggests, MySQL Cluster comprises multiple nodes which act as a single system, implemented as shared-nothing architecture, scale out on commodity hardware
- implemented as a pluggable storage engine for the MySQL Server, like InnoDB or MyISAM – so gives you ease-of-use and ubiquity of MySQL, with additional direct access via embedded APIs, so can eliminate SQL transofrmations completely and manage data directly from your app – C++, LDAP, HTTP, most recently, Java and OpenJPA. This boosts perf also enables devs to work in their prefeered dev environments accelate dev cycles.
- automatic or user configurable data partitioning across nodes, MySQL Cluster handles this, no need to partition within the apps
- synchronous data redundancy across nodes, using 2PC. Can be turned off, but default and recommendation is for it to be on
- Because shared nothingh & sync repli, we get sub-second fail-over. System also designed for self-healing recovery, so a fail;ed node will automatically rejoin and re-sync the cluster
- geographic replication, for DR
- data stored in main-memory or on disk (configurable per-column)
- logging and check pointing of in-memory data to disk, so durability – perfomed as a background process, so eliminate I/O waits
- online operations (i.e. add-nodes, schema updates, maintenance, etc), no downtime to apps or clients
So, look at how we deliver against those goals
- distributed hash table backed by an ACID relational model
- As name suggests, MySQL Cluster comprises multiple nodes which act as a single system, implemented as shared-nothing architecture, scale out on commodity hardware
- implemented as a pluggable storage engine for the MySQL Server, like InnoDB or MyISAM – so gives you ease-of-use and ubiquity of MySQL, with additional direct access via embedded APIs, so can eliminate SQL transofrmations completely and manage data directly from your app – C++, LDAP, HTTP, most recently, Java and OpenJPA. This boosts perf also enables devs to work in their prefeered dev environments accelate dev cycles.
- automatic or user configurable data partitioning across nodes, MySQL Cluster handles this, no need to partition within the apps
- synchronous data redundancy across nodes, using 2PC. Can be turned off, but default and recommendation is for it to be on
- Because shared nothingh & sync repli, we get sub-second fail-over. System also designed for self-healing recovery, so a fail;ed node will automatically rejoin and re-sync the cluster
- geographic replication, for DR
- data stored in main-memory or on disk (configurable per-column)
- logging and check pointing of in-memory data to disk, so durability – perfomed as a background process, so eliminate I/O waits
- online operations (i.e. add-nodes, schema updates, maintenance, etc), no downtime to apps or clients
Look at types of workload Cluster deployed into and the users
Cluster technology originally developed bu E///, used purely as an in-mem, carrier-grade db embedded in network equpt – typically switches. Acquired by MySQL in 2003. Acquired not just the technology, but also the engineering team who have contined to develop the product rapidy in subsequent years, ie added disk based tables, added SQL i/f, automtic node recovery, add Geo-Repl, open sourced.
Very strong in telecoms in Sub DBs (HLR/HSS)– truly mission critical apps, also in app servers, VAS
In web workloads, used a lot for session stores, eCommerce, Mgmt of user profiles
Here we show the architectire of MySQL Cluster
3 core elements
Data Nodes: handle actual storage and access to data – data is distributed across the data nodes – automatically partitioned, replication, failover and self healing. Don't need complex logic in the application – data nodes handle all of that
Application Nodes – provide connectors to the data. Most common use case is to connect via MySQL Server for a std SQL i/f. Also have a series of native interfaces embed directly into apps for direct access– bypasses SQL – gives highest performance, lowest latency: C++ API, Java API and OpenJPA plug-in for Object/Relational Mapping. Can also access via LDAP servers and HTTP with an Apache module
Mgmt Nodes: used at start-up, used to add nodes, to reconfigure the cluster, arbitration if there is a network failure – avoid split brain as determine which side of the cluster assumes ownership of servicing requests
So, its pretty simple – always have at least 2 copies of your data held in the data nodes, and accessed via series of app nodes
MySQL Cluster Manager is implemented as a set of peer-level agents; one running on each host.
DBA uses the standard MySQL client to connect to any one of these agents; the chosen agent will then cooperate with all of the other agents to perform the requested operation.
If an agent fails then just restart the process and it will be bought back up to date.
Management responsibilities
Starting, stopping & restarting nodes
Configuration changes
Upgrades
Host & Node status reporting
Recovering failed nodes
The example here shows the step to install, configure and run MySQL Cluster using MCM; don’t worry about the exact commands we have plenty of training and reference material.
Included this to show how what used to be a complex operation is made far simpler and less prone to human error. Without using MySQL Cluster Manager, there would be dozens of commands to run to upgrade even a simple deployment – make a mistake and you may have a temporary loss of service.
Which MCM this is reduced to a single command which goes away and restarts each process with the right software in the right sequence.
Stop by the MySQL Cluster demo-pod to see this in action.
Partitioning – 1 of the keys to scalability – partitioning automatically in Cluster, no need to implement sharding at application level – so keeps things very simple
Unlike most other MySQL storage engines, the data for MySQL Cluster tables is not stored in the MySQL Server – instead it is partitioned across a pool of data nodes as shown in the chart. The rows for a table are divided into partitions with each data node holding the primary fragment for one partition and a secondary (backup) fragment for another. By default, partitioning is based on a hashing of the primary key for a table.
To get the best performance, use a common component of the primary key (e.g. SessionID) across all of the tables that a transaction will access -> whole transaction can be processed on a single data node -> less messaging required.
By using this partitioning approach, we can distribute multiple copies of the data across multiple nodes, and scale perf very effecitvely, and give HA.
When a change is made, a 2-phase commit protocol is used to ensure that the change is simultaneously applied to both data nodes in the node group by the time the transaction is committed.
If a data node fails or is being restarted for maintenance reasons then the remaining data node processes all reads/writes and then updates the other data node when it returns to the Cluster.
As the replication is synchronous, the latency, throughput and reliability of the network interconnect is important.
A heart beat message is passed round all of the data nodes in the Cluster in a round-robin fashion. If no heartbeats are received for 3x the configurable heart-beat interval then the node’s right-hand neighbour initiates a protocol to remove the failed node from the Cluster.
A more complex scenario would be where a subset of the nodes became isolated from the others; part of the protocol is to check that any community of nodes in communication with each other represents the one and only viable subset of the Cluster: at least one data node from each node group and if there is the possibility of a second community, refer to the arbitrator to discover is should stay up or not.
When the failed node is brought back into service (manual or automated) it rejoins the Cluster and is automatically brought back up to date using the set of changes recorded by its peer in the node group.
To further support continuous operation, MySQL Cluster has the ability to add nodes on-line to a running cluster by automatically re-partitioning data as new node groups are added, ensuring the cluster maintains continuous operation.
Can also add new MySQL servers with no loss of service.
MySQL Cluster also allows on-line updates to a live database schema, in addition to upgrades and maintenance to the underlying hardware & software infrastructure.
Cluster backups are in-service.
On-line schema changes: add-column, add-index, drop-index
Data nodes within the cluster replicate synchronously with each other – almost always in the same data center.
Can also have asynchronous replication to one or remote Clusters. Unlike other MySQL storage engine Cluster supports active-active replication with conflict detection and resolution (does require some work from the application).
Can also replicate to databases that are using different storage engines (for example to allow complex report generation).
When we look at perf:
Ran industry std DBT2 test on the latest major release of MySQL Cluster: 7.0
2-4 socket commodity h/w
4 x data nodes, scaled performance by adding more MySQL Server instances / connections
Sustain 250k tpm. Each Tx = 30 operations, 125k op/s, average latency of 3ms – with synchronous replication
Data Nodes
Sun Fire x4450s
SQL Nodes
Sun Fire x4600s & x4450s
OpenSolaris
Gigabit Ethernet
We also compared Cluster 7 perf and scalability vs the previous release, and saw over 4x higher throughput on the same h/w
Recently benchmarked MySQL Cluster against the MEMORY Storage and was able to perform nearly 30x more transactions per second on a single node running a READ / WRITE Sysbench test suite. Also had checkpointing and logging enabled for Cluster so providing data durability, something MEMORY can’t do – if we turned c-pointing off, perf of Cluster would have been even higher
Performance of the MEMORY storage engine for READ / WRITE workloads is severely limited due to table locking when processing updates. For the Sysbench workload, WRITE operations comprise 30% of the total mix of queries so have almost no scalability at all beyond a single thread when using the MEMORY storage engine.
When running Sysbench as a purely read-only workload, scalability in the MEMORY storage engine was significantly improved as table locks are eliminated. When measuring performance up to 128 client connections, MEMORY delivered an average of 2.8x higher throughput than MySQL Cluster. This type of performance will only be seen for those workloads which comprise absolutely no UPDATE operations. Also unlike MEMORY, scale Cluster across multiple nodes to achieve perf requirements
END++++++++++++++++++++++++++++++++++++++++++++++++++
Benchmark Description
The Sysbench benchmark was run a single server, configured as follows:
4-socket server equipped with 6-core 2.8GHz x86 processors.
64GB RAM.
2 x 7,200 RPM Hard Disk Drives configured as RAID 0.
Fedora 12 Linux Operating System.
Single MySQL Server instance.
MySQL Cluster was configured with a single data node, with check-pointing and logging enabled.
The Sysbench transactions consist of a set of queries with a mix of reads, updates, deletes and inserts. The reads comprise access by both primary key and by a number of range scans. Each transaction performs between 14 and 21 queries. For the READ/WRITE benchmark, around 30% of the queries are UPDATE operations.
UC in April, we announced GA release of Cluster 7.1
Focus of this release is improving performance and reducing cost of operations
Performance relates to Java services – delivered MySQL Cluster Connector for Java, feature rich ORM solution providing a native Java interface embedded directly into apps and an OpenJPA plug-in to directly access data within the cluster from a Java app, without going via conventional JDBC / SQL path – so you get higher perf, low latency – and a more natural environment for Java persistence
Cost of operations:, released NDBINFO: provides monitoring of the cluster access to real-time status info as series of SQL views (always been a bit of a black box, lot of trawling through logs to see what is happening) – allows admins to Monitor & optimize cluster performance & availability
Faster restart via better caching • better internal communication within the Cluster which is delivering 20x speed up on complex, write-intensive workloads
Also released MySQL Cluster manager: this is part of the commercial edition of MySQL Cluster only. Automates and simplifies cluster management, reduces load and complexity for DBAs
Rather than having to wade through logs or know secret developer tools, you can now get access to what’s going on within the data nodes using the familiar SQL interface.
Examples include index and data memory usage, buffer occupancy, numbers of each type of operation performed on each data nodes, status of nodes and inter-node connections.
As the interface is SQL you can slice and dice all of this information to get exactly the output you need.
Probably simplest to step through a couple of examples...
Prior to MySQL Cluster 7.1 Java applications had a choice between using JDBC or writing their own JNI wrapper around the C++ NDB API:
JDBC familiar to Java designers but it is relational rather than dealing in objects. Also inefficient as Java app has to convert to relational view, JDBC then converts to SQL for the MySQL Server and the MySQL Server converts it to NDB API calls: adds latency & complexity. Can add JPA as a layer on top so that apps don’t have to perform the ORM but that is an extra source of latency.
NDB API: Best possible performance and lowest latency. Complex for Java developers to use.
The 2 new access methods allow application to work purely with objects and also cut out the SQL middle-man to get better performance.
ClusterJ is our own version of an ORM; can also use ClusterJPA as a plugin for OpenJPA to allow it to use ClusterJ whenever possible for better performance.
Can of course use Hibernate or TopLink through the JDBC path.
Y-axis is the CPU time consumed for each test, on X-axis show 5 different access methods for different classes of operations.
For the best apples-to-apples comparison compare the yellow and green bars. Green is OpenJPA using traditional JDBC path, yellow is when it is instead going the ClusterJ route.
In Cluster today, a join is implemented as a nested loop join within the MySQL Server. The data is not held there and so the MySQL server has to keep on making trips to the data nodes to read the next piece of data for the join. This works but there is a clear performance impact which makes Cluster unsuitable for a significant number of applications.
With SPJ the MySQL Server can send many of these join operations down to the data nodes which then calculate the results; removing a huge number of round trips and so reduce latency.
If the query is more complex then the MySQL Server may break it down into multiple requests.
This does not help every type of join but for those it does the results can be spectacular – e.g. 42x improvement has been observed; in some cases you may need to optimise your schema and/or queries to see the benefit.
NDBINFO exposes information on what’s happening within the data nodes via SQL, therefore build rules and graphs first time enables degree of data node monitoring from MEM
Alarms generate SNMP traps. Exposed via Mysqld acting as a proxy
Can’t see data nodes just the data they expose through NDBINFO.
MySQL Enterprise Monitor 2.3 is aiming to deliver a Cluster advisor (set of rules that can generate alerts) as well as a set of graphs. No reason why the end user couldn’t add their own (for example to graph the number of table scans).
MySQL Cluster Manager 1.0 went GA in April together with Cluster 7.1.
It is very much focussed on making management operations simpler, faster and safer to perform.
Without MCM, the DBA is responsible for editing configuration files, starting, stopping & restarting nodes in the correct order – make a mistake and service is lost.
With MCM you manage the Cluster through a single command-line-interface. No need to edit and duplicate configuration files across the Cluster. Complex operations are reduced from dozens of commands to a single command.
MCM also extends the HA of MySQL Cluster in that it can be configured such that if any node fails (MySQL Server, management node or data node) then it can automatically be restarted. Without Cluster Manager this is limited to data nodes.
Development work continues for MCM; one of the main features targeted for the next release is the automation of on-line add-node.
This is possible without MCM but involves a lot more steps.
Again, stop by the demo-pod to see this in action.
