MySQL Database for High Availability Web Applications

Tushar JoshiTurtle Networks Ltd

www.turtle.net

Overview

● What is High Availability?● Web/Network Architecture● Applications● MySQL Replication● MySQL Clustering

What is High Availability?

High availability is a system including physical implementation that ensures an absolute

degree of operational continuity during a given measurement period.

High Availability

● Decide your availability (99.9 or 99.999)● No single point of failure ● Uptime and availability are different● Network and software work hand in hand● BGP, Bonding, Load Balancing● Fast changeover

Load Balancing

● DNS Round Robin● Simple Failover when main server dies.● Multiple live real servers, using scheduling.● Round robin, weighted least connection ● Failover for load balancers! (heartbeat)● Persistence and Session IDs with cookies or source IP

● Local Director on Linux (HA Suite)

Apache / Tomcat

● Serves dynamic and static content.● Static files on disk needs to be replicated.● Session needs to be distributed or stored in database. (Broadcasted?)

● HTTP Status fed back to local director● Application data cache is useful for certain data.

● Evaluate work load split for AS and DB

Database

● Single point of failure is single database● NFS or distributed FS (SAN). Oracle RAC● Multiple databases but with load balancing in application.

● Transaction support? Inconsistencies. ● Application needs to deal with failure.● Recovery difficult.

MySQL

● Identify easiest route to faster access● Index data to speed up transactions.● Socket file or TCP/IP connection.● Multiple MySQL DB with different data● Data partitioning, either tables, groups● Problems with reporting functions. Joins.● Use both, partition and replicate.● Tablespaces (Oracle term – only in InnoDB)

MySQL : Storage Engines

● Flexible ways to store data on disk● Transparent to application● MyISAM (very fast)● InnoDB (transaction safe)● Memory● CSV● Archive (fastest)● Federated (more load balancing than HA)

MySQL : Master / Slave

●Multiple databases with 'same' data.●Application data cache invalidated.●Replication time can change.●Similar hardware is best●Enable binary logging (BinLog)●Slave connects as a client with replication privilege.

MySQL : Master / Slave

●Asynchronous replication●Read only from slave●Read/Write for master●Reporting functions on slave.●Slave connects and retrieves new data from log file on master.●Slave stays connected and master sends updates.●Row based and Statement based in 5.1

●

MySQL : Master / Slave

● On failure slave switches to master. (SW)● Master on recovery doesn't get updates from slave.

● Data inconsistency● Manual intervention required, downtime, not HA.

● Useful as live backup, and can shutdown slave to make a backup.

● Slave automatically recovers on startup.

MySQL : Master / Master

● Failure of master causes problems in M/S setup

● Need to swap the master automatically.● Updates of 'slave' to be seen on master● Changes on either propagated to other● Enable BinLog on slave.● Setup master in original setup to update from slave as well.

● Each DB must have a different ID.●

Continued.....

● Easy to setup and maintain.● No manual intervention for failover and recovery.

● Does work with all table types.● Multiple slaves allowed (MMSSSSS).● Used in combination with a control node.● Updates done to active master (which can change).

● Works remotely over a slow connection

Limitations

● Updates are still asyncronous● Delay in update being viewable on other server.

● Writes to only one database, however on failure this can swap over.

● Only two masters (MM), (MMM) not possible.● Chance of data loss.

Tools

● Replication Manager (Enterprise)● mysql● mysqldump (single transaction) (Level 0)● InnoDB Hot backup (E390)● SET MASTER / START STOP SLAVE

MySQL Clustering

● MySQL 5.1 ● Master/ Master Syncronous updates● 5 nines reliability● Fast automatic failover (sub second)● No single point of failure● Read and Write from any node.● Main memory only (no IO bottle necks).● Share nothing● Row level locking

Cluster Overview

Node Diagram

Cluster Setup

● Storage Nodes● Management Node (LDIR)● SQL Nodes (LDIR)● Use a load balanced IP on SQL Nodes.● Node != Server● (SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes

● Circular replication is possible

Cluster Limitations

● No disk storage engine, memory required to size of database.

● As of latest version only indexed data in memory.

● Must use 100MB or more network. (SCI)● Reducing latency speeds up transactions considerably.

● Overhead of query cache slows things down.

Limitations

● No indexes on text or blob fields● Max 48 data nodes (Max 63 nodes)● Dynamic adding/removing data nodes not possible

● Commits are replicated but not guaranteed to be flushed to disk.

● Does not handle large transactions well.

Summary

● Choose the strategy best for yourself● Databases need to be tuned● Can use a mix between clustered, partitioned and MS replicated

● Benchmarks available, whose lies do you believe?

● MySQL Cluster and replication improving all the time. Next version is 5.2