Promote a replica / fail over (promote)

Oracle

-- Data Guard broker (DGMGRL):
SWITCHOVER TO 'standby_db';     -- planned, no data loss
-- FAILOVER TO 'standby_db';     -- on loss of the primary, emergency

SWITCHOVER is a planned role transition; FAILOVER is performed while the primary is unreachable and carries a risk of data loss.

PostgreSQL

-- Promote the standby to primary:
SELECT pg_promote();
-- or from the shell: pg_ctl promote -D /var/lib/pgsql/data

Before promoting, make sure the old primary is really stopped (split-brain risk). After promotion, rejoining the old primary as a replica of the new primary requires pg_rewind; for that, wal_log_hints = on or data checksums must be enabled.

MySQL

-- On the replica (manual):
-- 1) Stop receiving new events, wait until the received relay log is fully applied:
STOP REPLICA IO_THREAD;
SELECT RECEIVED_TRANSACTION_SET FROM performance_schema.replication_connection_status;
SELECT @@GLOBAL.gtid_executed;  -- the received set must be fully contained here
-- 2) Remove replication and enable writes:
STOP REPLICA;
RESET REPLICA ALL;
SET GLOBAL read_only = OFF;  -- also turns off super_read_only
-- 3) Fence the old source against writes, then redirect the application.

If RESET REPLICA ALL is run before the relay log is fully applied, transactions that were received but not applied are lost. Replicas usually run with read_only/super_read_only enabled; writes are not accepted until they are turned off. If the old source is still writable, there is a split-brain risk. The syntax is 8.0.22+ (before that STOP SLAVE / RESET SLAVE ALL; the old form was removed in 8.4). For automatic and safe failover in production, prefer InnoDB Cluster/Group Replication, Orchestrator or MHA.

SQL Server

-- On the target secondary replica (synchronous):
ALTER AVAILABILITY GROUP [AG_Name] FAILOVER;
-- Force it, with risk of data loss:
-- ALTER AVAILABILITY GROUP [AG_Name] FORCE_FAILOVER_ALLOW_DATA_LOSS;

A planned failover to a synchronous replica has no data loss; FORCE is used only in a disaster scenario.

MongoDB

// Trigger an election on the current primary:
rs.stepDown(60)   // step down from primary for 60 s

stepDown starts a new election; to favor a specific node, adjust the members' priority values.

Redis

# Make the replica an independent primary:
REPLICAOF NO ONE
# With Sentinel (recommended): SENTINEL FAILOVER <master-name>

If you use Sentinel/Cluster, use SENTINEL FAILOVER instead of a manual REPLICAOF; otherwise there is a split-brain risk.