Using MySQL Distrivuted Database Architectures

Percona首席执行官Peter Zaitsev于2018年3月9日在加州帕萨迪纳举行的16倍规模会议上展示了“使用MySQL实现分布式数据库架构”。

展开查看详情

1. Using MySQL for Distributed Database Architectures Peter Zaitsev CEO, Percona SCALE 16x, Pasadena, CA March 9, 2018 © 2018 Percona. 1

2.About Percona Solutions for your success with MySQL,MariaDB and MongoDB Support, Managed Services, Consulting, Training, Software Our Software is 100% Free and Open Source Support Broad Ecosystem – MySQL, MariaDB, Amazon RDS, Google CloudSQL In Business for 11 years More than 3000 customers, including top Internet companies and enterprises © 2018 Percona. 2

3.Presentation Cover Basics Why Going Distributed How to do it © 2018 Percona. 3

4.Distributed ? MySQL Deployment on More than one System © 2018 Percona. 4

5.Modern MySQL Scalability © 2018 Percona. 5

6.Single MySQL Instance Can Do Hundreds of Thousands of Queries/Sec Tends of Thousands of Updates/Sec Traverse Tens of Millions of Rows/Sec Comfortably Handle Several TB Database size © 2018 Percona. 6

7.Lets Do Some Math 100.000 QPS 10 Queries per User Interaction 10.000 User Interactions/sec 864.000.000 User Interactions/Day 30 User Interactions/User Avg 28.000.000 Daily Active Users Possible 15M of Daily Active Users counting time of day skew © 2018 Percona. 7

8.Distributed Systems Tend To be More Complicated to Develop Against More Complicated to Operate Have Additional Performance Bottlenecks Have Complicated Failure Modes © 2018 Percona. 8

9.With All of this ? Why “Go Distributed” ? © 2018 Percona. 9

10.Reasons to “Go Distributed” High Data Scalability Availability Distribution © 2018 Percona. 10

11.High Availability with MySQL Cold Standby (ie DRBD) Failover (Classical Replication) Active-Active Clustering (PXC, MySQL Group Replication) © 2018 Percona. 11

12.Q1:What Failure Modes Do you Consider ? Server Crash/Server Hardware Failure Software Bugs and Storage Corruption Network Failure “Datacenter” Failure Developer Mistakes/Intruder Actions © 2018 Percona. 12

13.Q2:What Data Am I allowed to loose ? Limited Data Loss Allowed No Data Loss No Transactions In Flight Loss © 2018 Percona. 13

14.Q3:How Quickly do you need to Recover ? “Immediate?” “Seconds?” “Minutes?” “Hours?” © 2018 Percona. 14

15.Speed of Light Realities Data •Synchronous – Slow Propagation •Asynchronous – Can Be Data Loss Can Occur © 2018 Percona. 15

16.Scalability Scaling Scaling Scaling Reads Writes Data Size © 2018 Percona. 16

17.Data Distribution Some Data Must be in •User Latency Reasons Specific •Legal and Compliance Geographic Reasons Location © 2018 Percona. 17

18.Distributed Architectures with MySQL © 2018 Percona. 18

19.Main Concepts Replication Sharding Failover Management Traffic Management © 2018 Percona. 19

20.Replication Having Multiple Copies of the data, updated with changes © 2018 Percona. 20

21.Availability Service Stays up when component fails © 2018 Percona. 21

22.Availability via Redundancy Have more than one system Works well for stateless systems Is not enough for databases © 2018 Percona. 22

23.Availability via Replication Redundant Paired with Computing Replicated Resource Data © 2018 Percona. 23

24.Where Replication Happens Storage Level Database Level Application Level © 2018 Percona. 24

25.Storage Level Replication Replication in SAN/NAS, DRBD Typically provides cold standby Simple choice which works with many systems Amazon Aurora – Smart Storage © 2018 Percona. 25

26.Database level Most Flexible Most Common Hot/Warm Spare Some can do Active-Active © 2018 Percona. 26

27.Application Level Hard to get right Rarely used, especially “used right” Partial Replication/Syncronization Smart conflict resolution Cross Vendor Redundancy © 2018 Percona. 27

28.Sharding Split data set by certain criteria and store such “shards” on separate “clusters” © 2018 Percona. 28

29.Typical Sharding By User By Customer Account/Company © 2018 Percona. 29