Oss4b - pxc introduction
•
3 likes•1,236 views
This document provides an introduction to parallel synchronous replication using Percona XtraDB Cluster (PXC). It discusses the limitations of traditional MySQL replication and how PXC implements a data-centric approach with synchronous multi-master replication between nodes. Key features of PXC highlighted include parallel replication, data consistency, and automatic provisioning of new nodes. The document also covers integration with load balancers and limitations to be aware of for write-intensive or large transaction workloads.
Report
Share
Oss4b - pxc introduction
- 1. OSS4B: Percona XtraDB Cluster Introduction to parallel synchronous replication Frédéric Descamps 19 Sep 2013
- 2. OSS4B: Percona XtraDB Cluster Introduction to parallel synchronous replication Frédéric Descamps 19 Sep 2013
- 3. Who am I ? • Frédéric Descamps “lefred” • @lefred • http://about.me/lefred • Percona Consultant since 2011 • Managing MySQL since 3.23 (as far as I remember) • devops believer 3
- 4. Agenda • Percona • MySQL Replication • Galera & PXC 4
- 5. Percona • We are the oldest and largest independent MySQL Support, Consulting, Remote DBA, Training, and Software Development company with a global, 24x7 staff of nearly 100 serving more than 2,000 customers in 50+ countries since 2006 ! • Our contributions to the MySQL community include open source server and tools software, books, and original research published on the MySQL Performance Blog. 5
- 6. MySQL Replication 6 If your HA is based on MySQL Replication - You may play a dangerous game !
- 7. Traditional Replication Approach Server-centric : “one server streams data to another” 7 Server 1 Server 2 replication stream “master” “slave”
- 8. This can lead to cool topologies ! 8 1 2 3 4 5 6 7 8 9 10 1213 14 15 16 17 18 19 11
- 9. This can lead to cool topologies ! 9 1 2 3 4 5 6 7 8 9 10 1213 14 15 16 17 18 19 11 If node 4 crashes do we still have a cluster ?
- 10. This can lead to cool topologies ! 10 1 2 3 4 5 6 7 8 9 10 1213 14 15 16 17 18 19 11If node 3 crashes and clients failover to 2, how 3 joins back ?
- 11. This can lead to cool topologies ! 11 1 2 3 4 5 6 7 8 9 10 1213 14 15 16 17 18 19 11 How do we backup the cluster ?
- 12. Galera (wsrep) Approach 12 DATA Server 1 Server 2 Server 3 Server N... The dataset is synchronized between one or more servers: data-centric
- 13. Data-centric • Data does not belong to a node • Node belongs to data ! 13
- 14. What is Percona XtraDB Cluster ? • Percona Server • + WSREP patches • + Galera library • + utilities (init, SST and cluster check scripts) 14
- 15. Percona Server • This is a free open source solution, Percona Server is a MySQL alternative which offers breakthrough performance, scalability, features, and instrumentation. Self-tuning algorithms and support for extremely high- performance hardware make it the clear choice for organizations that demand excellent performance and reliability from their MySQL database server. 15
- 16. WSREP and Galera • WSREP API is a project to develop generic replication plugin interface for databases (WriteSet Replication) • Galera is a wsrep provider that implements true multi-master vritually synchronous replication 16
- 17. What is Percona XtraDB Cluster ? 17 Full compatibility with existing systems
- 18. What is Percona XtraDB Cluster ? 18 Minimal efforts to migrate
- 19. What is Percona XtraDB Cluster ? 19 Minimal efforts to return back to MySQL
- 22. (Virtual) Synchronous Replication • Different from asynchronous MySQL replication: – Writesets (tx) are replicated to all available nodes on commit (and en- queued on each) – Writesets are “certified” on every node – En-queued writesets are applied on those nodes independently and asynchronously 22
- 25. Multi-Master Replication • You can write to any node in your cluster • Don't worry about eventual out-of-sync 25 writes writes writes
- 27. Parallel Replication • Standard MySQL 27 Writes N threads Apply 1 thread
- 28. Parallel Replication • PXC / Galera 28 Writes N threads Apply M threads
- 30. Data Consistency • Writesets (transactions) are either applied on every node or not at all ! • Watch out split brain situation (minimum is 3 nodes) 30
- 32. Automatic Node Provisioning • When a node joins the cluster, the data is automatically copied and when finished the new node is automatically ready and accepting connections • The node provisioning can be divided in 2 different approaches: – SST (state snapshot transfer): full copy of the data – IST (incremental state transfer): send only the missing writesets (if available) 32
- 33. StateTransfer Summary 33 Full data SST Incremental IST New node Node long time disconnected Node disconnected short time
- 34. Snapshot State Transfer 34 mysqldump Small databases rsync Donor disconnected for copy time Faster XtraBackup Donor available Slower
- 35. Incremental State Transfer 35 Node was in the cluster Disconnected for maintenance Node crashed
- 36. Automatic Node Provisioning 36 writes writes writes new node joining data is copied via SST or IST
- 37. Automatic Node Provisioning 37 writes writes writes new node joiningwhen ready writes
- 38. Understanding Galera 38 The cluster can be seen as a meeting !
- 39. PXC (Galera cluster) is a meeting 39 bfb912e5-f560-11e2-0800-1eefab05e57d
- 40. PXC (Galera cluster) is a meeting 40 bfb912e5-f560-11e2-0800-1eefab05e57d
- 41. PXC (Galera cluster) is a meeting 41 bfb912e5-f560-11e2-0800-1eefab05e57d
- 42. PXC (Galera cluster) is a meeting 42 bfb912e5-f560-11e2-0800-1eefab05e57d
- 43. PXC (Galera cluster) is a meeting 43 bfb912e5-f560-11e2-0800-1eefab05e57d
- 44. PXC (Galera cluster) is a meeting 44 bfb912e5-f560-11e2-0800-1eefab05e57d
- 45. PXC (Galera cluster) is a meeting 45 bfb912e5-f560-11e2-0800-1eefab05e57d
- 46. PXC (Galera cluster) is a meeting 46
- 47. PXC (Galera cluster) is a meeting 47 ???
- 48. PXC (Galera cluster) is a meeting 48 4fd8824d-ad5b-11e2-0800-73d6929be5cf New meeting !
- 49. Why using a PXC ? • High Availability ! • Works perfect with a load balancer (like Ha proxy) • WAN replication is also possible but adds some delay to commit latency (100-300ms) 49
- 50. PXC with a Load balancer • PXC can be integrate with a load balancer and service can be checked using clustercheck or pyclustercheck • The load balancer can be a dedicated one • or integrated on each application servers 50
- 51. Dedicated shared HAProxy application server 1 application server 2 application server 3 PXC node 1 PXC node 2 PXC node 3 HA PROXY
- 52. Dedicated shared HAProxy application server 1 application server 2 application server 3 PXC node 1 PXC node 2 PXC node 3 HA PROXY
- 53. Dedicated shared HAProxy application server 1 application server 2 application server 3 PXC node 1 PXC node 2 PXC node 3 HA PROXY SST available_when_donor=0
- 54. HAProxy on application side
- 56. WAN replication MySQL MySQL MySQL Works fine Use higher timeouts and send windows No impact on reads No impact within a transaction Increase commit latency
- 57. WAN replication - latencies MySQL MySQL MySQL Beware of latencies Within EUROPE EC2 – INSERT INTO table: 0.005100 sec EUROPE <-> JAPAN EC2 – INSERT INTO table: 0.275642 sec
- 58. WAN replication with MySQL asynchronous replication MySQL MySQL MySQL You can mix both replications Good option on slow WAN link Requires more nodes If binlog position is lost, full cluster must be reprovisioned MySQL MySQL MySQL MySQL MySQL MySQL
- 59. So, is Percona XtraDB Cluster a perfect solution ? 59 Limitations
- 60. Limitations Supports only InnoDB tables – MyISAM support is very basic and will stay in alpha. Different locking: optimistic locking The weakest node limits the write performance For write intensive applications there could be datasize limit per node All tables must have a Primary Key !
- 61. Limitations (2) Large transactions are not recommended if you write on all nodes simultaneously If your application has a data hotspot then PXC may not be right for you.
- 62. OPTIMISTIC locking for transactions on different servers Traditional locking system 1 Transaction 1 Transaction 2 BEGIN Transaction1 BEGIN UPDATE t WHERE id=14 UPDATE t WHERE id=14 ... COMMIT Waits on COMMIT in trx 1
- 63. OPTIMISTIC locking for transactions on different servers Optimistic locking system 1 Transaction 1 Transaction 2 BEGIN Transaction1 BEGIN UPDATE t WHERE id=14 UPDATE t WHERE id=14 ... COMMIT system 2 ... COMMIT ERROR due row conflict
- 64. Credits WSREP patches and Galera library is developed by Codership Oy Percona & Codership will present on Percona Live UK 2013, Nov 11-12 http://www.percona.com/live/london-2013/
- 65. Resources Percona XtraDB Cluster website: http://www.percona.com/software/percona-xtradb-cluster/ Codership website: http://www.codership.com/wiki/doku.php PXC articles on mysqlperformanceblog: http://www.mysqlperformanceblog.com/category/percona- xtradb-cluster/
- 66. Percona provides 24 x 7 Support Services Quick and Easy Access to Consultants Same Day Emergency Data Recovery Remote DBA Services QUOTE OSS4B for Special Consulting Offer – Free Mini Health Audit with Gold Support and Free Performance Audit with Platinum Support Valid September- October 2013 sales@percona.com or 00442081330309
- 67. Thank you ! Test it now using Vagrant ! Questions?