Принудительная отработка отказа (FORCE_FAILOVER_ALLOW_DATA_LOSS) и восстановление после неё

Команда

-- 1) On each candidate secondary: pick the most current one (highest end_of_log_lsn)
SELECT ag.name AS ag_name, DB_NAME(drs.database_id) AS db,
       drs.synchronization_state_desc, drs.end_of_log_lsn, drs.last_commit_time
FROM   sys.dm_hadr_database_replica_states drs
  JOIN sys.availability_groups ag ON ag.group_id = drs.group_id
WHERE  drs.is_local = 1;

-- 2) On the chosen replica (while the primary is unreachable):
ALTER AVAILABILITY GROUP [AG_Musteri] FORCE_FAILOVER_ALLOW_DATA_LOSS;

-- 3) On the other secondaries, resume the suspended data movement:
ALTER DATABASE [Musteri] SET HADR RESUME;

-- 4) When the old primary returns (now a SUSPENDED secondary):
--    take a snapshot first to inspect the lost transactions, then resume
CREATE DATABASE [Musteri_lost_snap]
  ON (NAME = N'Musteri', FILENAME = N'D:\Data\Musteri_lost_snap.ss')
  AS SNAPSHOT OF [Musteri];
ALTER DATABASE [Musteri] SET HADR RESUME;

Что делает

При полной потере первичной реплики делает DR-реплику первичной с принятием потери данных; затем возобновляет приостановленное перемещение данных на остальных репликах и, когда старая первичная возвращается, делает снимок для изучения транзакций, не дошедших до новой первичной.

Когда использовать

Когда основной ЦОД недоступен, осталась только асинхронная реплика или синхронная реплика не SYNCHRONIZED, а отработка отказа всё равно нужна.

Внимание

ПОТЕРЯ ДАННЫХ: транзакции после последнего hardened LSN теряются. Сначала получите согласие бизнеса по RPO. После принудительной отработки отказа все вторичные базы находятся в SUSPENDED; журнал не усекается и растёт до HADR RESUME. Если кворум WSFC потерян, сначала запустите кластер с принудительным кворумом (PowerShell: Start-ClusterNode -FixQuorum), иначе команда завершится ошибкой. HADR RESUME на старой первичной реплике окончательно отбрасывает потерянные транзакции; не возобновляйте без снимка.