# Railway makes MySQL automatic failover generally available with Group Replication and HAProxy Railway has moved MySQL High Availability out of Priority Boarding and into general availability for eligible MySQL 8 and 9 services. Existing databases can be converted into odd-node Group Replication clusters behind HAProxy, with automatic primary election and project variable references rewritten during the migration. Railway’s managed MySQL path can now gain automatic failover without rebuilding the database elsewhere. The trade-off is real operational complexity: conversion briefly drops connections, hard-coded URLs need manual repair, replicas are for failover rather than read scaling, and each extra database/proxy node consumes billable resources. - Status: Active - Published: 2026-08-30T09:14:57+12:00 - Updated: 2026-08-30T09:14:57+12:00 - Categories: Cloud & Infrastructure, Cloud Platforms, Databases & Storage - Tags: database failover, high availability, MySQL, Railway - Canonical HTML: https://beyondthe.news/dossiers/railway-mysql-high-availability-ga-group-replication-haproxy-failover ## What changed Railway announced on August 28, 2026 that MySQL High Availability is generally available for eligible services using versioned official MySQL 8 or 9 images. Railway converts an existing standalone MySQL service into a single-primary Group Replication cluster, adds an even number of replicas so the total database-node count remains odd, and places HAProxy in front of the cluster as the stable connection endpoint. If the primary becomes unreachable, the remaining MySQL members elect a replacement and HAProxy begins routing new connections to it. Railway’s conversion workflow takes a backup, stages the replicas and proxy services, and rewrites variable references inside the project. The feature had previously been limited to Priority Boarding. ## Why it matters For smaller teams using Railway as an application platform, database failover previously required a separate architecture or accepting one MySQL service as a single point of failure. The GA path makes high availability an in-platform conversion rather than a database migration to another vendor. That can materially reduce operational work, but it does not make failure invisible: connections to the old primary drop during failover, clients still need reconnect logic, and the extra database and HAProxy services add resource cost and more components to monitor. ## High availability is now a conversion of the existing service An eligible MySQL service exposes a High Availability control in Railway. During conversion Railway backs up the database, provisions replicas plus HAProxy as staged changes and adopts the original data volume into the cluster. Variable references such as `MYSQL_URL` inside the same Railway project are migrated automatically to the new HAProxy service. ## MySQL itself performs membership and primary election Railway uses MySQL Group Replication in single-primary mode rather than a separate consensus coordinator. Customers can add 2, 4, 6 or 8 replicas to the original primary, producing clusters of 3, 5, 7 or 9 data nodes so a majority can be established during failures or partitions. Secondary nodes stay `super_read_only`. ## HAProxy gives applications one endpoint across failovers Clients connect through HAProxy rather than directly to a database node. When the current primary fails, Group Replication elects a new primary and HAProxy reroutes connections after its next role probe. Existing connections to the failed node are lost, so applications still need normal database reconnect/retry behavior. ## The replicas are not a read-scaling tier Railway’s current design sends all reads and writes to the primary through HAProxy. The replicas exist to preserve quorum and take over during failure; there is no separate read endpoint over secondaries. Teams that need read scaling should not assume enabling HA solves that requirement. ## Eligibility is deliberately narrow Railway supports official MySQL images with versioned MySQL 8 or 9 tags. `latest`, MariaDB, Percona and other variants are not eligible. A custom start command also blocks conversion until it is reset, because Railway’s cluster wrapper manages startup and replication configuration. ## Conversion and cost still need planning The conversion drops active connections and changes endpoints. Railway automatically rewrites project variable references, but literal connection strings in code, other Railway projects, CI systems or external tools must be updated manually. Railway bills CPU, memory, storage and egress by resource use, so multiple MySQL nodes and HAProxy services also increase the infrastructure footprint. ## The launch announcement and documentation are briefly out of sync Railway’s August 28 changelog explicitly says MySQL HA is now generally available for eligible services. The detailed documentation page still contains older Priority Boarding/beta wording in parts of the page. Builders should use the current product/changelog status for availability while validating their own dashboard eligibility before planning a production conversion. ## Key details - Railway announced general availability of MySQL High Availability on August 28, 2026. - Eligible databases must use a versioned official MySQL 8 or 9 image. - The cluster uses single-primary MySQL Group Replication plus HAProxy. - Replica choices are 2, 4, 6 or 8, producing 3-, 5-, 7- or 9-node MySQL groups. - Failover elects a new primary automatically and HAProxy routes new connections to it. - Railway rewrites variable references within the same project during conversion. - Hard-coded connection strings outside the reference system need manual updates. - All reads and writes currently go to the primary; replicas are for failover, not read scaling. - Conversion drops active connections. - Railway’s launch changelog says GA, while portions of the detailed docs still show older beta/Priority Boarding wording. ## Builder takeaways - Test application reconnect behavior before relying on automatic database failover; HAProxy can find the new primary, but it cannot preserve a connection to the failed one. - Search for literal MySQL URLs in code, CI, external tools and other projects before conversion because only Railway variable references are migrated automatically. - Use an explicit MySQL minor-version tag rather than `latest` before attempting conversion. - Run a planned failover after the cluster is healthy and measure recovery time, application errors and retry behavior on your actual workload. - Do not enable HA expecting read replicas to increase query throughput; the current architecture routes reads to the primary. - Estimate the resource cost of the full cluster—including replicas, storage and HAProxy—rather than comparing it with the price of one standalone MySQL service. ## What to watch - Railway updating its detailed documentation to consistently reflect GA status. - Published pricing examples for common three-node and larger MySQL HA configurations. - A read-replica endpoint or other read-scaling capability. - Independent reliability and failover-time evidence from production workloads. - Broader support for MySQL variants, image tags or custom startup configurations. ## Uncertainties - Railway’s current changelog declares GA while its detailed MySQL HA guide still contains stale beta/Priority Boarding wording; actual eligibility should be confirmed in the dashboard. - Railway does not publish a universal failover-time SLA in the reviewed material; recovery depends on group election, proxy probing and client reconnect behavior. - Resource cost varies with the chosen replica/proxy count and actual CPU, memory, storage and egress consumption. ## Sources - [Changelog #0305 — Railway plugin for Grok Bot, MySQL High Availability, favorite projects](https://railway.com/changelog/2026-08-28-railway-plugin-for-grok-bot) — Railway · primary_changelog · 2026-08-28T00:00:00+12:00. Primary GA announcement and conversion/failover overview. - [Upgrading MySQL to High Availability](https://docs.railway.com/databases/mysql-ha) — Railway Docs · primary_documentation. Detailed cluster architecture, eligibility, conversion, variable migration, failover, scaling, backup and revert behavior; some availability wording appears stale relative to the launch changelog. - [MySQL](https://docs.railway.com/databases/mysql) — Railway Docs · primary_documentation. Current MySQL overview linking the automatic-failover HA path. - [Pricing](https://docs.railway.com/pricing) — Railway Docs · primary_pricing. Current resource-usage pricing model used to frame the cost of additional database/proxy services.