Налаштування MS SQL Server Log Shipping для реплікації

Налаштування MS SQL Server Log Shipping для реплікації

Уявіть: primary база вийшла з ладу в годину пік, а бекапи — від учорашнього дня. Втрата даних — 12 годин. Альтернатива — Log Shipping. Асинхронна реплікація transaction log на secondary сервер, де резервна копія оновлюється кожні 15–30 хвилин. RPO — 15 хвилин, RTO — 5–10 хвилин на failover. Без ліцензій Enterprise і дорогого обладнання.

Наші інженери з 10+ річним досвідом впроваджують DR-рішення для SQL Server, де бюджет на Always On AG або FCI відсутній. Log Shipping — перевірений механізм, що працює з SQL Server 2000 і до останніх версій. Принцип простий: primary сервер бекапить transaction log, копіює файл на secondary, secondary відновлює його. Все через SQL Server Agent jobs, без додаткової інфраструктури.

Чому Log Shipping — надійне рішення для DR?

Log Shipping дає економію порівняно з Always On AG: вартість впровадження в 3–5 разів нижча, не вимагає Enterprise-ліцензій і однакового заліза. Наприклад, вартість ліцензії Enterprise може сягати $14,000 на ядро, тоді як Log Shipping працює на Standard за ціною $3,700 на ядро. При цьому RPO 15–30 хвилин задовольняє більшість бізнес-вимог. Асинхронність — компроміс: при аварії втрачається останній незаархівований інтервал. Але це плата за бюджетність. Для критичних систем з нульовою втратою даних — Always On AG, але для типових DR — Log Shipping оптимальний.

Як це працює і де типово ламається

Три job'и: backup (на primary), copy (на secondary), restore (на secondary). Опціонально — monitor server, який відстежує відставання і алертить при проблемах.

Найчастіша помилка при самостійному налаштуванні — backup job працює, copy job мовчить, в Error Log на secondary: Cannot open backup device '\\PRIMARY\LogShipping\AppDB_20240315_0230.bak'. Operating system error 5. Діагностика — Access Denied на share. SQL Server Agent на secondary працює під обліковкою без прав на UNC-шлях primary. Ми вирішуємо це налаштуванням share permissions або зміною сервісного акаунта. Подібні кейси — наш щоденний досвід.

Документація Microsoft рекомендує використовувати окремий обліковий запис для SQL Server Agent з мінімальними правами на UNC-шлях.

Приклад скрипта моніторингу:

-- Перевірка стану log shipping після налаштування
SELECT primary_server, primary_database, last_backup_file, last_backup_date, DATEDIFF(MINUTE, last_backup_date, GETDATE()) AS minutes_since_backup
FROM msdb.dbo.log_shipping_monitor_primary;

SELECT secondary_server, secondary_database, last_restored_file, last_restored_date, restore_threshold, DATEDIFF(MINUTE, last_restored_date, GETDATE()) AS minutes_since_restore
FROM msdb.dbo.log_shipping_monitor_secondary;

Як налаштувати Log Shipping з мінімальним RPO?

Налаштування через T-SQL — відтворюваний підхід. GUI в SSMS зручний для ознайомлення, але для автоматизації — тільки скрипти.

На primary сервері ініціалізуємо backup job:

-- На primary: налаштування backup job
EXEC msdb.dbo.sp_add_log_shipping_primary_database
    @database = N'AppDB',
    @backup_directory = N'\\SQLPRIMARY\LogShipping',
    @backup_share = N'\\SQLPRIMARY\LogShipping',
    @backup_job_name = N'LSBackup_AppDB',
    @backup_retention_period = 4320,
    @backup_threshold = 60,
    @threshold_alert_enabled = 1,
    @history_retention_period = 5760,
    @backup_compression = 1,
    @primary_id = @LS_BackupJobId OUTPUT;

На secondary — copy і restore jobs:

-- На secondary: налаштування copy + restore
EXEC msdb.dbo.sp_add_log_shipping_secondary_primary
    @primary_server = N'SQLPRIMARY',
    @primary_database = N'AppDB',
    @backup_source_directory = N'\\SQLPRIMARY\LogShipping',
    @backup_destination_directory = N'D:\LogShippingLocal',
    @copy_job_name = N'LSCopy_SQLPRIMARY_AppDB',
    @restore_job_name = N'LSRestore_SQLPRIMARY_AppDB',
    @file_retention_period = 4320,
    @secondary_id = @LS_Secondary OUTPUT;

EXEC msdb.dbo.sp_add_log_shipping_secondary_database
    @secondary_database = N'AppDB',
    @primary_server = N'SQLPRIMARY',
    @primary_database = N'AppDB',
    @restore_delay = 0,
    @restore_mode = 1,
    @disconnect_users = 0,
    @restore_threshold = 45,
    @threshold_alert_enabled = 1,
    @history_retention_period = 5760,
    @secondary_id = @LS_Secondary;

@restore_mode = 1 (STANDBY) дозволяє читання secondary між відновленнями — зручно для звітів. @restore_mode = 0 (NORECOVERY) дає мінімальний RTO при failover. @restore_delay — затримка застосування логів. Захист від випадкового DROP TABLE: ставимо затримку 60 хвилин — є година, щоб зупинити restore і витягти дані.

Ініціалізація secondary бази

Перед запуском log shipping відновлюємо повний бекап primary на secondary в NORECOVERY:

-- На primary: повний бекап
BACKUP DATABASE AppDB TO DISK = N'\\SQLPRIMARY\LogShipping\AppDB_init.bak'
WITH COMPRESSION, STATS = 10;

-- На secondary: відновлення
RESTORE DATABASE AppDB FROM DISK = N'\\SQLPRIMARY\LogShipping\AppDB_init.bak'
WITH NORECOVERY,
     MOVE 'AppDB' TO 'D:\SQLData\AppDB.mdf',
     MOVE 'AppDB_log' TO 'D:\SQLLog\AppDB_log.ldf',
     STATS = 10;

Після цього запускаємо jobs — вони почнуть копіювати і застосовувати transaction log файли. Типові терміни налаштування: одна база — 1 день, кілька баз з monitor сервером — 2-3 дні, міграція — до 3 днів.

Switchover при failover

-- На secondary при failover:
-- 1. Застосувати всі доступні логи вручну
RESTORE LOG AppDB FROM DISK = N'D:\LogShippingLocal\AppDB_last.trn' WITH NORECOVERY;
-- 2. Вивести базу в онлайн
RESTORE DATABASE AppDB WITH RECOVERY;
-- 3. Переключити connection string додатку на secondary сервер

Порівняння: Log Shipping vs Always On AG

Типові RPO/RTO залежно від конфігурації

-- Детальний моніторинг відставання
SELECT db.name, ls.primary_database, ls.last_backup_date, ls.last_restored_date,
       DATEDIFF(MINUTE, ls.last_backup_date, GETDATE()) AS backup_age_min,
       DATEDIFF(MINUTE, ls.last_restored_date, GETDATE()) AS restore_age_min
FROM sys.databases db
JOIN msdb.dbo.log_shipping_monitor_primary ls ON db.name = ls.primary_database;

Що входить в роботу

• Аудит поточної інфраструктури SQL Server
• Налаштування backup/copy/restore jobs
• Конфігурація monitor сервера з алертами
• Тестування failover і switchback
• Документація та Runbook по відновленню
• Навчання чергової зміни

Наші інженери мають сертифікати Microsoft і більше 50 успішних проектів по Log Shipping. Компанія на ринку з 2015 року, 10+ років досвіду з SQL Server. Отримайте консультацію — оцінимо ваше завдання і запропонуємо оптимальну схему реплікації.

Типові помилки при налаштуванні

• Неправильні права на UNC-шлях (Access Denied)
• Відсутність NORECOVERY при ініціалізації secondary
• Невірний restore_delay — дані можуть бути втрачені при швидкому failover
• Ігнорування моніторингу відставання — проблема стає помітною лише при аварії

Для виключення цих проблем зв'яжіться з нами — ми налаштуємо Log Shipping під ключ за 1-3 дні залежно від складності.