Failover or not to failover


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Failover or not to failover

  1. 1. Failover, or not Failover,that is the questionPercona Live MySQL Conference and Expo 2013Massimo Brignoli, SkySQLHenrik Ingo, NokiaPlease share and reuse this presentation licensed under the Creative Commonse Attribution License
  2. 2. Agenda● Why HA is more difficult for databases● Steps to failover● Monitoring● Automating failover● Sounds great!What could possibly go wrong?● Amazon Dynamo● Galera and NDB
  3. 3. Fault tolerance = redundancy● RAID● 2 power units per server● Cluster of servers● 2 kidneys per person● Redudancy at all levels:Software, Hardware, Network, Electricity...A chain is as strong as the weakest link.
  4. 4. Durability"Durability is an interesting concept.If I flush a transaction to disk,it is said to be durable.But if I then take a backup,it is even more durable."Heikki Tuuri
  5. 5. Why High Availability isMore Difficult for DatabasesRedundancy of serverANDRedundancy of dataWHILEPerforming thousands of write operationsper second onto the dataset
  6. 6. What failover?1. Primary server2. Secondary / Standby serverfor redundancy3. In case Primary fails,Secondary server mustbecome the new Primary
  7. 7. Steps to failover (theory)1. Notice failure2. Move VIP3. Continue
  8. 8. Automating failoverGeneric Clustering Solutions● Pacemaker/Corosync● Linux Heartbeat● Red Hat Cluster Suite● Solaris Cluster● Windows Server FailoverClustering● etc...MySQL Specific Solutions● MMM● PRM● MHA● JDBC connector
  9. 9. Steps to failover (DRBD)VIPVIP1. Have DRBD2. Notice failure3. Shutdown MySQL on primary4. Unmount disk on primary5. Mount disk on secondary6. Start MySQL on secondary7. Wait for InnoDB recovery8. Wait for InnoDB recovery9. Wait for InnoDB recovery10. Unset VIP on primary11. Set VIP on secondary12. Continue13. Should you add a new secondary?
  10. 10. Steps to failover (MySQL replication)VIPVIP1. Have replication2. Notice failure3. Make slave writable4. Make master read-only5. Unset VIP on master6. Set VIP on slave7. Continue8. Should you add a new slave?
  11. 11. What if you have more than 2 servers?(MySQL replication)VIPVIP?● MySQL replication failover with more than 2servers can be a hassle.● Which slave should become the new master?● All slaves must be pointed to the new master.● They must figure out where to continuereplication (binlog position)● MySQL 5.6 GTID helps.
  12. 12. MHA and SkySQL...● Combination ofresource manager+ scripts● Automating failoverprocess:○ New Masterselection○ Slavesreconfiguration○ VIP management○ Missing binlogsretrieval
  13. 13. Sounds great,what could possibly go wrong?
  14. 14. Sounds great,what could possibly go wrong?VIP1. Have replication○ Ok, is it working? What if its not working?○ Is it replicating in the right direction?○ Does your bash script handle binlog positions correctly?○ Asynchronous?2. Notice failure○ Polling interval○ Who is polling?○ ...and from where?○ How is he handling failure himself?○ False positives○ Is failover the right response to every failure?3. STONITH○ Shutdown MySQL on Primary? How? Its not responding...○ Unmount disk on Primary? How? Its not responding...○ "You need a STONITH device"! Hehe, nice try...4. Move VIP○ Unset VIP on Master/Primary? How? Its not responding...○ Set VIP on Secondary/Slave. This will work fine. Unfortunately.5. Continue6. Add back new/same Secondary○ Automatically of course. Even if it just failed 15 seconds ago.VIP
  15. 15. Case Github● MySQL replication, Pacemaker, Corosync, Percona Replication Manager● PRM health check fails due to high load during schema migration.● Failover!● New node has cold caches, so even worse performance.● Failover! (back)● Disable PRM● A slave is found outdated as replication is not happening● Enable PRM and hope it will fix it● Pacemaker segfaults, causing cluster partition● PRM selects the outdated node as master, shuts down others● All kinds of data inconsistencies● Restart PRM on all nodes● ...
  16. 16. Case GithubLesson learned:Automated failover is dangerousCold cache is dangerous
  17. 17. But...Not automating is also dangerousBaron Schwartz:75% of replication failures are human errors of Aviation accidentsare caused by human errors Events caused by human errors, 70% ofthem due to organization weaknesses
  18. 18. Are we solving the right problem?
  19. 19. Instead of automating the problem...Eliminate the problem!
  20. 20. Amazon DynamoR + W > NVoldemort, Cassandra, RIAK, DynamoDB, S3
  21. 21. N=3, R=W=2R + W > N
  22. 22. Eventual consistency is internal onlyR + W > N
  23. 23. Failover?Single node failure is a non-event!
  24. 24. For relational databases?Synchronous replication isspecial case of Dynamo:W=N & R=1
  25. 25. Or is there a failover after all?Due to W=N, writers actually notice nodefailures! Cluster reconfiguration needed.(Readers are ok.)?
  26. 26. Example: GaleraOKTimeout
  27. 27. Example: MySQL NDB Cluster
  28. 28. What have we learned?● Failover with DRBD is painful because it isslow.● Failover with MySQL replication is painfulbecause its a mess.● Amazon Dynamo has no failover● Galera Cluster has no failover but needscluster reconfiguration. Same thing...● MySQL NDB Cluster has failover but youcant see it.