Let’s talk
← All insights
ENGINEERING JOURNAL / Database Operations

MySQL Promotion: Check Read-Only State and Write Fencing

Prepare a self-managed MySQL promotion by checking transaction coverage, application routing, and read-only controls as one coordinated procedure.

Clouvenix Engineering notes · 4 min read · 20 Oct 2026
MySQL Promotion: Check Read-Only State and Write FencingMySQL Promotion: Check Read-Only State and Write Fencing — conceptual 3D-style vector showing Application, Writer gate, Candidate, New writes, Old source.. Conceptual teaching illustration; connections show the investigation flow rather than a vendor deployment topology.CLOUVENIX / DATABASE OPERATIONSMySQL Promotion: Check Read-Only State and Write Fencing01Application02Writer gate03Candidate04New writes05Old sourceConceptual investigation flow / MySQL Promotion: Check Read-Only State and Write Fencing
MySQL Promotion: Check Read-Only State and Write Fencing — conceptual 3D-style vector showing Application, Writer gate, Candidate, New writes, Old source.
● ● ● clouvenix / engineering-notes

Context

Promoting a MySQL replica changes who is allowed to accept business writes. Making the candidate writable is only one part of that transition. If the old source remains reachable by an application, two servers can accept incompatible histories even when the new endpoint looks healthy. A promotion runbook therefore needs an explicit write owner.

Prepare the decision

Use this guide for self-managed MySQL 8.4 asynchronous replication, with a topology owner and an established failover mechanism. Gather source and candidate identities, replication channels, transaction positions, application endpoints, and the accepted data-loss decision. Ensure that an administrator can reach each server through a separate management path. A planned switchover can coordinate a clean write stop; an unplanned failover may require an explicit acknowledgment that some transactions cannot be recovered immediately.

Promotion checkpoints

  1. Identify and fence the previous writer before directing new writes elsewhere. Fencing can involve the orchestrator, infrastructure isolation, or application access controls, depending on the design. Confirm the result from the application network. A server that is merely unreachable from the administrator is not necessarily unreachable from every application worker.
  2. Inspect candidate replication health and compare required transaction coverage with the former source where available. Read @@GLOBAL.gtid_executed when GTIDs are used and review unresolved replication errors. Capture the evidence before changing topology. A lag value or matching row count alone is insufficient evidence of transaction coverage.
  3. Read @@GLOBAL.read_only and @@GLOBAL.super_read_only on the candidate. Ordinary read-only mode has privileged-client exceptions; the stronger variable blocks additional client updates while still permitting replication activity. Their interaction matters when your failover tool changes them. Rehearse the exact tool sequence on a disposable topology rather than issuing global state changes from a generic article.
  4. Switch the writer endpoint through the approved mechanism, then test one bounded business transaction. Confirm which server actually handled it and verify it through the intended reader path. Drain or recycle application pools that retain old connections. Endpoint DNS and existing pooled sockets can move on different timelines.

Decision table

FindingMeaningRequired action
Candidate read-onlyWrites may be rejectedCheck failover tool state
Former source still serves writersTwo-writer riskComplete fencing first
Candidate lacks required transactionsRecovery tradeoff remainsEscalate the data decision
New endpoint, old pooled connectionsRouting incompleteDrain pools deliberately

Illustrative scenario

A billing application uses long-lived database connections. An operator updates the writer hostname, but several workers continue using the old source. The planned switchover succeeds only after the old writer is fenced and those pools reconnect. A new invoice is then created once, its server identity recorded, and its reader visibility checked. The scenario illustrates why endpoint changes and session migration require separate evidence.

Verification and correction

If the write test fails, inspect server identity and read-only state before loosening permissions. If it succeeds on the wrong host, stop the cutover and correct routing. Keep the previous source isolated until its history has been reconciled and a documented rejoin or rebuild procedure is selected. Do not simply point it at the new writer while divergent local changes remain unexplained.

Maintain the runbook

Monitor writer identity, unexpected writable replicas, connection destinations, and replication health after promotion. Assign responsibility for fencing, application acceptance, and rejoining servers. Rehearse failback separately: reversing names is not a recovery plan. Store transaction evidence and the accepted recovery point with the incident record so later reconciliation has a defensible starting point.

Explore Clouvenix database administration for implementation and operational handover.

Technical reference