Your SlideShare is downloading. ×
MySQL  HA  Alternatives 2010
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

MySQL HA Alternatives 2010

6,814
views

Published on

The presentation I gave in the MySQL Devroom at Fosdem 2010 , summarizing the different alternatives for MySQL HA

The presentation I gave in the MySQL Devroom at Fosdem 2010 , summarizing the different alternatives for MySQL HA

Published in: Technology

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

No Downloads
Views
Total Views
6,814
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
14
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. MySQL HA An overview Kris Buytaert
  • 2. Kris Buytaert
    • Senior Linux and Open Source Consultant @inuits.be
    • 3. „ Infrastructure Architect“
    • 4. I don't remember when I started using MySQL :)
    • 5. Specializing in Automated , Large Scale Deployments , Highly Available infrastructures, since 2008 also known as “the Cloud”
    • 6. Surviving the 10 th floor test
    • 7. DevOp
  • 8. What is HA Clustering ?
    • One service goes down
      • => others take over its work
    • IP address takeover, service takeover,
    • 9. Not designed for high-performance
    • 10. Not designed for high troughput (load balancing)
  • 11. Does it Matter ?
    • Downtime is expensive
    • 12. You mis out on $$$
    • 13. Your boss complains
    • 14. New users don't return
  • 15. Lies, Damn Lies, and Statistics Counting nines (slide by Alan R)
  • 16. The Rules of HA
    • Keep it Simple
    • 17. Keep it Simple
    • 18. Prepare for Failure
    • 19. Complexity is the enemy of reliability
  • 20. You care about ?
    • Your data ?
    • Your Connection
      • Always
      • 23. Most of the time
  • 24. Eliminating the SPOF
    • Find out what Will Fail
    • Find out what Can Fail
      • Network
      • 27. Going Out Of Memory
  • 28. Split Brain
    • Communications failures can lead to separated partitions of the cluster
    • 29. If those partitions each try and take control of the cluster, then it's called a split-brain condition
    • 30. If this happens, then bad things will happen
      • http://linux-ha.org/BadThingsWillHappen
  • 31. Historical MySQL HA
    • Replication
      • 1 read write node
      • 32. Multiple read only nodes
      • 33. Application needed to be modified
  • 34. Solutions
  • 41. Data vs Connection
    • DATA :
    • Connection
  • 45. Shared Storage
  • 51. DRBD
    • Distributed Replicated Block Device
    • 52. In the Linux Kernel (as of very recent)
    • 53. Usually only 1 mount
      • Multi mount as of 8.X
        • Requires GFS / OCFS2
    • Regular FS ext3 ...
    • 54. Only 1 MySQL instance Active accessing data
    • 55. Upon Failover MySQL needs to be started on other node
  • 56. DRBD(2)
    • What happens when you pull the plug of a Physical machine ?
      • Minimal Timeout
      • 57. Why did the crash happen ?
      • 58. Is my data still correct ?
      • 59. Innodb Consistency Checks ?
        • Lengthy ?
        • 60. Check your BinLog size
  • 61. MySQL Cluster NDBD
    • Shared-nothing architecture
    • 62. Automatic partitioning
    • 63. Synchronous replication
    • 64. Fast automatic fail-over of data nodes
    • 65. In-memory indexes
    • 66. Not suitable for all query patterns (multi-table JOINs, range scans)
  • 67. Title
      • Data
  • 68. MySQL Cluster NDBD
    • All indexed data needs to be in memory
    • 69. Good and bad experiences
      • Better experiences when using the API
      • 70. Bad when using the MySQL Server
    • Test before you deploy
    • 71. Does not fit for all apps
  • 72. Multi Master Replication
    • Replicating the same table data both ways can lead to race conditions
      • Auto_increment, unique keys, etc.. could cause problems If you write them 2x
    • Both nodes are master
    • 73. Both nodes are slave
    • 74. Write in 1 get updates on the other
    M|S M|S
  • 75. MySQL Proxy
    • Man in the middle
    • 76. Decides where to connect to
      • LUA
    • Write rules to
      • Redirect traffic
  • 77. Master Slave & Proxy
    • Split Read and Write Actions
    • 78. No Application change required
    • 79. Sends specific queries to a specific node
    • 80. Based on
  • 84. MySQL Proxy
    • Your new SPOF
    • 85. Make your Proxy HA too !
      • Heartbeat OCF Resource
  • 86. Breaking Replication
    • If the master and slave gets out of sync
    • 87. Updates on slave with identical index id
      • Check error log for disconnections and issues with replication
  • 88. Monitor your Setup
    • Not just connectivity
    • 89. Also functional
      • Query data
      • 90. Check resultset is correct
    • Check replication
  • 92. Pulling Traffic
    • Eg. for Cluster, MultiMaster setups
  • 96. MMM
    • Multi-Master Replication Manager for MySQL
      • Perl scripts to perform monitoring/failover and management of MySQL master-master replication configurations
    • Balance master / slave configs based on replication state
      • Map Virtual IP to the Best Node
    • http://mysql-mmm.org/
  • 97. Flipper
    • Flipper is a Perl tool for managing read and write access pairs of MySQL servers
    • 98. master-master MySQL Servers
    • 99. Clients machines do not connect "directly" to either node instead,
    • 100. One IP for read,
    • 101. One IP for write.
    • 102. Flipper allows you to move these IP addresses between the nodes in a safe and controlled manner.
    • 103. http://provenscaling.com/software/flipper/
  • 104. Linux-HA PaceMaker
    • Plays well with others
    • 105. Manages more than MySQL
    • 106. ...v3 .. don't even think about the rest anymore
    • 107. http://clusterlabs.org/
  • 108.  
  • 109. Conclusion
    • Plenty of Alternatives
    • 110. Think about your Data
    • 111. Think about getting Queries to that Data
    • 112. Complexity is the enemy of reliability
    • 113. Keep it Simple
    • 114. Monitor inside the DB
  • 115. ` Kris Buytaert < [email_address] > Further Reading http://www.krisbuytaert.be/blog/ http://www.inuits.be/ http://www.virtualization.com/ http://www.oreillygmt.com/ ? !

×