MySQL Replication Options Peter Zaitsev, CEO, Percona Moscow MySQL User Meetup Moscow,Russia
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
In This Presentation Why Replication? How to think about Replication Overview of what MySQL Has to Offer 3
Replication Having Multiple Copies of the data, updated with changes 4
Why Replication Availability Scalability Performance 5
Availability Service Stays up when component fails 6
Availability via Redundancy Have more than one system Works well for stateless systems Is not enough for databases 7
Availability via Replication Redundant Computing Resource Paired with Replicated Data 8
Component Failure Node Failures Total Crash Process Crash Stall/Unresponsive Consistency Issues Network Failures Single Port Failures Partitions Complicated Failures 9
Scalability Scales Reads Does not Scale Writes very well Data Distribution is needed for scaling writes 10
Performance Reduce response time by maintaining replica closer to user 11
Talking about Full Database Replication System of Record Partial Database Replication Can be used as Cache Synchronization of Client Data 12
Where Replication Happens Storage Level Database Level Application Level 13
Storage Level Replication Replication RAID Typically provides cold standby Simple choice which works with many systems Amazon Aurora Smart Storage 14
Database level Most Flexible Most Common Hot/Warm Spare Some can do Active-Active 15
Application Level Hard to get right Rarely used, even more so used right Partial Replication/Syncronization Smart conflict resolution Cross Vendor Redundancy 16
Replication Properties 17
Number of Writable Nodes Single Writer (Master) Write Anywhere (Multi Master) 18
Single Master All writes go to the single node One way replication stream Simple No Conflicts Replication aware Application or Connector 19
Multiple Active Masters Can write to multiple masters Replication is multi-directional More Complicated Possibility of Conflicts 20
Sync or Async Synchronous Replication Asynchronous Replication 21
Synchronous Replication Data Persisted on Target Server Guarantees No Data Loss if Source server fails Conflicts can be easily prevented Expensive 22
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
Asynchronous Replication Anything not Synchronous Many different variants exist! 24
Asynchronous Properties Commit on Master What happens with Persistence? What happens with Visibility? 25
Persistence Uncommitted Data on Master Committed Data on Master Date in Slave s memory Data on Slave s Disk (log) 26
Visibility Results be visible by concurrent sessions before acknowledgement Phantom Reads Results can t be visible by concurrent sessions No Phantom Reads 27
Conflits No Conflict Handling Conflict Detection Conflict Resolution Conflict Prevention 28
Acknowledgements Applies both to Sync and Some Async How many node have successfully replicated data? All? One? Majority? 29
Level of Control Global Control vs Database Control Control by Writer vs Reader 30
Number of Replicas On (2 nodes) Two or more (3+ nodes) 31
2 nodes Basic Redundancy Need Help with Failure detection and Split Brain No Redundancy in case of node maintainance 32
3+ Nodes Much better Redundancy Quorum based failure handling works out of the box Can do node maintenance without redundancy loss 33
Failure Detection and Promotion Built-In Handled by External Tools 34
Replica Provisioning Manual Automatic 35
Gotchas Distributed systems are complicated. All products have their own gotchas. 36
MySQL Replication 37
Classic MySQL Replication Fully Asynchronous No Failure Detection and Promotion Manual Provisioning Can run Multi-Master No Conflict Handling 38
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
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
Making MySQL Replication Better MHA MySQL Failover PRM 41
Percona XtraDB Cluster and Galera 42
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
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
PXC Data Architecture 45
Architecture Concepts All Nodes Have Full copy of Data Every Node is Equal No Central Management No SPOF 46
Understanding Cluster The cluster can be seen as a meeting! 47
PXC (Galera cluster) is a meeting 4 8 bfb912e5-f560-11e2-0800-1eefab05e57d 48
PXC (Galera cluster) is a meeting 4 9 bfb912e5-f560-11e2-0800-1eefab05e57d 49
PXC (Galera cluster) is a meeting 5 0 bfb912e5-f560-11e2-0800-1eefab05e57d 50
PXC (Galera cluster) is a meeting 5 1 bfb912e5-f560-11e2-0800-1eefab05e57d 51
PXC (Galera cluster) is a meeting 5 2 bfb912e5-f560-11e2-0800-1eefab05e57d 52
PXC (Galera cluster) is a meeting 5 3 bfb912e5-f560-11e2-0800-1eefab05e57d 53
PXC (Galera cluster) is a meeting 5 4 bfb912e5-f560-11e2-0800-1eefab05e57d 54
PXC (Galera cluster) is a meeting 5 5 55
PXC (Galera cluster) is a meeting 5 6??? 56
5 7 New meeting! 4fd8824d-ad5b-11e2-0800-73d6929be5cf 57
Cluster Reads Reads are always Local Stale Reads can be allowed or disallowed 58
Cluster Writes Write on one node or Write Anywhere Certification Based Replication Communication on Commit only Asynchronous Application Parallel Replication 59
Transaction Commit Flow 60
Loss of connectivity Quorum 6 1 Network Problem Does not accept Reads & Writes 61
Automatic Node Provisioning 6 2 new node joining data is copied via SST or IST writes writes writes 62
Automatic Node Provisioning 6 3 when ready new node joining writes writes writes writes 63
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
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
Scaling Writes? Shard over PXC Cluster rather than MySQL Replicas 66
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
MySQL Group Replication Similar to Galera Currently in Development Better integrated with MySQL No Automated provisioning (yet) 68
MySQL Cluster Mostly In Memory Storage Synchronous Replication Pessimistic Locking Conflict Detection with Async Replication Niche Use Only 69
New Developments MySQL Fabric MySQL Router MariaDB Max Scale 70
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! http://bit.ly/pl16call 71
Thank You! Peter Zaitsev pz@percona.com P.S We re Hiring http://bit.ly/perconajobs 72