Seminar : "The Future of MySQL - Roadmap to Success" session MySQL High Availability Options

1. <Insert Picture Here>
MySQL High Availability Options
Ryusuke Kajiyama
MySQL Principal Sales Consultant, Asia Pacific and Japan

2. Designing for High Availability
Copyright Oracle Corporation 2010 2 2

3. Selecting the Right HA Architecture
Copyright Oracle Corporation 2010 3 3

4. MySQL High Availability Option
• MySQL Replication • MySQL+DRBD (for Linux)
Asynchronous replication Shared Nothing Active/Passive
Application / Application /
Web / Web AP Web / Web AP
Load Balancing Fail Over on failure
MySQL MySQL MySQL MySQL
Server Asynchronous Server Server Synchronous Server
Replication Replication
• Shared Disk Based • MySQL Cluster
Active/Passive Shared Nothing Active/Active
Application / Application /
Web / Web AP Web / Web AP
Fail Over on failure Load Balancing
Shared disk
MySQL MySQL MySQL MySQL
Server Server Cluster Synchronous Cluster
Replication
4

5. Common MySQL HA Solutions
MySQL Replication is Common Foundation for MySQL HA
MySQL &
Requirements Replication Cluster
DRBD
Availability
Automatic Fail Over No Yes Yes
Fail Over Time Varies < 1 sec < 5 min
Resynch of Data No Yes Yes
Geographic Redundancy Yes Yes No
Scalability
Load Balancing Scale-Out Yes No
Read Intensive Yes Yes No
Write Intensive No Yes No
# of Nodes 100’s (reads) 255 1 Active
SQL Functionality
Primary Key Lookups Yes Yes Yes
Simple JOINs Yes Yes Yes
Complex JOINs Yes No Yes
Transactions Yes Yes Yes
Copyright Oracle Corporation 2010 5 5

6. MySQL Replication Overview
• Native in MySQL
• Used for Scalability
and HA
• Asynchronous as
standard
• Semi-Synchronous
support added in
MySQL 5.5
• Each slave adds
minimal load on
master
Copyright Oracle Corporation 2010 6 6

7. MySQL Replication
Delivering Read Scalability
Clients
MySQL Replication
Slaves Master
• Used by leading web properties for scale-out
• Reads are directed to slaves, writes to master
• Delivers higher performance & scale with efficient resource utilization
Copyright Oracle Corporation 2010 7 7

8. MySQL Replication Topologies
Master > Slave Master > Slaves
Masters > Slave (Multi-Source) Master > Slave > Slaves
Circular (Multi-Master)
Master < > Master (Multi-Master)
8

9. Building on Replication
Failure Detection & Failover
• Linux Heartbeat implements heartbeat protocol between nodes
• Failover initiated by Cluster Resource Manager (Pacemaker) if heartbeat
message is not received
• Virtual IP address failed over to ensure failover is transparent to apps
Copyright Oracle Corporation 2010 9 9

10. MySQL HA Configuraiton
MySQL Replication RedHat Cluster + Shared
+ IP address failover storage for Master + Slave
Application / Application /
Web / Web AP Web / Web AP
Load Balancing Fail Over on failure
Shared disk
MySQL MySQL MySQL MySQL
Server Asynchronous Server Server Server
Replication
Master Slave Master Standby
(Read + Write) (Read) (Read + Write) Asynchronous
Replication
MySQL
Server
Slave
(Read)
10

11. In case of failure of Master Server
MySQL Replication RedHat Cluster + Shared
+ IP address failover storage for Master + Slave
Application / Application /
Web / Web AP Web / Web AP
Fail Over on failure Fail Over on failure
Shared disk
MySQL MySQL MySQL MySQL
Server Server Server Server
New Master Asynchronous New Master
(Read + Write) Replication (Read + Write)
MySQL
Server
Slave
(Read)
11

12. MySQL 5.5 Replication Features
1. Semisynchronous replication
Improved resilience by having master wait for slave to
receive events.
2. Slave fsync tuning & Automatic relay log recovery
Tune fsyncs so corruption is less likely on slave crashes.
Let the slave recover from corrupted relay logs.
3. Replication Heartbeat
Have a more precise failure detection mechanism.
Avoid spurious relay log rotation when the master is idle.
4. Per server replication filtering
Instruct slave to discard events from a master with a
specific server id.
Copyright Oracle Corporation 2010 12 12

13. MySQL 5.5 Replication Features
5. Precise Slave Type Conversions
Use different types on master and slave and get
automatic type promotion and demotion when using RBR
6. Individual Log Flushing
Selectively flush server logs when using 'FLUSH LOGS'
7. Safe logging of mixed transactions
Replicate transactions containing both InnoDB and
MyISAM changes
Copyright Oracle Corporation 2010 13 13

14. Asynchronous Replication
Application
Commit Response
Connection Thread Changing
Data
Changing Changing
Data Binlog
Replication
Data Binlog Relaylog Data
Master Slave
14

15. Semi-synchronous Replication
Application
Commit Response
Connection Thread Changing
Response Data
Changing Changing
Data Binlog
Replication
Data Binlog Relaylog Data
Master Slave
15

16. What is Memcached?
“A high-performance, distributed memory object caching
system, generic in nature, but intended for use in speeding up
dynamic web applications by alleviating database load” *
* http://www.socialtext.net/memcached/index.cgi?faq
• Created by Danga Interactive to speed up LiveJournal’s 20
million+ dynamic page views per day for 1 million+ users
• Significantly dropped database load, delivering faster page
loads, better resource utilization, and faster access to
databases
• Perfect for dynamic sites that generate high database load
• Used by Facebook, YouTube, Wikipedia, others!
16

17. Why was Memcached created?
• Created to speed up blogging site LiveJournal
• 20 million+ dynamic page views per day
• 1 million+ users
• Results…
• Faster page loads
• Lowered database load
• Better resource utilization
• Faster access to databases
• Perfect for dynamic sites that generate high database load
17

18. Typical Use Case: Read/Pass-Through
• Application is modified so data is
read from memcached not the
database
• In the event the data is stale or
non-existent…
– data is read from the
database
– written into memcached
• Next request for the same data is
retrieved from memcached
18

19. Memcached Functions for MySQL
• Overview
– Uses UDF API and libmemcached
– Manage memcached Cluster via SQL
– Read through Cache
– Write through Cache
• Installation
– CREATE FUNCTION memc_servers_add
RETURNS INT SONAME
"libmemcached_functions_mysql.so";
19

20. memcached UDF Example
– Creating Trigger which kicks UDF is one of the best practices
20

21. Linux Heartbeat, Block-Replication & MySQL
• Distributed Replicated Block Device (DRBD)
– Runs over standard IP networks
– Distributed storage
– Similar to network RAID
• Synchronous
• Characteristics
– Higher complexity to install and configure
– No special networking components (except Heartbeat)
– Excellent performance (blocks vs. rows of data)
– Manages inconsistencies of data during a failure
– Hides the complexity of many recovery actions
– Linux heartbeat manages fail over and virtual IPs
21

22. DRBD Architecture
22

23. MySQL w/ Shared Storage & Clustering Agents
• Active/Passive likely configuration
– Multiple instances not allowed concurrent access to same
data files
• Automated management
– Virtual IPs
– Fail over
– Data synchronization
– Mounting file systems
• Characteristics
– High cost (storage, hardware, software)
– Idle resources
– Longer fail over times
– High initial complexity
– Many options and proven vendors
23

24. MySQL Cluster
• Shared-Nothing Clustering Solution
• Synchronous (2-phase commit)
• Fast Automatic Fail Over
• High Performance
• High Transactional Throughput
• No Special Component Requirements
• In-Memory & Disk Data Support
• Heart-beat protocol
24

25. MySQL Cluster Architecture
Parallel Database with no SPOF: High Read & Write Performance & 99.999% uptime
Clients
MySQL Cluster Application Nodes
MySQL MySQL
Cluster Cluster
Mgmt Mgmt
MySQL Cluster Data Nodes
25

26. 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
26

27. Geographic Replication
• Synchronous replication within
a Cluster node group for HA
• Bi-Direction asynchronous
replication to remote Cluster for
Cluster 1 Cluster 2 geographic redundancy
• Asynchronous replication to
non-Cluster databases for
specialised activities such as
report generation
• Mix and match replication types
MyISAM MyISAM InnoDB
Synchronous
replication
Asynchronous
replication
27

28. High Throughput, Low Latency Transactional Performance
DBT2 Benchmark, 4-MySQL Cluster Data Nodes
275000
Transactions Per Minute 250000
225000
200000
175000
150000
MySQL C lust 7.0
er
125000 MySQL C lust 6.3
er
100000
75000
50000
25000
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
28

29. Low-Level Access via NDB API
• High performance C++ API
• Implements indexes, scans, transactions & events
• ACID-compliant
• Object-oriented error-handling
• Additional performance features not available in SQL
SQL Node
(MySQL)
X
NDB API
Data Node
(NDB Storage Engine)
29

30. MySQL Cluster Connector for Java
• New Domain Object Model Persistence
API (ClusterJ) :
– Java API
– High performance, low latency
– Feature rich
• JPA interface built upon this new Java
Network layer:
– Java Persistence API compliant
• Implemented as an OpenJPA plugin
– 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
Data Nodes applications
30

31. • 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
Learn More: http://www.mysql.com/why-mysql/case-studies/mysql_cs-pyro_telecoms.php
32
32

32. 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
Learn More: http://www.mysql.com/why-mysql/case-studies/mysql_cs_shopatron.php 33
33

33. MySQL High Availability Option
• MySQL Replication • MySQL+DRBD (for Linux)
Asynchronous replication Shared Nothing Active/Passive
Application / Application /
Web / Web AP Web / Web AP
Load Balancing Fail Over on failure
MySQL MySQL MySQL MySQL
Server Asynchronous Server Server Synchronous Server
Replication Replication
• Shared Disk Based • MySQL Cluster
Active/Passive Shared Nothing Active/Active
Application / Application /
Web / Web AP Web / Web AP
Fail Over on failure Load Balancing
Shared disk
MySQL MySQL MySQL MySQL
Server Server Cluster Synchronous Cluster
Replication
34