レプリカを昇格/フェイルオーバー(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 は計画的なロール遷移。FAILOVER はプライマリに到達できない状態で実行され、データ損失のリスクを伴う。

PostgreSQL

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

昇格の前に、旧プライマリが確実に停止していることを確認する(スプリットブレインのリスク)。昇格後、旧プライマリを新プライマリのレプリカとして再参加させるには pg_rewind が必要で、そのためには wal_log_hints = on またはデータチェックサムが有効である必要がある。

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.

リレーログが完全に適用される前に RESET REPLICA ALL を実行すると、受信済みで未適用のトランザクションが失われる。レプリカは通常 read_only/super_read_only を有効にして稼働しており、これらを無効にするまで書き込みは受け付けない。旧ソースが書き込み可能なままだとスプリットブレインのリスクがある。この構文は 8.0.22+(それ以前は STOP SLAVE / RESET SLAVE ALL。旧形式は 8.4 で削除)。本番環境で自動かつ安全なフェイルオーバーには InnoDB Cluster/Group Replication、Orchestrator または 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;

同期レプリカへの計画的なフェイルオーバーではデータ損失はない。FORCE は障害シナリオでのみ使用する。

MongoDB

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

stepDown は新しい選出を開始する。特定のノードを優先するには、メンバーの priority 値を調整する。

Redis

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

Sentinel/Cluster を使用している場合は、手動の REPLICAOF ではなく SENTINEL FAILOVER を使用する。そうしないとスプリットブレインのリスクがある。