Slide 1

Slide 1 text

2 © The Pythian Group Inc., 2018 June 21, 2018 - DataOps Barcelona Barcelona, Spain Implementing MySQL Database-as-a-Service using Open Source tools Matthias Crauwels

Slide 2

Slide 2 text

© The Pythian Group Inc., 2018 3 Who am I?

Slide 3

Slide 3 text

© The Pythian Group Inc., 2018 4 4 © The Pythian Group Inc., 2017 Matthias Crauwels ● Living in Ghent, Belgium ● Bachelor Computer Science ● ~20 years Linux user / admin ● 10+ years PHP developer ● 5+ years MySQL DBA ● ~1 year at Pythian as MySQL Database Consultant ● Father of Leander

Slide 4

Slide 4 text

© The Pythian Group Inc., 2018 5 © The Pythian Group Inc., 2018 5 PYTHIAN A global IT company that helps businesses leverage disruptive technologies to better compete. Our services and software solutions unleash the power of cloud, data and analytics to drive better business outcomes for our clients. Our 20 years in data, commitment to hiring the best talent, and our deep technical and business expertise allow us to meet our promise of using technology to deliver the best outcomes faster.

Slide 5

Slide 5 text

6 © 2018 Pythian. Confidential AI / ML / BLOCKCHAIN Intelligent analytics and decision making Software autonomy Disruptive data technologies CLOUD MIGRATION & OPERATIONS Plan, Migrate, Manage, Optimize, Innovate Multi-cloud, Hybrid-Cloud, Cloud Native ANALYTIC DATA SYSTEMS Kick AaaS cloud-native, pre-packaged analytics platform Custom analytics platform design, implementation and support services–for on-premises and cloud Data science consulting and implementation services OPERATIONAL DATA SYSTEMS Database services–architecture to ongoing management On prem and in the cloud Oracle, MS SQL, MySQL, Cassandra, MongoDB, Hadoop, AWS/Azure/Google DBaaS

Slide 6

Slide 6 text

7 © The Pythian Group Inc., 2018 AGENDA 7 ● Introduction ● History ● Database-as-a-Service: Frontend solution ● Database-as-a-Service: Backend management ● Overview ● Questions

Slide 7

Slide 7 text

8 © The Pythian Group Inc., 2018 Let’s get started!

Slide 8

Slide 8 text

9 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 9 You start a new application, in many cases on a LAMP stack ● Linux ● Apache ● MySQL ● PHP Everything on a single server! History

Slide 9

Slide 9 text

10 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 10 Your application grows… What do you do? You buy a bigger server! History

Slide 10

Slide 10 text

11 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 11 You application grows even more! Yay! You buy more servers and split your infrastructure! History Database Web server File server

Slide 11

Slide 11 text

12 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 12 Your application grows even more! ● You scale up the components ● Web servers are easy, just add more and load balance ● File servers are easy, get more/bigger disks, implement RAID solutions, ... ● What about the database?? ■ More servers? ● Ok but what about the data? ■ I want all my web servers to see the same data. ● Writing it on all the servers? Overhead! History

Slide 12

Slide 12 text

13 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 13 MySQL replication! ● Writing to master ● Reading from replica’s (slaves) History

Slide 13

Slide 13 text

14 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 14 Million dollar questions ● How do we know what server is the master? ● How do we know which servers are the replica’s? ● How do we manage this replication topology? ● What if the master goes down? ● What about maintenance? ● … History

Slide 14

Slide 14 text

15 © The Pythian Group Inc., 2018 Database-as-a-Service Frontend Solution

Slide 15

Slide 15 text

16 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 16 ProxySQL

Slide 16

Slide 16 text

17 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 17 ProxySQL is a high performance layer 7 proxy application for MySQL. ● It provides ‘intelligent’ load balancing of application requests onto multiple databases ● It understands the MySQL traffic that passes through it, and can split reads from writes. ● It understands the underlying database topology, whether the instances are up or down ● It shields applications from the complexity of the underlying database topology, as well as any changes to it ● ... ProxySQL: what?

Slide 17

Slide 17 text

18 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 18 ● Hostgroup All backend MySQL servers are grouped into hostgroups. These “hostgroups” will be used for query routing. ● Query rules Query rules are used for routing, mirroring, rewriting or blocking queries. They are at the heart of ProxySQL’s functionalities ● MySQL users and servers These are configuration items which the proxy uses to operate ProxySQL: terminology

Slide 18

Slide 18 text

19 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 19 ProxySQL: basic design (1)

Slide 19

Slide 19 text

20 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 20 ProxySQL: basic design (2)

Slide 20

Slide 20 text

21 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 21 ProxySQL: internals

Slide 21

Slide 21 text

22 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 22 ProxySQL will be configured to share configuration values with its peers. Currently all instances are equal and can be used to reconfigure, there is no “master” or “leader”. This a feature on the roadmap. Helps to: ● avoid your ProxySQL instance to be the single point of failure ● avoid having to reconfigure every ProxySQL instance on the application server ProxySQL: clustering

Slide 22

Slide 22 text

23 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 23 ProxySQL exists between the application and the database. ● It hides the complexity of the database topology to the application ● It knows which server is the master and which are the slaves ● It will not make changes to the topology so topology management is not solved with this product. ● It has support for gracefully taking a server out of service ● It is easy to configure ● It can be clustered for not being a single-point-of-failure ProxySQL: conclusions

Slide 23

Slide 23 text

24 © The Pythian Group Inc., 2018 Question about ProxySQL?

Slide 24

Slide 24 text

25 © The Pythian Group Inc., 2018 Database-as-a-Service Backend management

Slide 25

Slide 25 text

26 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 26 Orchestrator

Slide 26

Slide 26 text

27 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 27 Orchestrator is a High Availability and replication management tool. It can be used for: ● Discovery of a topology ● Visualisation of a topology ● Refactoring of a topology ● Recovery of a topology Orchestrator: what?

Slide 27

Slide 27 text

28 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 28 Orchestrator can (and will) discover your entire replication technology as soon as you connect it to a single server in the topology. It will use SHOW SLAVE HOSTS, SHOW PROCESSLIST, SHOW SLAVE STATUS to try and connect to the other servers in the topology. Requirement: the orchestrator_topology_user needs to be created on every server in the cluster so it can connect. Orchestrator: discovery

Slide 28

Slide 28 text

29 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 29 Orchestrator comes with a web interface that visualizes the servers in the topology. Orchestrator: visualization

Slide 29

Slide 29 text

30 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 30 Orchestrator can be used to refactor the topology. This can be done from the command line tool, via the API or even via the web interface by dragging and dropping. You can do things like ● Repoint a slave to a new master ● Promote a server to a (co-)master ● Start / Stop slave ● ... Orchestrator: refactoring

Slide 30

Slide 30 text

31 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 31 All of these features are nice, but they still require a human to execute them. This doesn’t help you much when your master goes down at 3AM and you get paged to resolve this. Orchestrator can be configured to automatically recover your topology from an outage. Orchestrator: recovery

Slide 31

Slide 31 text

32 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 32 To be able to perform a recovery, Orchestrator first needs to detect a failure. As indicated before Orchestrator connects to every server in the topology and gathers information from each of the instances. Orchestrator uses this information to make decisions on the best action to take. They call this the holistic approach. Orchestrator: how recovery works?

Slide 32

Slide 32 text

33 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 33 Orchestrator: failure detection example

Slide 33

Slide 33 text

34 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 34 Orchestrator was written with High Availability as a basic concept. You can easily run multiple Orchestrator instances with a shared MySQL backend. All instances will collect all information but they will allow only one instance to be the “active node” and to make changes to the topology. To eliminate a single-point-of-failure in the database backend you can use either master-master replication (2 nodes) or Galera synchronous replication (3 nodes). Orchestrator High Availability

Slide 34

Slide 34 text

35 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 35 Since version 3.x of Orchestrator there is “Orchestrator-on-Raft”. Orchestrator now implements the ‘raft consensus protocol’. This will ● Ensure that a leader node is elected from the available nodes ● Ensure that the leader node has a quorum (majority) at all times ● Allow to run Orchestrator without a shared database backend ● Allow to run without a MySQL backend but use a sqlite backend Orchestrator High Availability

Slide 35

Slide 35 text

36 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 36 A common example of a High Availability setup ● 3 Orchestrator nodes in different DC’s ● Often one primary DC, one backup DC and one “arbitrator” node in a cloud DC. ● Orchestrator developers have made changes to raft protocol to allow ■ leader to step down ■ other nodes to yield to a certain node to become the leader ● Shlomi Noach from GitHub will definately go into more detail on how they implemented this at GitHub. Orchestrator High Availability

Slide 36

Slide 36 text

37 © The Pythian Group Inc., 2018 Questions about Orchestrator?

Slide 37

Slide 37 text

38 © The Pythian Group Inc., 2018 Overview

Slide 38

Slide 38 text

39 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 39 Architecture overview APP(S) Leader

Slide 39

Slide 39 text

40 © The Pythian Group Inc., 2018 Questions?

Slide 40

Slide 40 text

41 © The Pythian Group Inc., 2018 Credits

Slide 41

Slide 41 text

42 © The Pythian Group Inc., 2018 © The Pythian Group Inc., 2018 42 Credits go to: ● René Cannaò and Derek Downey for the images on ProxySQL internals and overview. Taken from their “ProxySQL Tutorial” on Percona Live 2016. ● Shlomi Noach for the Orchestrator screenshots taken from the Orchestrator manual and from his “Orchestrator at GitHub” blogpost. Credits

Slide 42

Slide 42 text

Contact Matthias Crauwels [email protected] +1 (613) 565-8696 ext. 1215