Is Percona XtraDB Cluster Right for Any Application
summary
Percona XtraDB Cluster uses Galera to provide synchronous replication and automatic provisioning; it requires InnoDB tables with primary keys and converts MyISAM before migration. Typical deployments are three nodes (can lose one) or five nodes (can lose two); a single remaining node without quorum stays up but refuses queries. Flow control defaults to stalling writes after 16 queued transactions (tuneable) and long-running transactions or hotspots cause costly rollbacks; use Percona Server slow query logs, aggregation/digest and donor desync for backups.
AI-written summary · about
chapters (17)
- 0:00Percona XtraDB Cluster intro
- 1:45Traditional MySQL replication limits
- 3:10How PXC solves replication issues
- 5:41What makes PXC unique
- 7:08High availability with PXC
- 8:32Node failures and quorum
- 12:54Scaling clusters
- 14:41PXC limitations and requirements
- 15:44Optimistic locking conflicts
- 19:20Flow control in PXC
- 24:31Workload suitability for PXC
- 26:00Detecting hotspots and long transactions
- 29:17How PXC replication works
- 31:47Synchronous replication latency
- 33:37Performance and parallelism
- 34:20Multi-DC deployments
- 36:32Q&A
related talks
35mMySQL HA, Recovery and Load Balancing
47mMeet Percona XtraDB Cluster 5.7
56mDeploying MySQL on Kubernetes & Openshift
58m600k QPS on MySQL Galera cluster
52mBest Practices for MySQL High Availability in 2022
31mOpen Source Databases on Kubernetes: Best Practices
51mMariaDB Scaling - From Single Instance to Multiple Clusters
15mPercona Database Distributions - An Overview
