DBAtlas · Atlas d'exploitation des bases de données

Promouvoir un réplica / basculer (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 est une transition de rôle planifiée ; FAILOVER s'effectue lorsque le primaire est injoignable et comporte un risque de perte de données.

PostgreSQL

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

Avant la promotion, assurez-vous que l'ancien primaire est réellement arrêté (risque de split-brain). Après la promotion, réintégrer l'ancien primaire comme réplica du nouveau primary nécessite pg_rewind ; pour cela, wal_log_hints = on ou les checksums de données doivent être activés.

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.

Si RESET REPLICA ALL est exécuté avant que le relay log soit entièrement appliqué, les transactions reçues mais non appliquées sont perdues. Les réplicas tournent généralement avec read_only/super_read_only activés ; les écritures ne sont acceptées qu'après leur désactivation. Si l'ancienne source est encore accessible en écriture, il existe un risque de split-brain. La syntaxe est 8.0.22+ (auparavant STOP SLAVE / RESET SLAVE ALL ; l'ancienne forme a été supprimée en 8.4). Pour un failover automatique et sûr en production, préférez InnoDB Cluster/Group Replication, Orchestrator ou 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;

Un failover planifié vers un réplica synchrone n'entraîne aucune perte de données ; FORCE n'est utilisé qu'en scénario de sinistre.

MongoDB

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

stepDown déclenche une nouvelle élection ; pour favoriser un nœud précis, ajustez les valeurs priority des membres.

Redis

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

Si vous utilisez Sentinel/Cluster, utilisez SENTINEL FAILOVER au lieu d'un REPLICAOF manuel ; sinon il existe un risque de split-brain.

Ouvrir dans DBAtlas →