Percona XtraDB Cluster MySQL Scaling and High Availability with PXC 5.7 Tibor Korocz

Transcription

1 Percona XtraDB Cluster MySQL Scaling and High Availability with PXC 5.7 Tibor Korocz Architect Percona University Budapest Percona

2 Scaling and High Availability (application) 2

3 Scaling and High Availability (application) 3

4 Scaling and High Availability (application) - Application does not change too often (static) - If we need more performance we adding more resources - Easy to scale and achieve High Availability But what happens with the database? 4

5 Scaling and High Availability (database) - We have to distribute all the changes to all the server in real time. - It has to be available for all the applications - The application has to be able to do changes 5

6 Traditional Replication server-centric, one server streams the data to another one 6

7 Topologies 7

8 Topologies 8

9 Async - Master writes the events in the binary log - Slave request them - Master does not know whether or when a slave has retrieved and processed them - If the master crashes, transactions that it has committed might not have been transmitted to any slave - Failover might cause data loss 9

10 Data-centric The data is synchronised between servers, data-centric 10

11 Virtual Synchronous - "synchronous" guarantees that if changes happened on one node of the cluster, they happened on other nodes synchronously" - It is always highly available (no data loss) - Data replicas are always consistent - Transactions can be executed on all nodes in parallel - No complex, time-consuming failovers 11

12 Virtual Synchronous 12

13 Certification-based replication - A transaction executes conventionally until it reaches the commit point, assuming there is no conflict. This is called optimistic execution. - Each transaction has a global ordinal sequence number. - At COMMIT all changes made to the database collected into a write-set - Sends the write-set to all the other nodes. - The write-set then undergoes a deterministic certification test, using the primary keys. - It determines whether or not the node can apply the write-set. The procedure is deterministic and all replica receive transactions in the same order. Thus, all nodes reach the same decision about the outcome of the transaction. The node that started the transaction can then notify the client application whether or not it has committed the transaction. 13

14 Traditional Locking 14

15 Optimistic Locking 15

16 Galera - Database Management System (DBMS) The database server that runs on the individual node. Galera Cluster can use MySQL or MariaDB. - wsrep API The interface and the responsibilities for the database server and replication provider. - Galera Replication Plugin The plugin that enables write-set replication service functionality. - Group Communication plugins The various group communication systems available to Galera Cluster. Example: gcomm 16

17 Percona XtraDB Cluster Percona XtraDB Cluster is based on Percona Server running with the XtraDB storage engine. It uses the Galera library, which is an implementation of the write set replication (wsrep) API developed by Codership Oy. The default and recommended data transfer method is via Percona XtraBackup. 17

18 Percona XtraDB Cluster 18

19 Percona XtraDB Cluster 19

20 Percona XtraDB Cluster 20

21 Percona XtraDB Cluster 21

22 Percona XtraDB Cluster 22

23 Percona XtraDB Cluster 23

24 Percona XtraDB Cluster 24

25 Percona XtraDB Cluster 25

26 Percona XtraDB Cluster 26

27 Percona XtraDB Cluster 27

28 Flow Control - Feedback mechanism for replication process - Ability of any node in the cluster to ask the rest of the nodes to pause writes while it catches up - It can pause the entire cluster!! wsrep_local_recv_queue > fc_limit 28

29 Limitations - Only InnoDB tables are supported (MyISAM alpha) - Optimistic locking - The weakest node limits the write performance - All tables should have a Primary Key. (wsrep_certify_nonpk=1, in last resort ) - Large transaction are not recommended, specially if you write multiple nodes simultaneously - Data hotspots - Lock Tables, GET_LOCK() 29

30 What is Percona XtraDB Cluster NOT? - Not a Write-scalable solution - Not good for large transactions - Not great for working with Foreign Keys (optimistic locking) - Not good for sharding 30

31 What is Percona XtraDB Cluster good for? - Easy to scale the reads with PXC - Data consistency - Easy Failover - No data loss if server crashes - Easy to add/remove a node (auto provisioning) 31

32 State Transfer Full data SST New node Node long time disconnected Incremental IST Node disconnected short time 32

33 Snapshot State Transfer Mysqldump Small database Rsync Donor disconnected for copy time Faster Xtrabackup Donor available Slower 33

34 Adding a node 34

35 Adding a node 35

36 Loadbalancing HAproxy Automatic Donor/Failover detection Automatic write distribution Stand alone or like a service on the app server Layer 4 loadbalancer ProxySQL Like HAproxy but Layer 7 Know the MySQL protocol Read/Write splitting 36

37 ProxySQL Developed by René Cannaò Knows the MySQL protocol Query Routing (read/write splitting) Supports Failover Query caching Query rewrite Available in Percona repository 37

38 PXC with ProxySQL 38

39 PXC with ProxySQL 39

40 Quorum Split-brain protection 40

41 Quorum Split-brain protection 41

42 Quorum Split-brain protection 42

43 Quorum Split-brain protection 43

44 Quorum Split-brain protection 44

45 Geographic distribution - Segments 45

46 Async Slave 46

47 Backup Logical mysqldump mydumper Binary Xtrabackup MySQL Enterprise Backup Point to Time recovery binary logs 47

48 Always use the newest PXC version 48

49 Questions? Percona

50 DATABASE PERFORMANCE Database Performance Matters MATTERS 50