Experiences using gh-ost in a multi-tier topology
summary
gh-ost runs in multi‑tier setups by reading binlogs (requires ROW format and sometimes log_slave_updates) and can run against masters or slaves to offload work; use flags like assume-master, echo throttle and --panic-file to control chunk size, pause/resume, and emergency stop. A 1M‑row table comparison shows ALTER takes ~25s but creates 25s replication lag, pt‑OSC ~35s, gh‑ost ~40s while keeping replicas consistent. Limitations: needs a shared unique key, no triggers/foreign keys or some MySQL‑5.7 types, and dropping the old table can stall the server so delete rows slowly.
AI-written summary · about
chapters (9)
- 0:00gh-ost and multi-tier topology
- 2:05gh-ost commands and use cases
- 4:37gh-ost with Tungsten Replicator
- 7:09MariaDB replication with gh-ost
- 8:34Daisy chain replication and slaves
- 10:20Post-cutover best practices
- 11:02gh-ost vs other tools
- 12:29gh-ost limitations
- 13:31Q&A
related talks
32mHow GH-OST Saved Our Deployments
35mMySQL HA, Recovery and Load Balancing
49mMySQL Replication — Advanced Features
39mBreakout Session
53mMySQL replication setup, benefits, limitations
24mComparing the High Availability of MySQL with Modern Distributed SQL Databases
29mMySQL Performance for DevOps
39mZero-Downtime Rebalancing and Data Migration of a Mature Multi-Shard Platform