MySQL Replication Options. Peter Zaitsev, CEO, Percona Moscow MySQL User Meetup Moscow,Russia

Transcription

1 MySQL Replication Options Peter Zaitsev, CEO, Percona Moscow MySQL User Meetup Moscow,Russia

2 Few Words About Percona 2 Your Partner in MySQL and MongoDB Success 100% Open Source Software We work with MySQL, MariaDB, MongoDB, Amazon RDS and Aurora No Lock in Required Solutions and Services 2

3 In This Presentation Why Replication? How to think about Replication Overview of what MySQL Has to Offer 3

4 Replication Having Multiple Copies of the data, updated with changes 4

5 Why Replication Availability Scalability Performance 5

6 Availability Service Stays up when component fails 6

7 Availability via Redundancy Have more than one system Works well for stateless systems Is not enough for databases 7

8 Availability via Replication Redundant Computing Resource Paired with Replicated Data 8

9 Component Failure Node Failures Total Crash Process Crash Stall/Unresponsive Consistency Issues Network Failures Single Port Failures Partitions Complicated Failures 9

10 Scalability Scales Reads Does not Scale Writes very well Data Distribution is needed for scaling writes 10

11 Performance Reduce response time by maintaining replica closer to user 11

12 Talking about Full Database Replication System of Record Partial Database Replication Can be used as Cache Synchronization of Client Data 12

13 Where Replication Happens Storage Level Database Level Application Level 13

14 Storage Level Replication Replication RAID Typically provides cold standby Simple choice which works with many systems Amazon Aurora Smart Storage 14

15 Database level Most Flexible Most Common Hot/Warm Spare Some can do Active-Active 15

16 Application Level Hard to get right Rarely used, even more so used right Partial Replication/Syncronization Smart conflict resolution Cross Vendor Redundancy 16

17 Replication Properties 17

18 Number of Writable Nodes Single Writer (Master) Write Anywhere (Multi Master) 18

19 Single Master All writes go to the single node One way replication stream Simple No Conflicts Replication aware Application or Connector 19

20 Multiple Active Masters Can write to multiple masters Replication is multi-directional More Complicated Possibility of Conflicts 20

21 Sync or Async Synchronous Replication Asynchronous Replication 21

22 Synchronous Replication Data Persisted on Target Server Guarantees No Data Loss if Source server fails Conflicts can be easily prevented Expensive 22

23 What Persisted means? In Memory Assumes power loss of both servers does not happen On Disk Handles Total Loss of Master and Power loss on the Slave 23

24 Asynchronous Replication Anything not Synchronous Many different variants exist! 24

25 Asynchronous Properties Commit on Master What happens with Persistence? What happens with Visibility? 25

26 Persistence Uncommitted Data on Master Committed Data on Master Date in Slave s memory Data on Slave s Disk (log) 26

27 Visibility Results be visible by concurrent sessions before acknowledgement Phantom Reads Results can t be visible by concurrent sessions No Phantom Reads 27

28 Conflits No Conflict Handling Conflict Detection Conflict Resolution Conflict Prevention 28

29 Acknowledgements Applies both to Sync and Some Async How many node have successfully replicated data? All? One? Majority? 29

30 Level of Control Global Control vs Database Control Control by Writer vs Reader 30

31 Number of Replicas On (2 nodes) Two or more (3+ nodes) 31

32 2 nodes Basic Redundancy Need Help with Failure detection and Split Brain No Redundancy in case of node maintainance 32

33 3+ Nodes Much better Redundancy Quorum based failure handling works out of the box Can do node maintenance without redundancy loss 33

34 Failure Detection and Promotion Built-In Handled by External Tools 34

35 Replica Provisioning Manual Automatic 35

36 Gotchas Distributed systems are complicated. All products have their own gotchas. 36

37 MySQL Replication 37

38 Classic MySQL Replication Fully Asynchronous No Failure Detection and Promotion Manual Provisioning Can run Multi-Master No Conflict Handling 38

39 Semi-Sync Replication 5.6 Wait for one of the slaves to ack update before response to client Commits too soon on the Master Phantom Reads / Possible loss of visible changes Can switch to asynchronous mode 39

40 Semi-Sync Replication 5.7 Commits on the Master only after slave acknowledges Update invisible to other clients until slave acknowledges Can be Configured to have MySQL 5.6 behavior 40

41 Making MySQL Replication Better MHA MySQL Failover PRM 41

42 Percona XtraDB Cluster and Galera 42

43 Percona XtraDB Cluster Virtually Synchronous Replication Well known Innodb Storage Engine All Reads are Local Parallel Replication Write to any node behavior Built in Node Provisioning and HA Works great in the Cloud! 43

44 PXC vs Galera Galera Is replication technology/library Compare to Linux Kernel Percona XtraDB Cluster Percona Server Enabling Enhancements Galera Library Provisioning Tools HA and Load Balancing Integrated together and Tested Compare to Linux Distribution 44

45 PXC Data Architecture 45

46 Architecture Concepts All Nodes Have Full copy of Data Every Node is Equal No Central Management No SPOF 46

47 Understanding Cluster The cluster can be seen as a meeting! 47

48 PXC (Galera cluster) is a meeting 4 8 bfb912e5-f560-11e eefab05e57d 48

49 PXC (Galera cluster) is a meeting 4 9 bfb912e5-f560-11e eefab05e57d 49

50 PXC (Galera cluster) is a meeting 5 0 bfb912e5-f560-11e eefab05e57d 50

51 PXC (Galera cluster) is a meeting 5 1 bfb912e5-f560-11e eefab05e57d 51

52 PXC (Galera cluster) is a meeting 5 2 bfb912e5-f560-11e eefab05e57d 52

53 PXC (Galera cluster) is a meeting 5 3 bfb912e5-f560-11e eefab05e57d 53

54 PXC (Galera cluster) is a meeting 5 4 bfb912e5-f560-11e eefab05e57d 54

55 PXC (Galera cluster) is a meeting

56 PXC (Galera cluster) is a meeting 5 6??? 56

57 5 7 New meeting! 4fd8824d-ad5b-11e d6929be5cf 57

58 Cluster Reads Reads are always Local Stale Reads can be allowed or disallowed 58

59 Cluster Writes Write on one node or Write Anywhere Certification Based Replication Communication on Commit only Asynchronous Application Parallel Replication 59

60 Transaction Commit Flow 60

61 Loss of connectivity Quorum 6 1 Network Problem Does not accept Reads & Writes 61

62 Automatic Node Provisioning 6 2 new node joining data is copied via SST or IST writes writes writes 62

63 Automatic Node Provisioning 6 3 when ready new node joining writes writes writes writes 63

64 Dedicated shared HAProxy 6 4 application server 1 application server 2 application server 3 HA PROXY PXC node 1 PXC node 2 PXC node 3 64

65 HAProxy on application side 6 5 application server 1 application server 2 application server 3 HA PROXY HA PROXY HA PROXY PXC node 1 PXC node 2 PXC node 3 65

66 Scaling Writes? Shard over PXC Cluster rather than MySQL Replicas 66

67 Thinks To Keep in Mind Use Innodb storage engine Primary Key on all tables Avoid Large write transactions (changing many rows) Plan Data size for SST time correctly Hot Rows Optimistic Locking 67

68 MySQL Group Replication Similar to Galera Currently in Development Better integrated with MySQL No Automated provisioning (yet) 68

69 MySQL Cluster Mostly In Memory Storage Synchronous Replication Pessimistic Locking Conflict Detection with Async Replication Niche Use Only 69

70 New Developments MySQL Fabric MySQL Router MariaDB Max Scale 70

71 Percona Live 2016 call for papers is Open 7 1 Call for Papers Open until November 29, 2015 MySQL, MongoDB, NoSQL, Data in The Cloud Anything to make Data Happy! 71

72 Thank You! Peter Zaitsev P.S We re Hiring 72