SQL Server Log Shipping: транзакционные логи каждые 15 минут и RPO, который клиент принял

Задача пришла от клиента, у которого три production-базы на SQL Server 2005: основная ERP, отдельная база аналитики и небольшой склад промежуточных данных для BI-отчётности. Физический сервер стоит в офисе, резервный - в арендованной стойке у хостера. Между ними VPN. Клиент хотел, чтобы при падении основного сервера резервный подхватил работу без потери суток данных. Желательно - быстро.

Варианты обсуждали недолго. Database Mirroring в SQL Server 2005 есть, но требует Enterprise Edition на обоих узлах - у клиента Standard. Replication тоже присутствует, но для трёх баз с разной структурой настраивать транзакционную репликацию руками - это история на несколько дней плюс перманентный мониторинг агентов. Log Shipping в этой ситуации оказался разумным выбором: встроен в Standard Edition, прозрачен в настройке, понятен в диагностике.

Как устроен механизм

Log Shipping работает просто. На primary-сервере по расписанию запускается backup job - он снимает транзакционный лог и кладёт файл на сетевую шару. На secondary стоят два job-а: copy job забирает файл со шары себе, restore job применяет его к резервной базе. Базы на secondary живут в режиме No Recovery или Standby - первый не позволяет вообще ничего читать, второй позволяет открывать базу только для чтения между восстановлениями.

Клиент хотел возможность периодически строить отчёты с резервного сервера - выбрали Standby.

Что настраивали

Три базы, расписание у каждой своё. Основная ERP - бэкап лога каждые 15 минут, copy и restore с задержкой в несколько минут. Аналитическая база обновляется реже, там поставили час. Промежуточное хранилище - тоже 15 минут, потому что в него льют данные ETL-процессы, и опаздывать там неприятно.

Несколько моментов, которые выяснились по ходу:

• Размер шары. Первый бэкап лога после включения log shipping - это не инкремент, а полный снимок с момента последнего полного бэкапа. У ERP-базы он весил несколько гигабайт. Шару пришлось делать с запасом, плюс настроить cleanup job, чтобы старые файлы не копились бесконечно.
• Модель восстановления. Все три базы перевели в Full Recovery Model - без этого log shipping не работает. На одной базе модель была Simple, пришлось поменять и сразу снять полный бэкап, иначе цепочка логов оборвана.
• Время рассинхрона. В Standby-режиме restore job на несколько секунд блокирует базу на secondary. Если в этот момент кто-то пытается её читать - получит ошибку. Пользователей об этом предупредили заранее.
• VPN и задержки. Copy job иногда спотыкался о нестабильное соединение между офисом и хостером. Добавили retry-логику и увеличили таймаут в настройках job-а.

Тестовый failover

Через пару недель после запуска устроили плановый тест. Остановили все job-ы на primary, дождались завершения последнего restore на secondary, перевели резервные базы из Standby в Recovery - они стали доступны для записи.

RPO по итогам теста составило около 12 минут - именно столько данных потеряли бы при немедленном отказе в момент, когда последний restore был 12 минут назад. Клиент посмотрел на цифру, подумал и сказал: нормально, работаем. Для их задач это приемлемо.

RTO - само переключение заняло минут десять: применить оставшиеся логи если они доступны, перевести базы, переключить строки подключения в приложениях. При реальной аварии добавилось бы время на то, чтобы понять, что авария вообще произошла, - но это уже вопрос мониторинга, не log shipping.

Мониторинг в Zabbix

Стандартные средства SQL Server Agent показывают статус job-ов, но Zabbix у клиента уже был, и логичнее было добавить проверку туда. Написали простой скрипт, который опрашивает системную таблицу msdb.dbo.log_shipping_monitor_secondary: в ней хранится время последнего успешного restore и вычисляется задержка в минутах.

Настроили два триггера:

• Предупреждение - если задержка restore больше 20 минут (при расписании 15 минут это значит, что job пропустил уже один цикл).
• Критическое - если задержка больше 40 минут (два пропущенных цикла, пора смотреть, что происходит).

За первые две недели триггер на предупреждение сработал дважды - оба раза из-за VPN-дропа. Оба раза job отработал со второй попытки и наверстал, но сигнал был полезен.

Что в итоге

Log Shipping не претендует на звание zero-downtime-репликации - это честный инструмент с явными параметрами: RPO равен интервалу между бэкапами лога плюс время copy/restore, RTO зависит от того, насколько быстро дежурный добежит до консоли. Зато он работает на Standard Edition, настраивается за день, и при правильном мониторинге ведёт себя предсказуемо.

Для клиентов, которым нужна реплика данных на резервном сайте и которые не хотят платить за Enterprise и разбираться с кластером, - вполне рабочая история.