Your SlideShare is downloading. ×
  • Like
  • Save
Disaster Recovery with MySQL and Tungsten
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Disaster Recovery with MySQL and Tungsten

  • 348 views
Published

 

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
348
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
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
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

Transcript

  • 1. Disaster Recovery with MySQL and Tungsten Jeff Mace©Continuent 2012.
  • 2. Right now ... • your slaves are 2 hours behind the master. • it takes 30 minutes to recover from a DB failure. • you are running a network of sites from a single datacenter.©Continuent 2012 2
  • 3. You need to ... • reduce replication lag of your slaves. • automatically failover when a DB crashes. • host sites from many locations, and have a copy of the data everywhere.©Continuent 2012 3
  • 4. Where does lag come from? www.example.com©Continuent 2012 4
  • 5. Where does lag come from? www.example.com www.spacely.com©Continuent 2012 4
  • 6. Where does lag come from? www.example.com www.spacely.com www.widgets.com©Continuent 2012 4
  • 7. Where does lag come from? www.example.com www.spacely.com www.widgets.com www.bigfoothunter.com Large updates to one site can hold up replication for others©Continuent 2012 4
  • 8. Reducing replication lag www.example.com www.spacely.com www.widgets.com www.bigfoothunter.com Tungsten can replicate each site in parallel©Continuent 2012 5
  • 9. Best Practices • Use a separate schema for each site • Avoid updates that affect multiple schemas • We recommend 10 parallel channels max • Manually create channel assignments for each schema to balance the workload©Continuent 2012 6
  • 10. Bi-directional HA Tungsten allows you to replicate in both directions©Continuent 2012 7
  • 11. Bi-directional HA Tungsten allows you to replicate in both directions©Continuent 2012 8
  • 12. Bi-directional HA Tungsten allows you to replicate in both directions©Continuent 2012 9
  • 13. Best Practices • SET GLOBAL read_only=true; • REVOKE SUPER ON *.* FROM ‘app_user’@‘host.example.com’; • Take your backups from the slave©Continuent 2012 10
  • 14. What’s wrong with most failover • Recovery of the failed server is tedious and requires careful analysis • Virtual IPs may go to the wrong server even after being moved • Synchronous replication may reduce write performance©Continuent 2012 11
  • 15. Why connect to a database server ...©Continuent 2012 12
  • 16. ... when you can connect to a cluster. Tungsten sends connections to the current master©Continuent 2012 13
  • 17. Failover is hidden inside the cluster Tungsten will automatically trigger a failover©Continuent 2012 14
  • 18. Failover is hidden inside the cluster and promote a new master.©Continuent 2012 15
  • 19. Failover is hidden inside the cluster The failed server can be restored later©Continuent 2012 16
  • 20. Planning for disaster recovery NYC London Tokyo©Continuent 2012 17
  • 21. Planning for disaster recovery NYC London Tokyo©Continuent 2012 18
  • 22. Planning for disaster recovery NYC London Tokyo©Continuent 2012 19
  • 23. Planning for disaster recovery NYC London Tokyo©Continuent 2012 20
  • 24. Build a global replication network NYC London Tokyo©Continuent 2012 21
  • 25. Best Practices • Shard your data at the schema level • Limit writes to a single location per schema • If that is not an option ... • Use auto_increment options to avoid key conflicts • Enable ROW replication • https://docs.continuent.com/wiki/x/24Qk©Continuent 2012 22
  • 26. Support • Per server or site-license based support • 24/7 coverage for replication failures • Includes - • Clustering • Advanced replication topologies • Heterogenous replication such as MySQL -> Oracle or Oracle -> MySQL©Continuent 2012 23
  • 27. We’re Hiring • Cluster Implementation Engineer • QA Engineer©Continuent 2012 24
  • 28. Jeff Macejeff.mace@continuent.comsales@continuent.com560 S.Winchester Blvd. Suite 500 San Jose, CA 95128Tel (866) 998-3642Fax (408) 668-1009 http://www.continuent.com http://code.google.com/p/tungsten-replicator©Continuent 2012 25