MySQL Database for High Availability Web Applications Tushar Joshi Turtle 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