Mysql Cluster Carrier Grade Edition: Introduction

MySQL Cluster Carrier Grade Edition: Introduction

Oracle Corporation Japan , MySQL Global Business Unit Master Principal Solutions Specialist | APAC & Japan, Alexander Yu 2011/10/28 Please Read

The following 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.

• Intro: MySQL Cluster Real-time Database • MySQL Cluster 7.2 DMR • API Flexibility: SQL & NoSQL! • MySQL Cluster Manager • Q & A

8X DATA GROWTH IN 5 YRS 750M USERS 70+ NEW DOMAINS EVERY 60 SECONDS 20M APPS PER DAY 40% DATA GROWTH PER YEAR 600 NEW VIDEOS EVERY 60 SECONDS

100K TWEETS PER MINUTE $1TR BY 2014

$700BN IN 2011

5.3BN MOBILE SUBS IN 2010 (78% PENETRATION) 370K CALL MINUTES 13K iPHONE APPS EVERY 60 SECONDS DOWNLOADED PER MINUTE

Requirement MySQL Replication Heartbeat + DRBD Oracle VM Template MySQL Cluster Availability All Supported by MySQL All Supported by MySQL Platform Support Linux Oracle Linux Server Cluster Depends on Connector and Automated IP Failover No Yes Yes Configuration Automated Database No Yes Yes Yes Failover Automatic Data No Yes N/A - Shared Storage Yes Resynchronization Configuration Dependent, 60 Configuration Dependent, 60 Typical Failover Time User / Script Dependent 1 Second and Less seconds and Above seconds and Above No, Asynchronous and Semi- Synchronous Replication Yes N/A - Shared Storage Yes Synchronous Geographic Redundancy Yes Yes, via MySQL Replication Yes, via MySQL Replication Yes, via MySQL Replication Support Scalability

One Active (primary), one One Active (primary), one Number of Nodes One Master, Multiple Slaves 255 Passive (secondary) Node Passive (secondary) Node

Reads, via MySQL Reads, via MySQL Reads, via MySQL Built-in Load Balancing Yes, Reads and Writes Replication Replication Replication & During Failover

Read-Intensive Workloads Yes Yes Yes Yes

Yes, via Application-Level Yes, via Application-Level Yes, via Application-Level Write-Intensive Workloads Sharding to Multiple Sharding to Multiple Yes, via Auto-Sharding Sharding Active/Passive Pairs Active/Passive Pairs Scale On-Line (add nodes, No No No Yes repartition, etc.)

• Web – eCommerce – User Profile Management – Session Management & Caching – Content Management – On-line Gaming • Telecoms – Subscriber Databases (HLR/HSS) – Service Delivery Platforms – VoIP, IPTV & VoD – Mobile Content Delivery – IP Management – Payment Gateways

http://www.mysql.com/customers/cluster/

HLR / HSS Location

Updates

AuC, Call

Pre & Post Paid Routing, Billing

• Massive volumes of write traffic • <3ms database response Billing, AuC, VLR • Downtime & lost transactions = lost $

MySQL Cluster in Action: http://bit.ly/oRI5tF

• Integrated Service Provider platform – eCommerce – Payment processing – Fulfillment • Supports 1k+ manufacturers & 18k retail partners • Requirements – Scaling, On-Demand – HA: failures & on-line upgrades – High batch & real time loads – Low TCO: capex and opex

http://mysql.com/customers/view/?id=1080

• US Navy aircraft carriers • Consolidated flight operations management system – Maintenance records – Fuel loads – Weather conditions – Flight deck plans • Requirements – No Single Points of Failure – Complete redundancy – Small footprint, harsh environment – 4 x MySQL Cluster nodes, Linux and Windows

1,000 Downloads per Day

MySQL Cluster database supports 7 million roaming subscribers per day

Migrated from a Microsoft platform with SQL Server

MySQL Cluster selected as a result of high transactional throughput, low latency, “MySQL Cluster 7.1 gave us the carrier-grade availability and low cost perfect combination of extreme levels of transaction throughput, low Pyro InRoam SDP is an intelligent latency & carrier-grade availability, application enabling subscribers to communicate with ease across borders while reducing TCO” Phani Naik, Pyro Group

• ACID Compliant Relational Database • SQL & NoSQL interfaces • Write-Scalable & Real-Time • Distributed, multi-master, auto-sharding • Optimized in-memory structures & indices • Near-linear scalability, transparent load balancing • 99.999% Availability • Shared-nothing, integrated clustering, sub-second recovery • Local & geographic replication, on-line operations • Low Barriers to Entry • Open-source, elastic, multiple APIs, management and monitoring tools • Commodity hardware

Clients

MySQL Cluster Application Nodes

MGM Client

NDB API (C++) MGM API (C)

NDB NDB API NDB NDB API

MGM Node MGM Node MySQL Cluster Data Nodes

• Transparent to the application • No need for application-layer sharding logic • Partitioning based on hashing the primary key or user defined key • Each node stores primary fragment for 1 partition and back-up fragment for another • Transparency maintained during failover, upgrades and scale-out • No need to limit application to single-shard transactions

Copyright© 2011, Oracle. All rights reserved. Automatic Data Partitioning Transparent Load Balancing 4 Partitions * 2 Replicas = 8 Fragments Table T1 Data Node 1 F1 F3 Px Partition P1 Node Group 1 Data Node 2 P2 F3 F1

P3 Data Node 3

F2 F4 P4

Node Group 2 Fx Primary Fragment Data Node 4

- Node groups are created automatically F4 F2 - # of groups = # of data nodes / # of replicas Fx Secondary Fragment (fragment replica)

4.3M QPS

• 8 Intel servers • Dual-6-core CPUs @2.93 GHz • 24GB RAM • 2 Data Nodes per server • flexAsync benchmark • 16 parallel threads, each issuing 256 simultaneous transactions • Read / Write 100KB attribute • Access via NDB API

Copyright© 2011, Oracle. All rights reserved. MySQL Cluster: Extreme Resilience •Shared-nothing distributed database with no SPOF: JDBC (Java) NDB API (C++) High Read & Write Performance & 99.999% uptime ClusterJ (Java) OpenJPA (Java) Clients PHP/P*/ODBC OpenLDAP

MySQL Cluster Application Nodes SQL Nodes

ClusterJ MGM Client

NDB API (C++) MGM API (C)

NDB NDB API NDB NDB API

MGM Node MGM Node MySQL Cluster Data Nodes

P3 Data Node 3

F2 F4 P4

Node Group 2 Fx Primary Fragment Data Node 4 As long as one data node in each node group is running we have a complete F4 F2 Fx Secondary Fragment (fragment replica) copy of the data

• Scale the cluster for additional throughput or capacity –Data and SQL Nodes –Automatic repartition of tables • Recover failed nodes • Rolling –Upgrade / patch servers & OS –Upgrade / patch MySQL Cluster • Backup • Schema changes

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 on-line • Upgrade hardware & software with no downtime • Perform back-ups on-line

CREATE OFFLINE INDEX b ON t1(b); • Fully online – transaction response Query OK, 1356 rows affected (2.20 sec)‏ times unchanged • Add and remove indexes, add new columns and tables DROP OFFLINE INDEX b ON t1; Query OK, 1356 rows affected (2.03 sec)‏ • No temporary table creation • No recreation of data or deletion required CREATE ONLINE INDEX b ON t1(b); • Faster and better performing table Query OK, 0 rows affected (0.58 sec)‏ maintenance operations • Less memory and disk requirements DROP ONLINE INDEX b ON t1; Query OK, 0 rows affected (0.46 sec)‏

ALTER ONLINE TABLE t1 ADD COLUMN d INT; Query OK, 0 rows affected (0.36 sec)

• Online Backup for the Data only – Data dump/backup for each Data Node – Schema dump via mysqldump • What to configure – Backup path • Choose local disk, SAN or NAS – Backup files can then be picked up by external backup managers – Compressed backup • Space optimization/saving • Backup Initiation – Schema dump initiated via mysql on a SQL Node – Backup snapshot of Data at end of backup or start of backup via ndb_mgm • Backup command – $ ndb_mgm -e “START BACKUP SNAPSHOTSTART" • Restore command – $ ndb_restore -c „192.168.10.10‟ -n 2 -b 1 -p 1 -m (once!) – $ ndb_restore -c „192.168.10.10‟ -n 2 -b 1 -p 1 -r – Restore data command issued for each Data Node – Point-In-Time Recovery • Need to enable Binary-Logging on MySQL Server • Replay changes up-to a time using binary logs

• Multiple replication topologies available • Master - Master (Bi-directional) – Conflict detection and resolution • Master - Slave(s) • Circular • etc

Copyright© 2011, Oracle. All rights reserved. • Synchronous (two phase commit) replication within a Cluster node group for HA Cluster 1 Cluster 2 • Bi-Direction asynchronous replication to remote Cluster for geographic redundancy • Asynchronous replication to non- Cluster databases for specialised activities such as report generation MyISAM MyISAM InnoDB • Mix and match replication types

Synchronous replication

Asynchronous replication

• A SQL Node/MySQL Server is responsible for the replication – NDB Binlog injector thread – Subscribes to events in MySQL Cluster • Injects rows into the Binlog – All changes in the cluster – Row-based replication • Two replication channels – No single point of failure

• Node 2 – One node from each node group? => No – Shutdown

Network split/shutdown

Data Node 1 Data Node 2

Data Node 3 Data Node 4

• Disk Data Tables – Not enough memory to store all data – Non-Indexed columns are stored on disk • Tablespace • A disk data based table stores its data in a tablespace • Contains one more data files • Log File Groups – In order to facilitate rollback – Undo data in one or more undo log files

• Data Nodes – ndbd/ndbdmt daemon (single threaded/multithreaded) – Data storage – Transaction Coordination • SQL Node – mysqld daemon – provides SQL access to dataset – Handles geographical replication • Management Nodes – ndb_mgmd daemon – cluster configuration, cluster log, default arbitrator • Management Clients – ndb_mgm, cluster command line client (interactive/non-interactive) – start/stop backups, node restarts, filter cluster log. – mysql, CLI for accesing the SQL Node • API Nodes/Applications – Via SQL Node (JDBC/ODBC) – Direct APIs (C++/Java apps) – LDAP, Web Services • MySQL Cluster Manager Agent – mcmd agent daemon – mysql, CLI for agent cluster management commands

• Example 1: Check memory usage/availability

mysql> select * from ndbinfo.memoryusage; +------+------+------+------+------+------+ | node_id | memory_type | used | used_pages | total | total_pages | +------+------+------+------+------+------+ | 3 | Data memory | 917504 | 28 | 104857600 | 3200 | | 3 | Index memory | 221184 | 27 | 11010048 | 1344 | | 4 | Data memory | 917504 | 28 | 104857600 | 3200 | | 4 | Index memory | 221184 | 27 | 11010048 | 1344 | +------+------+------+------+------+------+

• 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

• Example 2: Check how many table scans performed on each data node since the last restart

• Perform Complex Queries across Shards – JOINs pushed down to data nodes mysqld Data Nodes – Executed in parallel A – Returns single result set to MySQL Q • Opens Up New Use-Cases L – Real-time analytics – Recommendations engines – Analyze click-streams

mysqld

Data Nodes DON’T COMPROMISE FUNCTIONALITY TO SCALE-OUT !!

MySQL Server

Data Data Node1 Node2

• 70x Speedup for real customer JOIN across 7.2 7.2 = 1.26s 11 tables analyzed= • Try Analyze tables to optimize results 65.3s • mysql> ANALYZE TABLE ;

7.1 = 87.23s

• Persistent, Scalable, HA Back-End to memcached – No application changes: re-uses standard memcached clients & libraries –Faster Cloud Deployments/Integration • Consolidate Caching & Database Tiers –Eliminate cache invalidation –Simpler re-use of data across services –Improved service levels • Flexible Deployment New –Schema or Schema-less storage NoSQL Access

• Exploit Latest Server / Storage Engine Developments within a Single Application –InnoDB: Foreign Keys, XA Transactions, Large Rows –MySQL Cluster: HA, High Write Rates, Real- Time • Reduces Complexity, Simplifies DevOps • MySQL 5.5 –3x higher performance –Improved partitioning, diagnostics, availability, etc.

• Replicating complete clusters across data centers – DR & data locality – No passive resources • Simplified Active / Active Replication – Eliminates requirement for application & schema changes Geographic – Transaction-level rollback Replication

• Split data nodes & node groups across data centers ⁃ Synchronous replication & auto- failover between sites Data Node 1 ⁃ Improved heartbeating to handle network Data Node 2 partitions Synchronous • Extends Disaster Recovery Options Data Node 3 Replication • More Resilient Cloud Deployments Data Node 4 • Active/Active with no need for conflict handling

Clients

JDBC / ODBC PHP / PERL Python / Ruby Native memcached HTTP/REST

NDB API

Data Nodes Mix & •SQL: Complex, relational queries Match •HTTP / memcached: Key-Value web services •Java: Enterprise Apps •NDB API: Real-time services

Mix & Match! Same data accessed simultaneously through SQL & NoSQL interfaces

•NoSQL – Multiple ways to bypass SQL, and maximize performance: •NDB API. C++ for highest performance, lowest latency •Cluster/J for optimized access in Java •NEW! Memcached. Use all your existing clients/applications

Clients • Application embeds the NDB API C++ interface library • NDB API make intelligent decision (where possible) about which data node to send

Applications with embedded NDB API queries to Library – With a little planning in the schema design, achieve linear scalability • Used by all of the other application nodes (MySQL, LDAP, ClusterJ,…) • Best possible performance but requires > development skill • Favourite API for real-time network applications • Foundation for all interfaces

MySQL Cluster Data Nodes

• Memcached is a distributed memory based hash-key/value store with no persistence to disk Memcached protocol • NoSQL, simple API, popular with developers • MySQL Cluster already provides scalable, in- memory performance with NoSQL (hashed) access as well as persistence • Provide the Memcached API but map to NDB API calls • Writes-in-place, so no need to invalidate cache • Simplifies architecture as caching & database integrated into 1 tier • Access data from existing relational tables

•Flexible: Simple: set maidenhead 0 0 3 • Deployment options SL6 • Multiple Clusters STORED • Simultaneous SQL Access • Can still cache in Memcached server get maidenhead • Flat key-value store or map to multiple VALUE maidenhead 0 3 tables/columns SL6 END

key value

Application view

SQL view key value

generic table

The existence, content and timing of future releases described here is included for information only and may be changed at Oracles discretion. October 3rd, 2011 Copyright© 2011, Oracle. All rights reserved. Cluster & Memcached - Configured Schema

key value

Application view

SQL view prefix key value

Config tables map.zip

• Rich set of existing MySQL connectors • JPA interface built upon this new Java layer: exist but performance worse than NDB API ⁃Java Persistence API compliant • New Domain Object Model Persistence API • Implemented as an OpenJPA plugin (ClusterJ) : ⁃Uses ClusterJ where possible, reverts to JDBC for some ⁃Java API operations ⁃High performance, low latency ⁃Higher performance than JDBC ⁃Feature rich ⁃More natural for most Java designers ⁃Easier Cluster adoption for web applications

• High Performance, Easy to Use • In the style of Hibernate / JPA / JDO • Domain Object Model DataMapper pattern –Data is represented as domain objects –Domain objects are separate from business logic –Domain objects are mapped to database tables • Built on ndbjtie –JNI adapter –integral part of MySQL Cluster –Straight mapping of MySQL Cluster API (a.k.a NDB API) to Java • Does not support relationships –Look at JDO / JPA for these modelling patterns

Configuration Session properties Factory • SessionFactory –One per Cluster per JVM • Session –Instance per user; represents a Session & Session & Session & Cluster connection Transaction Transaction Transaction • Transaction –Instance per Session • Query –Multiple instances per Session Domain Domain Domain Domain Domain Domain Object Object Object Object Object Object Domain Domain Domain Object Domain Domain Domain Object Object Object Object Object

Annotated interface

// Create a session (connection to the database) SessionFactory factory = ClusterJHelper.getSessionFactory(props); Session session = factory.getSession();

// Create and initialise an Employee Employee newEmployee = session.newInstance(Employee.class); newEmployee.setId(988); newEmployee.setFirst("John"); newEmployee.setLast("Jones"); newEmployee.setStarted("1 February 2009"); newEmployee.setDepartment(666);

// Write the Employee to the database session.persist(newEmployee);

// Fetch the Employee from the database Employee theEmployee = session.find(Employee.class, 988);

// Make some changes to the Employee & write back to the database theEmployee.setDepartment(777); theEmployee.setCity("London"); session.updatePersistent(theEmployee);

// Retrieve the set all of Employees in department 777 QueryBuilder builder = session.getQueryBuilder(); QueryDomainType domain = builder.createQueryDefinition(Employee.class); domain.where(domain.get("department").equal(domain.param("department"))); Query query = session.createQuery(domain); query.setParameter("department",777); List results = query.getResultList();

• 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,

• @Entity(name = "department") mysql> describe department;

• public class Department { +------+------+------+-----+------+------+ private int Id; | Field | Type | Null | Key | Default | Extra | private String Site; +------+------+------+-----+------+------+ | id | int(11) | NO | PRI | NULL | | • public Department(){} | location | varchar(255) | YES | | NULL | | • +------+------+------+-----+------+------+ @Id public int getId() {return Id;} public void setId(int id) {Id=id;}

• @Column(name="location") public String getSite() {return Site;}

public void setSite(String site) Note that OpenJPA will create this table if it doesn’t already exist but user {Site=site;} needs to change the storage engine to NDB: mysql> ALTER TABLE department=ndb; • }

EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("clusterdb"); EntityManager em = entityManagerFactory.createEntityManager(); EntityTransaction userTransaction = em.getTransaction(); userTransaction.begin(); Department dept = new Department(); dept.setId(101); dept.setSite(“London”); em.persist(dept); userTransaction.commit(); userTransaction.begin(); Department theDepartment = em.find(Department.class, 101); theDepartment.setSite(“Edinburgh”); userTransaction.commit(); em.close(); entityManagerFactory.close();

Delivered as part of MySQL Cluster CGE 7.1

Before MySQL Cluster Manager With MySQL Cluster Manager •1 x preliminary check of cluster state upgrade cluster --package=7.1 mycluster; •8 x ssh commands per server •8 x per-process stop commands •4 x scp of configuration files (2 x mgmd & 2 x Total: 1 Command - mysqld) Unattended Operation •8 x per-process start commands •8 x checks for started and re-joined processes • Results •8 x process completion verifications • Reduces the overhead and complexity of •1 x verify completion of the whole cluster. managing database clusters •Excludes manual editing of each configuration file. • Reduces the risk of downtime resulting from Total: 46 commands - administrator error 2.5 hours of attended operation • Automates best practices in database cluster management

• Site: the set of physical hosts which are to run Cluster processes to be managed by MySQL Cluster Manager. A site can include 1 or more Site clusters. • Cluster: represents a MySQL Cluster Host Host Host Host deployment. A Cluster contains 1 or more Cluster processes running on 1 or more hosts

• Host: Physical machine, running the MySQL

Process Process Process

Process Cluster Manager agent

Process Process Process

Cluster • Agent: The MySQL Cluster Manager process running on each host

• Process: an individual MySQL Cluster node;

Process Process Process one of: ndb_mgmd, ndbd, ndbmtd, mysqld &

agent agent agent agent ndbapi* • Package: A copy of a MySQL Cluster installation directory as downloaded from mysql.com, stored on each host *ndbapi is a special case, representing a slot for an external application process to connect to the cluster using the NDB API

1. Download MCM from edelivery.oracle.com: • Package including Cluster 2. Unzip 3. Run agent, define, create & start Cluster! – $> bin¥mcmd –bootstrap – MySQL Cluster Manager 1.1.2 started – Connect to MySQL Cluster Manager by running "D:¥Andrew¥Documents¥MySQL¥mcm¥bin¥mcm" -a NOVA:1862 – Configuring default cluster 'mycluster'... – Starting default cluster 'mycluster'... – Cluster 'mycluster' started successfully – ndb_mgmd NOVA:1186 – ndbd NOVA – ndbd NOVA – mysqld NOVA:3306 – mysqld NOVA:3307 – ndbapi * – Connect to the database by running "D:¥Andrew¥Documents¥MySQL¥mcm¥cluster¥bin¥mysql" -h NOVA -P 3306 -u root 4. Connect to Cluster & start using database • http://www.clusterdb.com/mysql-cluster/mysql-cluster-manager-1-1-2-creating-a-cluster-is-now-trivial

mysql 1.Define the site: client –Mysql> create site --hosts=192.168.0.10,192.168.0.11, -> 192.168.0.12,192.168.0.13 mysite; 2.Expand the MySQL Cluster tar-ball(s) from mysql.com to known directory 7. mysqld 8. mysqld 3.Define the package(s): 1. ndb_mgmd 2. ndb_mgmd •Mysql> add package --basedir=/usr/local/mysql_7_1_15 7.1; Mysql> add package --basedir=/usr/local/mysql_7_2_1 7.2; agent agent • Note that the basedir should match the directory used

192.168.0.10 192.168.0.11 in Step 2. 4.Create the Cluster 3. ndbd 4. ndbd –Mysql> create cluster --package=7.1 -> [email protected],[email protected], 5. ndbd 6. ndbd -> [email protected],[email protected], [email protected], -> [email protected],[email protected],[email protected] agent agent -> mycluster; • This is where you define what nodes/processes make 192.168.0.12 192.168.0.13 up the Cluster and where they should run 5.Start the Cluster: –Mysql> start cluster mycluster;

mysql client

• Upgrade from MySQL Cluster 7.1.15 to 7.2.1: 7. mysqld 8. mysqld mysql> upgrade cluster --package=7.2 mycluster; 1. ndb_mgmd 2. ndb_mgmd

agent agent • Automatically upgrades each node and restarts the process – in the correct order to

192.168.0.10 192.168.0.11 avoid any loss of service • Without MySQL Cluster Manager, the

3. ndbd 4. ndbd administrator must stop each process in turn, start the process with the new version and wait 5. ndbd 6. ndbd for the node to restart before moving onto the agent agent next one

192.168.0.12 192.168.0.13

mysql client • Request the status of the Cluster processes –mysql> show status --process mycluster; –+------+------+------+------+------+ | Id | Process | Host | Status | Nodegroup | +------+------+------+------+------+ 7. mysqld 8. mysqld | 1 | ndb_mgmd | 192.168.0.10 | running | | | 2 | ndb_mgmd | 192.168.0.11 | running | | 1. ndb_mgmd 2. ndb_mgmd | 3 | ndbd | 192.168.0.12 | running | 0 | | 4 | ndbd | 192.168.0.13 | running | 0 | agent agent | 5 | ndbd | 192.168.0.12 | running | 1 | | 6 | ndbd | 192.168.0.13 | running | 1 | | 7 | mysqld | 192.168.0.10 | running | | 192.168.0.10 192.168.0.11 | 8 | mysqld | 192.168.0.11 | running | | +------+------+------+------+------+ • Get the status of the hosts & agents 3. ndbd 4. ndbd –mysql> list hosts mysite;

5. ndbd 6. ndbd –+------+------+------+ | Host | Status | Version | +------+------+------+ agent agent | 192.168.0.10 | Available | 1.0.1 | | 192.168.0.11 | Available | 1.0.1 | | 192.168.0.12 | Available | 1.0.1 | 192.168.0.12 192.168.0.13 | 192.168.0.13 | Available | 1.0.1 | +------+------+------+

• Service is maintained for all Cluster processes (i.e., automatically restart process)

7. mysqld 8. mysqld • Without MySQL Cluster Manager, an angel process would recreate failed ndbd processes 1. ndb_mgmd 2. ndb_mgmd but not mysqld or ndb_mgmd processes agent agent • Cluster continues to function if one or more agents fail or is stopped (e.g. To upgrade it) 192.168.0.10 192.168.0.11 – To restore management functions, the agent should be restarted 3. ndbd 4. ndbd

5. ndbd 6. ndbd

agent agent

192.168.0.12 192.168.0.13

• 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_1_15 – hosts=192.168.0.35,192.168.0.36 7.2; – mysql> add process -- [email protected],[email protected],[email protected] 68.0.35,[email protected] mycluster; – mysql> start process --added mycluster; • Restart optimizations • Fewer nodes restarted on some parameter changes

MySQL Cluster on the web www.mysql.com/cluster/

Evaluate MySQL Cluster 7.2 Quick Start Guides Download Today Linux, Solaris, http://dev.mysql.com/dow Windows nloads/cluster/ http://www.mysql.com/prod ucts/cluster/get- started.html#quickstart http://labs.mysql.com (memcached)

Session Management Webinar: http://tinyurl.com/3dmtf9r

• MySQL Enterprise • MySQL Database 5.5 Backup 3.6 • MySQL Enterprise Backup 3.5 • Oracle VM Template • MySQL Enterprise Monitor 2.3 for MySQL Enterprise Edition • MySQL Cluster Manager 1.1 All GA! GA! • MySQL Workbench 5.2 MySQL Database 5.6 GA! MySQL Cluster 7.2 DMR* •MySQL Enterprise Monitor 2.2 •MySQL Cluster 7.1 and MySQL Labs! (“early and often”) • MySQL Cluster Manager 1.0 All GA! A Better MySQL *Development Milestone Release

Q2 CY2010 Q3 CY2010 Q4 CY2010 Q1 CY2011 Q2-4 CY2011

• 16-24 cores for 5.5 and above • x86_64 - 64 bit for more memory is important - Data/Memory ration 1/3 to 1/10 to good (rule of thumb) - The more the better • Linux or Solaris best, Windows and Unix also fine. • RAID 10 for most, RAID 5 OK if very read intensive • Hardware RAID battery backed up cache critical! - More disks are always better! - 4+ recommended, 8-16 can increase IO performance if needed • At least 2 x NICs for redundancy • Slaves should be as powerful as the Master • Oracle Sun X4170 for example

• Storage Layer (Data nodes) • One data node can (7.0+) use 8 cores • CPU: 2 x 4 core (Nehalem works really well). Faster CPU → faster processing of messages. • RAM: As much as you need • a 10GB data set will require 20GB of RAM (because of redundancy • Each node will then need 2 x 10 / # of data nodes. (2 data nodes → 10GB of RAM → 16GB RAM is good) • SQL Layer (MySQL Servers) • CPU: 2 – 16 cores • RAM: Not as important – 4GB enough (depends on connections and buffers)

LCP LCP REDOLOG REDOLOG LCP / REDOLOG

1 x SATA 7200 RPM 1 x SAS 10K RPM 4 x SAS 10K RPM • For read-mostly • Heavy duty (many MB/s) • Heavy duty (many MB/s) • No redundancy • No redundancy • Disk redundancy (RAID1+0) (but other data node is (but other data node is hot swap the mirror) the mirror)

• REDO, LCP, BACKUP – written sequentially in small chunks (256KB) • If possible, use Odirect = 1

LCP UNDOLOG REDOLOG (REDO LOG) UNDOLOG TABLESPACE 1 TABLESPACE

TABLESPACE 2 2 x SAS 10K RPM (preferably) (REDO LOG / UNDO LOG) LCP 4 x SAS 10-15K RPM (preferably)

• Use High-end for heavy read / write workloads (1000's of 10KB records per sec) of data (e.g. Content Delivery platforms) • SSD for TABLESPACE an option to consider • Having TABLESPACE on separate disk is good for read performance • Enable WRITE_CACHE on devices

• Dedicated >= 1Gb/s networking – On Oracle Sun CMT servers it may be necessary to bond 4 or more NICs together because typically many data nodes are on the same physical host. • Prevent network failures (NIC x 2, Bonding, dual switches) • Use dedicated network for cluster communication – Put Data nodes and MySQL Servers on e.g 10.0.1.0 network and let MySQL listen on a “public” interface. • No security layer to management node • Enable port 1186 access only from cluster nodes and administrators

Copyright© 2011, Oracle. All rights reserved. CUSTOMER PERSPECTIVE “MySQL Cluster won the performance test hands-down, • COMPANY OVERVIEW and it fitted our needs perfectly. We evaluated shared-disk • Leading provider of communications platforms, clustered databases, but the cost would have been at least solutions & services 10x more.” • €15.2bn Revenues (2009), 77k employees across -- François Leygues, Systems Manager 130 countries

• CHALLENGES / OPPORTUNITIES • Converged services driving migration to next generation HLR / HSS systems RESULTS • New IMS platforms for Unified Communications • Scale out on standard ATCA hardware to support 60m+ subscribers on a single platform • Reduce cost per subscriber and accelerate time to value • Low latency, high throughput with 99.999%+ availability • Enabled customers to reduce cost per subscriber and improve margins • SOLUTIONS • Delivered data management solution at 10x less • MySQL Cluster Carrier Grade Edition cost than alternatives • MySQL Support & Consulting Services

http://www.mysql.com/why-mysql/case-studies/mysql-alcatel-casestudy.php

Copyright© 2011, Oracle. All rights reserved. • COMPANY OVERVIEW CUSTOMER PERSPECTIVE • Pyro provide comms technology solutions in ”MySQL Cluster 7.1 gave us the perfect combination of Core Network, OSS/BSS & VAS extreme levels of transaction throughput, low latency & • Deployed in 120+ networks worldwide carrier-grade availability. We also reduced TCO by being • Cell C, one of the largest mobile operators in able to scale out on commodity server blades and eliminate South Africa costly shared storage” • 560 roaming partners in 186 countries -- Phani Naik, Head of Technology at Pyro Group

• CHALLENGES / OPPORTUNITIES • FIFA 2010 world cup opens up network services to millions of mobile subscribers • International roaming SDP to support up to 7m RESULTS roaming subscribers per day • Supported subscriber and traffic volumes • Offer local pricing with home network • Delivered continuous availability functionality • Implemented in 25% of the time of typical SDP • Minimize cost and time to market solutions • Choice in deployment platforms to eliminate vendor lock-in (migrated from Microsoft) • SOLUTIONS • MySQL Cluster 7.1 & Services

Copyright© 2011, Oracle. All rights reserved. USER PERSPECTIVE • COMPANY OVERVIEW “MySQL Cluster exceeds our requirements for low latency, • Division of Docudesk high throughput performance with continuous availability, in • Deliver Document Management SaaS a single solution that minimizes complexity and overall cost.” -- Casey Brown, Manager of Dev & DBA Services, • CHALLENGES / OPPORTUNITIES Docudesk • Provide a single repository for customers to manage, archive, and distribute documents • Implement scalable, fault tolerant, real time data management back-end RESULTS • PHP session state cached for in-service • Successfully deployed document management personalization solution, eliminating paper trails from legal • Store document meta-data, text (as BLOBs), ACL, processes job queues and billing data • Integrate caching and database into one layer, • Data volumes growing at 2% per day reducing complexity & cost • Support workload with 50:50 read/write ratio • Low latency for real-time user experience and • SOLUTION document time-stamping • MySQL Cluster deployed on EC2 • Continuous database availability

• 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 uptime requirements” — Sean Collier, CIO & COO, Shopatron Inc http://www.mysql.com/why-mysql/case-studies/mysql_cs_shopatron.php

Copyright© 2011, Oracle. All rights reserved. 53 • COMPANY OVERVIEW CUSTOMER PERSPECTIVE • UK-based retail and wholesale ISP & Hosting “Since deploying our latest AAA platform, the MySQL Services environment has delivered continuous uptime, enabling us to • 2010 awards for best home broadband and exceed our most stringent SLAs” customer service -- Geoff Mitchell Network Engineer • Acquired by BT in 2007

• CHALLENGES / OPPORTUNITIES • Enter market for wholesale services, demanding more stringent SLAs • Re-architect AAA systems for data integrity & continuous availability to support billing sytems RESULTS • Consolidate data to for ease of reporting and • Continuous system availability, exceeding wholesale operating efficiency SLAs • Fast time to market • 2x faster time to market for new services • Agility and scale by separating database from applications • SOLUTIONS • Improved management & infrastructure efficiency • MySQL Cluster through database consolidation • MySQL Server with InnoDB