High Availability in GCE
summary
Migration moves MySQL from a Tennessee data center to GCE using MHA for topology and ProxySQL on each app host to route traffic; MaxScale and Orchestrator are tested but ProxySQL wins for MySQL protocol features. Backups use Percona xtrabackup/XBstream and gsutil/trickle, with Aspera cutting a >10‑day transfer to under 3 hours and a 2 TB slave standing up in <8 hours. Failovers keep sub-20s windows (previously 7–11s on‑prem), PT‑heartbeat monitors lag, and remaining issues are no GCE VIP and ~10 ms cross‑region latency. ProxySQL tiled per-app MHA for differential relay logs Aspera transfer <3 hours
AI-written summary · about
chapters (18)
- 0:00High availability migration intro
- 1:04Current data center infra
- 3:51Motivation for moving to Google Cloud
- 7:45Business mandate and tech
- 10:50Cloud SQL failover limits
- 13:41Topology split and traffic
- 16:50ProxySQL config and features
- 18:56MHA vs Orchestrator eval
- 21:24MHA setup and failover
- 25:49Moving DBs to GCE challenges
- 28:15Aspara for large transfers
- 31:26Network throttling fixes
- 33:11Final HA and failover plan
- 36:44Current HA architecture
- 38:10New issues and perf notes
- 41:01On-prem vs GCE perf
- 43:11Migration progress and steps
- 46:12Q&A
related talks
53mMySQL in the Cloud: DBaaS vs Kubernetes
28mMove to Managed Databases
35mMySQL HA, Recovery and Load Balancing
32mBest Practice in Design and Implementing MySQL Geographic Distributed, High Availability Solutions
41mCase Study: Deploying a Multi-Region, Highly Available MySQL Architecture
37mScale MySQL beyond limits with ProxySQL
40mCloud Databases: Pros and Cons
29mRunning MySQL on AWS