Бэкап журналов транзакций AlwaysOn на вторичной реплике MS SQL Server
Архитектура бэкапов в AlwaysOn AG
Технология AlwaysOn Availability Groups в MS SQL Server позволяет разгрузить первичную реплику (Primary Replica) от задач резервного копирования, перенеся их на вторичные узлы (Secondary Replicas). Это особенно критично для высоконагруженных баз данных 1С, где I/O операции бэкапа журнала транзакций (T-Log) могут вызывать блокировки. Однако неправильная настройка политик копирования (Automated Backup Preference) приводит к нарушению цепочки LSN (Log Sequence Number) и невозможности восстановления Point-in-Time.
Параметры Automated Backup Preference
| Параметр (Политика) | Поведение MS SQL Server | Рекомендация для 1С |
|---|---|---|
Secondary only | Бэкапы всегда выполняются на вторичной реплике. Если её нет, бэкап не выполняется. | Не рекомендуется (высокий риск потери цепочки логов при отвале Secondary). |
Prefer Secondary | Бэкапы выполняются на вторичной реплике. При её недоступности — на первичной. | Рекомендуется. Обеспечивает отказоустойчивость цепочки LSN. |
Primary | Бэкапы всегда выполняются только на первичной реплике. | Использовать только при слабом I/O на Secondary-узлах. |
Настройка T-Log Backup на вторичных репликах
Сценарий 1: Проверка статуса реплики перед бэкапом (T-SQL)
MS SQL Agent не знает автоматически, на какой реплике он запущен. В скриптах обслуживания (Maintenance Plans или скриптах Ola Hallengren) необходимо использовать функцию sys.fn_hadr_backup_is_preferred_replica.
-- Проверка, является ли текущая реплика предпочтительной для бэкапа
IF (sys.fn_hadr_backup_is_preferred_replica('Database_1C') <> 1)
BEGIN
PRINT 'Это не предпочтительная реплика для бэкапа. Пропускаем...'
RETURN
END
-- Код выполнения резервного копирования
BACKUP LOG [Database_1C] TO DISK = N'\\BackupShare\TLog\DB1C_log.trn'Сценарий 2: Особенности Full и T-Log бэкапов
Полные бэкапы (Full Backups) на вторичной реплике AlwaysOn могут быть ТОЛЬКО типа Copy-Only. Это означает, что они не сбрасывают бит дифференциальных изменений. Однако, бэкапы журнала транзакций (T-Log) на вторичной реплике срезают лог (Truncate) и обновляют общую цепочку LSN для всей группы доступности.
- Путь сохранения: Все реплики должны сохранять бэкапы в единую сетевую шару (SMB/NFS), чтобы при аварии вы имели единый непрерывный набор .trn файлов для восстановления.
- Ola Hallengren: При использовании его скриптов параметр
@BackupSoftware = NULLи наличие AlwaysOn автоматически обработают логику предпочтительной реплики.
Сбой синхронизации AlwaysOn (статус Not Synchronizing) блокирует усечение лога на Primary-реплике. Инженеры ITSTM проведут глубокий аудит производительности AlwaysOn, устранят сетевые BottleNeck'и и настроят надежные планы обслуживания MS SQL.
Частые вопросы (FAQ)
Почему журнал транзакций не усекается после бэкапа на Secondary?
Усечение (Truncation) происходит только после того, как транзакция зафиксирована на ВСЕХ синхронных репликах и бэкап успешно выполнен. Если вторичная реплика отстает или приостановлена (Suspended), Primary не очистит свой лог.
Можно ли делать дифференциальные (Diff) бэкапы на вторичной реплике?
Нет. MS SQL Server не поддерживает создание дифференциальных резервных копий на вторичных репликах AlwaysOn, так как там невозможно сбросить карту изменений (BCM).
Что будет, если сделать обычный T-Log бэкап на Primary при политике 'Prefer Secondary'?
Цепочка не сломается. Вы просто получите один файл бэкапа с Primary. Главное — хранить все файлы в одной папке, чтобы MS SQL мог собрать их по порядку LSN при восстановлении.
Поддерживает ли Maintenance Plan проверку предпочтительной реплики?
Да, стандартные планы обслуживания (Maintenance Plans) в MS SQL Server 2012+ автоматически распознают настройки AlwaysOn и пропускают задачи на нецелевых узлах.