Skip to content

v3.4.0 — HA / automatic failover feature removed

Choose a tag to compare

View all tags
@X4Applegate X4Applegate released this 19 Apr 20:50
· 70 commits to main since this release
v3.4.0
995b28b

HA / automatic failover feature removed

The high-availability auto-failover work tracked in #13 has been fully removed from the project.

The code worked end-to-end — a CF-driven failover drill did successfully promote the standby within ~30 seconds of a simulated primary outage. But the ongoing operational cost (bidirectional MariaDB replication, promote webhook service, split-brain guard, Cloudflare Load Balancer + Notification policy, plus the manual resync procedure after every failover) is genuinely out of proportion to the uptime gains for a self-hosted status monitor.

For typical users (single-server deployments)

No action required. Core app behaviour is identical to v3.3.5:

  • same check loop, same DB schema, same APIs, same dashboards
  • no migration, no config changes, no downtime
  • upgrade is literally docker compose pull && docker compose up -d

Removed

  • backend/server.js — REPLICA_MODE / IS_REPLICA env flag, the @@global.read_only probe in initDB(), the createDatabaseTable/clearExpired gating on MySQLStore, and the if (!IS_REPLICA) guard around the check loop + scheduled weekly report. The server now unconditionally initialises its schema, runs the check loop, and fires the weekly report — matching pre-HA behaviour.
  • scripts/promote-replica.sh
  • scripts/promote-webhook.js
  • scripts/promote-webhook.service
  • scripts/promote-webhook.env.example
  • docs/HIGH_AVAILABILITY.md
  • docker-compose.replica.example.yml
  • docker-compose.example.yml — stripped of HA-specific commented blocks
  • README.md — removed HA work-in-progress banner

Commit: 995b28b (−2,423 / +34 lines)

If you were running the HA pair

Standby box (typically the one with REPLICA_MODE=1 in its .env):

  • sudo systemctl disable --now promote-webhook
  • sudo rm /etc/systemd/system/promote-webhook.service /etc/status-server/promote-webhook.env
  • STOP SLAVE; RESET SLAVE ALL; on its MariaDB to cut replication
  • the box can be powered off, repurposed, or kept as a backup-dump target

Primary box:

  • remove replication command: flags from the mariadb service in your local compose
  • remove the ports: 3306 exposure if you added one
  • RESET MASTER; on MariaDB if you want the binlogs gone (optional)

Cloudflare:

  • delete the Load Balancer(s) and their pools
  • delete the Notification policy + webhook destination
  • point the hostname that was fronting the LB at a plain A/CNAME to the primary's tunnel

.env:

  • delete any REPLICA_MODE=… line if present (the code no longer reads it, but tidiness helps)

Recommended replacement for redundancy-minded operators

A cron job on a second box pulling hourly mysqldump --single-transaction snapshots of status_monitor, with DNS-swing recovery on hard primary loss. ~15–30 min RTO vs. ~30 s, at roughly 10% of the day-to-day complexity cost.

Resurrection

Anyone who wants the HA code back can cherry-pick any commit up to 70e4f52. The scripts/*, docs/HIGH_AVAILABILITY.md, and docker-compose.replica.example.yml files live in history — nothing is destroyed.

Assets 2
Loading