PureMyHA: MySQL 8.4 HA Manager in Haskell

Everyone's flocking to managed MySQL like Aurora. But what if you can't? Enter PureMyHA—a Haskell daemon that nails async replication HA without the overhead.

PureMyHA dashboard showing MySQL 8.4 cluster health metrics

Key Takeaways

  • PureMyHA fills the async HA gap for MySQL 8.4 self-hosted setups, ditching bloat like Vitess.
  • Haskell's types and concurrency make it rock-solid for failure-prone state management.
  • Single binary, Prometheus-ready, K8s probes—ops simplicity without dependencies.

Managed databases promised to kill self-hosted MySQL forever. Aurora, Cloud SQL—they handle the HA mess, right? Wrong. Latency hawks, cost-cutters, legacy infra warriors still sweat over bare-metal clusters. And with MySQL 8.4 fresh out, the toolbox feels rusty: InnoDB Cluster’s sync commits kill writes, Orchestrator’s semi-sync is barely preview, Vitess? Total overkill for three nodes.

PureMyHA changes that. It’s a lightweight MySQL 8.4 HA manager, async replication-focused, built in Haskell. No etcd dependencies. Single static binary. Daemon plus CLI, chatting over a Unix socket. Stars on GitHub? Sure, but let’s unpack why this matters.

Why Haskell for MySQL High Availability?

Haskell. Not Go, not Rust—Haskell. You’re thinking, ‘Pure functional for databases? Masochism?’ But here’s the thing: its type system catches state bugs before they crash your prod. Concurrency? Fearless, they say. In HA land, where one flipped bit means split-brain hell, that’s gold.

The builder ditched legacy MySQL cruft—no mysql_native_password, just caching_sha2_password. SHOW REPLICA STATUS, CHANGE REPLICATION SOURCE TO. Modern only. And failovers? Smart. Errant GTID repair injects empty transactions. Split-brain fencing slaps super_read_only=ON on rogues. Anti-flap cooldowns kill loops.

PureMyHA is designed to be minimal but heavily armed for production edge-cases.

That quote nails it. Not a kitchen sink. Just failover smarts.

Picture this: three replicas, async chain. Primary flakes—TCP blip or real crash? PureMyHA waits for N failures, probes deeper, promotes the lag-leader with zero data loss if GTIDs align. No drama.

How Does PureMyHA Beat the Big Boys?

Orchestrator? Percona’s got 8.4 support, but semi-sync preview screams ‘not yet.’ Vitess crushes it—for sharding empires. InnoDB Cluster? Sync writes balloon latency 2x-5x on high TPS.

PureMyHA stays async. Lightweight. Daemon (puremyhad) discovers topology, monitors lag, metrics to Prometheus. CLI (puremyha) for clones via native CLONE plugin—‘puremyha clone’ reseeds a dead node from donor. Zero downtime config via SIGHUP. Hooks for Slack, DNS flips.

Kubernetes probe? /health ready. Single binary—no debs needed beyond MySQL itself. Install, point at your cluster YAML, done.

But.

My unique take: this echoes the Mnesia era in Erlang land, 90s telecom switches where functional purity tamed distributed state. Haskell’s doing it for MySQL now—predict it’ll spark a mini-renaissance in typed DB ops tools. Companies like Jane Street already bet Haskell on finance infra; databases next?

Is PureMyHA Production-Ready for MySQL 8.4?

Short answer: yes, if ‘lightweight HA’ fits. It’s battle-tested on the builder’s setups, but open-source young. Docs exhaustive—feature ref, config samples. Dry-runs for manual switches. Pause failover mid-maintenance.

Consecutive failure thresholds dodge TCP flakes. Recovery block periods halt flap. Lag thresholds trigger hooks before failover. Granular: exclude nodes, resume anytime.

Skeptical? Fork the repo. ikaro1192/PureMyHA. Star it, hack it. But don’t sleep—async HA gap was begging this.

Corporate spin? None here. Solo dev, no VC fluff. Just solves the itch: self-hosted MySQL 8.4 without bloat.

And the arch shift? Unix philosophy reborn. Daemon lifts weights, CLI’s your remote. NDJSON over socket—fast, local, secure. No web UI cruft to vuln-scan.

Look, if you’re on IaaS with sub-ms latency needs, this slots in. Prometheus scrapes cluster health. K8s liveness. Hooks chain to PagerDuty.

Deeper: GTID errants. MySQL async chains drift—extra txns on replicas. PureMyHA sniffs ‘em, skips with empties on promote. Zero loss.

Split-brain? Multi-writes detected, fence extras read-only. Clean slate post-failover.

Why Does PureMyHA Matter for DevOps Teams?

Self-hosted ain’t dead. 40% of prod MySQL still on-prem or IaaS (per surveys). Costs 5x managed sometimes. Latency? Unbeatable.

This tool shrinks ops toil. No ZooKeeper herds. No Vitess learning cliff. Haskell compiles anywhere—static bin deploys like Docker zero.

Bold call: expect forks for Postgres, MariaDB. Haskell’s concurrency wins here.


🧬 Related Insights

Frequently Asked Questions

What is PureMyHA?

PureMyHA’s a Haskell-based HA manager for MySQL 8.4 async replication—automated failover, split-brain protection, minimal footprint.

How does PureMyHA handle MySQL failover?

Detects failures after N probes, repairs GTIDs, promotes safest replica, fences splits—zero data loss where possible.

PureMyHA vs Orchestrator?

Lighter, 8.4-native async focus; Orchestrator’s heavier, semi-sync preview lags.

Sarah Chen
Written by

AI research editor covering LLMs, benchmarks, and the race between frontier labs. Previously at MIT CSAIL.

Frequently asked questions

What is PureMyHA?
PureMyHA's a Haskell-based HA manager for MySQL 8.4 async replication—automated failover, split-brain protection, minimal footprint.
How does PureMyHA handle MySQL failover?
Detects failures after N probes, repairs GTIDs, promotes safest replica, fences splits—zero data loss where possible.
PureMyHA vs Orchestrator?
Lighter, 8.4-native async focus; Orchestrator's heavier, semi-sync preview lags.

Worth sharing?

Get the best AI stories of the week in your inbox — no noise, no spam.

Originally reported by dev.to

Stay in the loop

The week's most important stories from theAIcatchup, delivered once a week.