Your SlideShare is downloading. ×
Drupal Con My Sql Ha 2008 08 29
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Drupal Con My Sql Ha 2008 08 29

1,315

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,315
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. High Availability Solutions for MySQL Lenz Grimmer <lenz@grimmer.com> 2008-08-29 DrupalCon 2008, Szeged, Hungary
  • 2. Agenda ● High Availability in General ● MySQL Replication ● MySQL Cluster ● DRBD ● Links/Tools
  • 3. Why High Availability Matters ● Downtime is expensive ● You miss $$$ ● Your Boss complains ● New Site visitors won't come back
  • 4. What Is HA Clustering? ● One service goes down → others take over its work ● IP address takeover, service takeover ● Not designed for high-performance ● Not designed for high troughput (load balancing)
  • 5. Split-Brain ● Communications failures can lead to separated partitions of the cluster ● If those partitions each try and take control of the cluster, then it's called a split-brain condition ● If this happens, then bad things will happen http://linux-ha.org/BadThingsWillHappen ● Use Fencing or Moderatation/Arbitration to avoid it
  • 6. Eliminating the SPOF ● Identify what will fail ● Disks ● Find out what can fail ● Network cables ● OOM ● Power supplies
  • 7. Rules of High Availability ● Prepare for failure ● Keep it simple, stupid (KISS) ● Complexity is the enemy of reliability ● Test your setup frequently
  • 8. MySQL Replication ● One-way, statement-based ● One Master, many Slaves ● Asynchronous – Slaves can lag ● Master maintains binary logs & index ● Easy to set up ● Built into MySQL ● Replication is single-threaded
  • 9. MySQL Replication Overview Read & Write Web/App Server Write Relay Log mysqld I/O SQL Thread Thread Index & Binlogs Daten Replication Binlog Data mysqld MySQL Master MySQL Slave
  • 10. Replication Topologies Master > Slave Master > Slaves Master > Slave > Slaves Masters > Slave (Multi-Source) Ring (Multi-Master) Master < > Master (Multi-Master)
  • 11. Replication & HA ● Combined with Heartbeat ● Virtual IP takeover ● Slave gets promoted to Master ● Side benefits: load balancing & backup ● Tricky to fail back ● No automatic conflict resolution ● Proper failover needs to be scripted
  • 12. Master-Master Replication ● Useful for easier failover ● Not suitable for load-balancing ● Writes still end up on both machines ● Neither machine has the authorative data ● Don't write to both masters! ● Use Sharding or Partitioning instead (e.g. MySQL Proxy)
  • 13. MySQL Cluster ● Shared nothing ● Automatic partitioning ● Distributed Fragments ● Synchronous replication ● Fast automatic fail-over of data nodes ● Automatic resynchronization ● Transparent to Application ● Supports Transactions
  • 14. MySQL Cluster ● In-memory tables ● Not suitable for all query patterns ● Not suitable for large datasets ● Latency matters ● Can be combined with MySQL Replication
  • 15. DRBD ● Distributed Replicated Block Device ● “Raid-1 over network” ● Synchronous block replication ● Automatic resync on recover ● Application-agnostic ● Can mask local I/O errors ● Active/passive configuration
  • 16. DRBD & Heartbeat ● Heartbeat mounts file system on failover (passive node becomes active) ● Data only accessible on the active node ● (LVM snapshots can work around this) ● Increased I/O Latency ● Failover is “cold” (fsck, log recovery, buffers/caches)
  • 17. MySQL Replication & MySQL, Heartbeat & MySQL Requirements MySQL Replication Heartbeat DRBD Cluster Automated IP Failover No Yes Yes No Automated DB Availability Failover No No Yes Yes Typical Failover time Varies Varies < 30s < 3s Auto resync of data No No Yes Yes Geographic MySQL redundancy Yes Yes MySQL Replication Replication Built-in load Scalability balancing MySQL Replication MySQL Replication MySQL Replication Yes Read-intensive Yes Yes MySQL Replication Yes Write-intensive No No Possible Yes #Nodes/Cluster Master/Slave(s) Master/Slave(s) Active/Passive 255
  • 18. Related tools / Links ● Linux Heartbeat http://linux-ha.org/ ● DRBD http:/drbd.org/ ● Linux Cluster Information Center http://www.lcic.org/ha.html ● Red Hat Cluster Suite http://www.redhat.com/cluster_suite/ ● Sun Open High Availability Cluster http://opensolaris.org/os/project/ha-mysql/
  • 19. Tools/Links ● MySQL Multi-Master Replication Manager http://code.google.com/p/mysql-master-master/ ● Maatkit http://maatkit.sourceforge.net/ ● Mon – scheduler and alert management http://www.kernel.org/software/mon/ ● Continuent Tungsten Replicator https://community.continuent.com/community/tungsten-replicator
  • 20. Q&A Questions, Comments?
  • 21. Thank you! Lenz Grimmer <lenz@grimmer.com>

×