Учения по отработке отказа / плановая смена ролей
Дерево решений, которое определяет тип смены ролей (плановое переключение, аварийная отработка отказа или учения без затрагивания продуктива) и даёт правильную последовательность команд и шаги проверки для каждого сценария. Цель: быть готовым к переходу без потери данных в плановом случае, с минимальными потерями в аварийном и вообще без простоя на учениях.
Что нужно сделать?
Выберите контекст смены ролей. Вы выполняете плановый переход при исправном первичном сервере (обслуживание/миграция), первичный сервер действительно вышел из строя и нужен аварийный переход, или вы проводите учения/проверку готовности, не затрагивая продуктив?
- Плановое переключение (switchover, первичный сервер исправен)
- Аварийная отработка отказа (failover, первичный сервер недоступен)
- Учения / тест готовности (не затрагивать продуктив)
Плановый переход — вы готовы?
Цель планового переключения — НУЛЕВАЯ потеря данных. Для этого перед переходом нужно убедиться, что реплика догнала первичный сервер (задержка ~0) и исправна. Проверьте задержку командами ниже; если она близка к нулю, переходите к шагам перехода.
SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#; -- DG: SELECT name, value FROM v$dataguard_stats WHERE name LIKE '%lag%';- Задержка близка к нулю, готов к переходу
- Задержка высокая, сначала дождитесь синхронизации
Плановое переключение (контролируемый переход без потери данных)
Пока первичный и резервный серверы исправны и синхронизированы, поменяйте роли контролируемо. Порядок важен: остановите запись, убедитесь, что оставшиеся изменения дошли до standby, затем передайте роль и перенаправьте приложение на новый первичный сервер.
Аварийный переход — первичный сервер действительно недоступен?
Перед принудительной отработкой отказа убедитесь, что первичный сервер действительно недоступен, и оцените риск split-brain. Если первичный сервер на самом деле жив (например, кратковременный сбой сети), принудительный переход приведёт к двум отдельным копиям, доступным для записи (split-brain). Также сравните задержку, чтобы выбрать наиболее актуальный standby.
-- try to reach the primary: tnsping primary_db; and on the standby: SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;- Да, первичный сервер недоступен — выполнить принудительный переход
- Не уверен / первичный сервер может вернуться
Аварийная отработка отказа (первичный сервер недоступен, переход с риском потери данных)
Первичный сервер недоступен, и ждать его возвращения нельзя. Нужно принудительно повысить standby; при асинхронной репликации часть последних транзакций может быть потеряна. Приоритет — восстановить сервис, затем определить окно потерь и безопасно вернуть старый первичный сервер.
Учения / тест готовности (проверка без затрагивания продуктива)
Докажите готовность к отработке отказа без реального перехода. Проверьте состояние реплик, допустимость задержки и возможность перенаправить приложение, не затрагивая продуктив. При желании отрепетируйте реальное переключение на изолированной копии.