Log shipping: проверяйте восстановление, а не цвет заданий

Log shipping позволяет поддерживать резервную базу сравнительно простым набором компонентов. Главная эксплуатационная ловушка состоит в том, чтобы считать успешное задание доказательством выполнения требований восстановления. Копирование может завершаться успешно, хотя источник больше не создаёт копий журнала. Восстановление может работать, пока новейший файл лежит на другом сервере. Важно отставание доступного для восстановления состояния от реального бизнеса.

Проследите файл через три этапа

Возьмите конкретную копию журнала: создание на основном сервере, появление на резервном и применение к базе. Зафиксируйте идентификатор и время каждого этапа. Если резервирование актуально, но переданные файлы стары, проверяйте общий каталог, хранилище и копирование. Если файлы приходят, но восстановление отстаёт, ищите ошибки, пропущенные предшественники, мешающих читателей или недостаточный темп применения.

Следующая административная процедура только читает сводку на экземпляре, настроенном как монитор. Нужны соответствующие права. Рассматривайте результаты основной и резервной сторон совместно. Убедитесь, что сам монитор получает свежую информацию.

USE master;
EXEC sys.sp_help_log_shipping_monitor;

Старая запись иногда означает отказ передачи сведений, а не отставание данных. Перед вмешательством проверьте локальную историю заданий и реальные файлы. Но эта возможность не оправдывает отклонение каждого предупреждения. Определите допустимый возраст и испытайте доставку уведомления, а не только наличие настройки. Назначьте получателя, который действительно дежурит во время возможной аварии.

При резервировании каждые пять минут, копировании и восстановлении каждые две транзакция сразу после создания копии ждёт следующий цикл. Затем возможны ожидания обоих последующих этапов. Такое расписание не гарантирует максимум пять минут потерь. Результат определяют фактическое выполнение, ошибки, очереди и доступные после аварии файлы.

Явно задайте задержку и хранение

Намеренная задержка применения может некоторое время сохранять состояние до ошибочного удаления. Защита зависит от обнаружения события раньше его применения. Это не замена независимо хранимым копиям: обнаружение бывает поздним, а общий отказ хранилища или компрометация доступа затрагивает несколько экземпляров.

Различайте возраст последнего скопированного и последнего применённого файла. Предупреждение о восстановлении должно учитывать заданную задержку и обоснованный эксплуатационный допуск. Копирование при этом обязано продолжаться. Общая отмена тревог для отложенных баз способна скрыть реально остановившийся процесс.

Срок хранения должен покрывать задержку, вероятные простои, диагностику и разбор накопившейся очереди. Если очистка удалит ещё необходимый журнал, исправный более поздний файл не устранит разрыв. Согласуйте работу других продуктов резервирования. Обычная копия журнала, созданная сторонним инструментом, может стать обязательным файлом, который log shipping никогда не передаст. Назначьте владельца полной последовательности и проверьте правила удаления на обеих сторонах.

Испытайте смену ролей полностью

Переключение является управляемым ручным процессом. Сначала исключите противоречащие записи на прежнем основном сервере. Если он доступен, оцените заключительное резервирование журнала, затем передайте и примените все необходимые доступные файлы. Если он потерян, документируйте последний достижимый результат и неопределённость относительно последующих транзакций.

Не завершайте восстановление просто ради проверки открытия. После этого прежнюю последовательность нельзя автоматически продолжить. Для возобновления защиты нужен отдельный план. Определите, когда прекращается ожидание файлов, кто принимает возможные потери и как перенаправляются клиенты. Проверьте, что старый сервер не вернётся в работу с устаревшими настройками маршрутизации.

STANDBY может разрешать чтение между применениями журнала. Однако читатели способны мешать расписанию без продуманного отключения. Испытайте выбранный режим и поддерживаемую комбинацию версий. После переключения проверьте логины, задания, подключения и внешние зависимости. Измеряйте весь путь до первой правильной бизнес-операции. Сохраните последовательность носителей и фактическую длительность как свидетельство, понятное следующему дежурному.

Техническая документация: Microsoft Learn: Log shipping overview · Microsoft Learn: Monitor summary · Microsoft Learn: Manual failover.