© 2016 Percona© 2016 Percona© 2016 Percona© 2016 Percona© 2016 Percona© 2016 Percona© 2016 Percona�1

Tibor Korocz

Percona XtraDB ClusterMySQL Scaling and High Availability with PXC 5.7

Architect 2018.04.18

Scaling and High Availability (application)

�2

Scaling and High Availability (application)

�3

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

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

Traditional Replicationserver-centric, one server streams the data to another one

�6

Topologies

�7

Topologies

�8

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

Data-centricThe data is synchronised between servers, data-centric

�10

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

Virtual Synchronous

�12

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

Expected errors

Brute force abort:Occurs when other node execute conflicting transaction and local active transaction needs to be killed. - wsrep_local_bf_aborts

Local certification failure:When 2 nodes executes conflicting workload and add it to the queue at the same time. - wsrep_local_cert_fauilers

�14

Traditional Locking

�15

Optimistic Locking

�16

- 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

Galera

�17

Percona XtraDB ClusterPercona 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.

�18

Percona XtraDB Cluster

�19

Percona XtraDB Cluster

�20

Percona XtraDB Cluster

�21

Percona XtraDB Cluster

�22

Percona XtraDB Cluster

�23

Percona XtraDB Cluster

�24

Percona XtraDB Cluster

�25

Percona XtraDB Cluster

�26

Percona XtraDB Cluster

�27

Percona XtraDB Cluster

�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

�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()…�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

�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)

�32

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

�33

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

�34

Adding a node

�35

Adding a node

�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• “Knows” the MySQL protocol• Read/Write splitting

�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

�38

PXC with ProxySQL

�39

PXC with ProxySQL

�40

Quorum▪Split-brain protection

�41

Quorum▪Split-brain protection

�42

Quorum▪Split-brain protection

�43

Quorum▪Split-brain protection

�44

Quorum▪Split-brain protection

�45

Geographic distribution - Segments

�46

Async Slave

�47

Backup▪Logical• mysqldump • mydumper ▪Binary• Xtrabackup • MySQL Enterprise Backup

▪Point to Time recovery• binary logs

�48

Always use the newest PXC version

�49

© 2016 Percona© 2016 Percona© 2016 Percona© 2016 Percona© 2016 Percona© 2016 Percona© 2016 Percona�50

Questions?

© 2018 Percona 51

Use code 10ATTENDPL18 for 10% discount!