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 Mace
jeff.mace@continuent.com
sales@continuent.com
560 S.Winchester Blvd. Suite 500 San Jose, CA 95128
Tel (866) 998-3642
Fax (408) 668-1009
http://www.continuent.com
http://code.google.com/p/tungsten-replicator
©Continuent 2012 25