Multi-Data Center MySQL with Continuent Tungsten

Transcription

1 Multi-Data Center MySQL with Continuent Tungsten Peter Boros, Consultant, Percona Robert Hodges, CEO, Continuent Percona Technical Webinars March 2, 2013

2 About This Presentation Why is multi-data center MySQL important? How does Continuent Tungsten fill the gaps? Demonstration Practical steps to multi-data center MySQL 2

3 Why is multi-data center MySQL important? Robert Hodges

4 Key reasons for multi-data center MySQL High availability Moving data away from problems Performance Moving data closer to users Legal Keeping data within some locations but not others 4

5 HA Example Amazon Failure EBS fails in a single availability zone US- West-1 Region US-East-1 EU- West-1 Availability Zones 5

6 HA Example Amazon Failure Leading to failures within the region due to coupled Amazon services US- West-1 Region US-East-1 EU- West-1 Availability Zones 6

7 HA Example Amazon Failure Leading to failure of tightly coupled applications in other regions US- West-1 Region US-East-1 EU- West-1 Availability Zones 7

8 Requirements for successful multi-dc MySQL Local HA within geographic regions Failover Planned maintenance and upgrade Advanced multi-site replication Flexible topologies Tolerant of faults and WAN latency Transaction filtering Minimal changes to apps / migration 8

9 How does Continuent Tungsten fill the gaps? Robert Hodges

10 Tungsten picks up where MySQL leaves off Handle local DBMS server failures Perform maintenance while apps are running Load balance SQL across DBMS Create disaster recovery sites Enable multi-master replication Replicate transactions in real-time to other DBMS types 10

11 Tungsten Cluster Architecture Off-the-shelf MySQL build Async replicators Peer-to-peer management db2 db1 db3 Network-based connectors Manager Slave Manager Master Manager Slave 11

12 How connectivity works TCP/IP Transparent: Implements MySQL wire protocol Runs anywhere on network Master Routes transactions to master by default Optional read/write splitting Slave db2 Manager db1 Manager Reads load-balanced across all slaves 12

13 Graceful failover Triggered by command Zero-data loss Transparent to applications db2 db1 db3 Automatic reconfiguration Manager Slave Manager Master Manager Slave 13

14 Hard failover MySQL crash Triggered by automatic rules Within seconds for MySQL crash Shunned Up to 1 minute after host crash db2 Manager db1 Manager db3 Manager Admin required for recovery Slave Master Slave 14

15 Hard failover quorum loss Managers maintain quorum Connectivity stops when lost Works across Amazon s X X X X Shunned Shunned Shunned db2 db1 db3 Manager Failed Manager Failed Manager But not regions Slave Master Slave 15

16 How replication works Moves transactions between points Can replicate between clusters Can run multiple services Global transaction IDs Very flexible topologies Transaction filtering Manager DBMS 16

17 Cross-site multi-master with independent clusters Normal operation 17

18 Multi-master replicator failure Automatic rerouting after replicator failure 18

19 Multi-master node failure Automatic failover following node failure 19

20 Full site failure West site down for multiple days 20

21 Cross-site primary/dr with composite data service Normal operation us 21

22 Composite service node failure Failover to slave node us 22

23 Composite service site failure Manual failover to slave site us 23

24 Demonstration Peter Boros

25 Demo Architecture EU-West-1 World US-East-1 US-West-1 EU-West-1 US-West-1 Composite Data Service Multi-Master Topology 25

26 Practical steps to multi-data center MySQL Robert Hodges

27 Setting Up Multi-DC Clustering Tungsten tpm Sets up local clusters and replication links between them 1. Put tungsten.ini file on host 2. Download software (rpm or tarball) 3. Run tpm install 27

28 Ini File for Composite Service [defaults]! home-directory=/opt/continuent! user=tungsten! replication-user=tungsten! replication-password=password! application-user=sbtest! application-password=sbtest! mysql-connectorj-path=/home/tungsten/mysql-connector-java bin.jar! start-and-report=true! [eu]! master=tw-eu1! slaves=tw-eu2,tw-eu3! connectors=tw-eu1,tw-eu2,tw-eu3! []! master=tw-usw1! relay-enabled=true! relay-source=eu! slaves=tw-usw2,tw-usw3! connectors=tw-usw1,tw-usw2,tw-usw3! [world]! composite-datasources=eu,! 28

29 Composite Data Services Pros and Cons Key benefits: No conflicts No app changes Failover is transparent Works with statement replication Things to consider and test: High latency writes to primary master Managing unplanned site failover Potential coupling between sites 29

30 Multi-Master Data Services Pros and Cons Key benefits Sites are completely uncoupled No failover! Minimal write latency Things to consider and test carefully: Potential for conflicts App changes often required Row replication strongly recommended 30

31 Workloads that handle multimaster very well Append-only data Tables that use only auto-increment keys Sharded apps where writes to each shard are in a particular region (system of record) 31

32 Where to get started Cluster and replication documentation Software software Percona and Continuent Websites 32

33 Thank You! Peter Boros Robert Hodges 33