Production with ProxySQL and Orchestrator
summary
Three concrete setups using ProxySQL and Orchestrator show how to decouple apps and run MySQL rolling changes: a central cluster with 1 master + 3 promotable slaves, 3 Orchestrator nodes in raft (sqlite backend), and 2 synchronized ProxySQL nodes behind a load balancer; failover uses sudo GTID, Orchestrator hooks, and pt-heartbeat for lag detection with a scheduler workaround for duplicate heartbeat rows. Demo forces a master kill, automatic promotion works but the old master needs manual acknowledge to rejoin and the Orchestrator UI can lag.
AI-written summary · about
chapters (13)
- 0:00Start
- 0:39Outline
- 8:18Orchestrator User
- 8:53Pseudo-GTID
- 11:52Getting Allases
- 13:57Master and Intermediate Master recovery
- 20:05Prevent Cross DC/Region failover
- 21:17High Availability through Raft
- 25:07ProxySQL Overview and Benefits
- 30:07Use the read_only check
- 32:34Configure pt-heartbeat
- 35:46Set up ProxySQL Cluster
- 39:06Dynamic Promotion
related talks
05mMySQL failover with orchestrator and ProxySQL
43mMySQL Failover for Asynchronous replication with Orchestrator, ProxySQL and Consul
08mMySQL as a Layered Service: How to use Proxy SQL to Control Traffic and Scale Out
06mRoad to Percona Live 2022 - Oleksandr Kuzminskyi - ProxySQL Talk
50m#ProxySQL Use Case Scenarios
25mRolling out a Database-as-a-Service layer at Ghent University
37mScale MySQL beyond limits with ProxySQL
56mDeploying MySQL on Kubernetes & Openshift