Promoting a database replica makes it the new writable primary—or, in some services, an independent server. The exact operation depends on the database and provider. Promotion alone does not detect an outage, fence the former primary, redirect applications, or restore redundancy. Before proceeding, decide whether you can wait for synchronization or must accept the risk of losing changes that have not reached the candidate.
What promotion changes—and what it does not
A replica may be a standby that can take over after a primary failure, or a read-only copy used to serve reporting queries. Promotion changes the candidate’s role so it can accept writes, subject to the engine or provider’s behavior. A reporting copy that is only used to offload read-only queries does not necessarily need promotion; PostgreSQL explicitly distinguishes that use from failover in its failover guidance.
Promotion is one part of failover, not an end-to-end recovery system. It does not necessarily decide that the old primary has failed, prevent that server from accepting writes, update application connections, preserve every transaction, or create a replacement replica. Those jobs need to be handled by operators, a managed service, or an orchestration system configured for the database.
Choose planned switchover or forced failover
The key difference is whether the current primary can cooperate and the candidate can catch up. A planned switchover aims to synchronize first. A forced promotion prioritizes restoring write availability when waiting is not practical, but may discard committed changes that never reached the candidate.
#1 Best Overall
| Decision point | Planned switchover | Forced failover |
|---|---|---|
| Primary condition | Usually reachable and able to participate in synchronization. | May be unreachable or unable to complete a coordinated handoff. |
| Data synchronization | Wait for the candidate to receive the primary’s changes before changing roles, as supported by the platform. | May proceed while the candidate is behind. Changes committed on the primary but not replicated may be lost. |
| Recovery time and data loss | Waiting for catch-up can extend the switchover; the goal is to reduce divergence. | May restore write service sooner, but neither a displayed lag figure nor a fast operation guarantees an exact recovery point. |
| Routing and old primary | Plan the endpoint or connection change and role transition together. | Treat routing and fencing as urgent separate actions; do not leave two writable primaries serving clients. |
These are operational distinctions, not guarantees shared by every database product. For Azure Database for PostgreSQL Flexible Server, Microsoft documents a planned switchover that waits for synchronization and a forced promotion that can lose primary changes not yet received by the replica. The reported replication lag is an approximation of possible loss, not a precise transaction-by-transaction recovery point. See Microsoft’s switchover procedure.
Base the choice on whether the primary is reachable, the candidate’s actual replication state, the amount of data loss the service can tolerate, and the recovery time objective. If the primary can still accept writes, coordinate or stop writes as appropriate for the platform before proceeding; otherwise, newer writes may continue on a server that is about to be superseded.
Prepare the candidate and the recovery path
Before promotion, identify the exact candidate, verify its health and replication state, and make sure the people responsible for the database and its clients agree on the change. A stale, unhealthy, or incorrectly selected replica can turn an availability incident into data loss or prolonged recovery.
- Check health and replication state. Confirm the candidate is the intended replica, is healthy, and is receiving or has received the relevant primary changes. Use the status and lag indicators provided by your engine or service, while treating lag as an estimate rather than a guarantee of the recovery point.
- Set the loss boundary. For a planned change, determine whether synchronization has completed before switching roles. For an emergency, explicitly accept the potential loss represented by the candidate’s unsynchronized state.
- Plan fencing. Know how to stop or isolate the old primary from accepting writes, including if it becomes reachable again. This may require a separate infrastructure or cluster action; promotion itself should not be assumed to fence it.
- Check database-specific dependencies. Review replication slots, subscribers, credentials, parameters, and other configuration that may not follow automatically with a role change.
- Plan client routing. Identify the endpoint, DNS record, proxy, connection pool, or application configuration that clients use, and who will change or verify it.
- Define verification and rollback limits. Decide how the team will confirm writes and dependent services are healthy, and avoid reconnecting an old primary until its data and role have been reconciled.
PostgreSQL logical subscribers
If PostgreSQL logical replication subscribers must continue through physical-standby failover, slot readiness is a specific additional check—not a universal prerequisite for all PostgreSQL promotion. PostgreSQL 18 documents synchronization of logical slots to a physical standby when failover is enabled. Before promotion, verify that required slots exist on the standby and are marked ready. Slot synchronization is asynchronous; the documentation also describes using synchronized_standby_slots so the standby is ahead of the subscriber. Follow the engine-version-specific PostgreSQL 18 logical replication failover guidance.
Rank #2
Managed-service configuration
Do not assume a replica inherits every setting or behaves like a self-managed server after promotion. Azure Database for PostgreSQL Flexible Server documents that parameters, authentication configuration, and high-availability configuration may need separate attention. Its two documented outcomes are role reversal by promoting to the primary role, or promotion to an independent server that is removed from replication. Both servers must be Ready for the documented operation. These requirements and outcomes are specific to Azure’s service; consult its promotion concepts.
Promote using the procedure for your platform
There is no single safe promotion command for all replicated databases. Use the procedure for the exact engine version or managed service, and distinguish a role change from changing replication sources or redirecting clients.
Self-managed PostgreSQL physical standby
For PostgreSQL 18, the official failover instruction is: “To trigger failover of a log-shipping standby server, run pg_ctl promote or call pg_promote().” Those are the documented triggers for that standby setup; they do not provide failure detection, client routing, or old-primary fencing. PostgreSQL says deployments need an operational mechanism to detect primary failure and notify the standby. Consult the PostgreSQL failover documentation for the applicable configuration and procedure.
Azure Database for PostgreSQL Flexible Server
Use the Azure-specific planned switchover or forced promotion procedure rather than applying a self-managed PostgreSQL command by assumption. Select the documented outcome—role reversal or independence—and meet the service’s readiness and configuration requirements. The procedure and its behavior are described in Microsoft’s switch-over instructions.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Google Cloud SQL for PostgreSQL cross-region replicas
Google Cloud describes cross-region replica promotion for planned regional migration and disaster recovery when a region is unavailable. Its general sequence is to let replication catch up when possible, promote the replica, then direct clients to the promoted instance. Manual replica promotion is distinct from automatic high availability. Use the current Cloud SQL cross-region replica procedure; do not infer a universal promotion duration from a provider workflow.
MySQL source changes and GTIDs
MySQL 8.4 documents changing a replica’s source with CHANGE REPLICATION SOURCE TO. That operation tells the replica to read and execute events from the selected source’s binary-log coordinates; it does not check whether the source databases are compatible. Treat it as a replication-source change, not proof that the candidate is ready to serve as primary. Follow the MySQL 8.4 manual’s source-switching guidance, including its binary logging considerations for replicas that may become sources.
MySQL 9.7’s GTID guidance explains how globally unique transaction identifiers can simplify replication management and failover. GTIDs help track and coordinate transaction history; they do not replace validation that the candidate contains the required changes and is suitable to serve writes. See Using GTIDs for Failover and Scaleout.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Route applications and verify service
Once the new primary is ready, move clients to it using the routing mechanism for your deployment. A database role change does not guarantee that applications, proxies, or connection pools have stopped using the old endpoint.
Rank #4
- HP ProLiant DL360 G7 8B Server
- 2x X5650 2.66GHz 12-Cores Total
- 32GB RAM / 8x 146GB 10K 2.5in SAS Hard Drives
- P410 w/ 512MB
- Apply the endpoint change. Update or switch the service’s documented connection endpoint, DNS, proxy, or application configuration. For a managed platform, follow its routing instructions rather than assuming an endpoint changes automatically.
- Refresh client connections. Ensure application instances and pools establish connections to the new primary, and monitor for clients that remain attached to the former one.
- Test a controlled write path. Verify that an authorized application can write to the promoted database and that the expected data is readable through the application’s normal path.
- Check dependent replication and services. Confirm that logical subscribers, downstream replicas, jobs, and other dependent components have the expected state and can continue from the new primary.
- Watch error and consistency signals. Check database and application health for failed writes, stale reads, replication errors, or unexpected divergence before declaring recovery complete.
Fence the former primary and restore redundancy
If the old primary returns after the standby has taken over, it must be told that it is no longer primary. PostgreSQL warns that otherwise both servers may act as primary, causing confusion and possible data loss. The isolation step is commonly called fencing or STONITH. Verify the former server cannot accept application writes before allowing it back into the topology; do not simply reconnect it as a peer.
Next determine, using the platform’s recovery procedure, whether the former primary can safely rejoin as a replica or must be rebuilt. Re-establish replication from the current primary and confirm that the new standby is healthy and caught up. PostgreSQL notes that a third system can help provide a replacement standby while a cluster is rebuilt, though adding one also increases configuration and operational complexity.
Rehearse the complete failover
A promotion runbook should cover more than the command or console action: detection, the planned-versus-forced decision, data-loss acceptance, fencing, client routing, verification, and replica recovery. PostgreSQL recommends written administration procedures and regular switchovers to exercise failover. Test the full workflow—including application connections and the return of the old primary—in a controlled setting, and record responsibilities and decision points so an incident does not depend on improvisation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →
