Ви отримали задачу — забезпечити відмовостійкість для легасі БД на застарілих редакціях SQL Server, де Always On AG недоступний через ліцензію. Ми часто стикаємося з такими запитами у замовників, у яких в продакшні досі крутяться системи на легасі-версіях. Database Mirroring — робоче рішення, хоча Microsoft і позначила його як deprecated. Нижче — практичні деталі, які допоможуть обійти підводні камені.
Чому Database Mirroring досі затребуваний?
Незважаючи на вік технології, mirroring залишається єдиним варіантом для старих редакцій SQL Server (Standard, Web) без ліцензії Enterprise. Він не вимагає додаткових компонентів на кшталт кластеризації Windows, а налаштування займає 2–3 дні. При цьому синхронний режим забезпечує RPO = 0, що критично для фінансових систем та ERP. Крім того, mirroring не залежить від версії ОС і може бути розгорнутий на ізольованих серверах без спільного сховища.
Як вибрати режим: синхронний чи асинхронний?
Вибір режиму визначається вимогами до RPO та продуктивності. Синхронний режим (High Safety) гарантує нульову втрату даних, але збільшує час відгуку на 10–30% через очікування підтвердження від mirror. Асинхронний (High Performance) не чекає підтвердження, що дає максимальну пропускну здатність, але при збої можлива втрата даних за останні кілька секунд. Автоматичний failover працює тільки в синхронному режимі за наявності witness-сервера.
| Режим | RPO | RTO | Продуктивність | Автоматичний failover |
|---|---|---|---|---|
| High Safety (synchronous) | 0 | Секунди | Знижується на 10–30% | Так (з witness) |
| High Performance (asynchronous) | Кілька секунд (можлива втрата) | Хвилини | Максимальна | Ні (тільки ручний) |
Як налаштувати Database Mirroring через T-SQL?
Налаштування складається з трьох кроків: створення endpoint'ів, ініціалізація mirror-бази, запуск сесії. В середньому процедура займає близько 30–40 хвилин за наявності чистих серверів.
Створення endpoint'ів
На обох серверах та witness (опціонально) створюються endpoint'и на TCP-порту 5022:
-- На PRINCIPAL і MIRROR CREATE ENDPOINT Mirroring
STATE = STARTED AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
FOR DATABASE_MIRRORING (ROLE = PARTNER, ENCRYPTION = REQUIRED ALGORITHM AES);
-- На WITNESS (можна SQL Express)
CREATE ENDPOINT Mirroring
STATE = STARTED AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
FOR DATABASE_MIRRORING (ROLE = WITNESS, ENCRYPTION = SUPPORTED);Ініціалізація mirror-бази
Виконуєте повний бекап + лог-бекап на principal, відновлюєте на mirror в режимі NORECOVERY:
-- На principal: бекап
BACKUP DATABASE AppDB TO DISK = 'D:\Backup\AppDB_mirror_init.bak' WITH COMPRESSION;
BACKUP LOG AppDB TO DISK = 'D:\Backup\AppDB_mirror_log.bak';
-- На mirror: відновлення
RESTORE DATABASE AppDB FROM DISK = 'D:\Backup\AppDB_mirror_init.bak' WITH NORECOVERY, REPLACE, MOVE 'AppDB' TO 'E:\SQLData\AppDB.mdf', MOVE 'AppDB_log' TO 'E:\SQLLog\AppDB_log.ldf';
RESTORE LOG AppDB FROM DISK = 'D:\Backup\AppDB_mirror_log.bak' WITH NORECOVERY;Запуск сесії та перевірка
Спочатку на mirror, потім на principal:
-- На MIRROR:
ALTER DATABASE AppDB SET PARTNER = N'TCP://SQL01.corp.local:5022';
-- На PRINCIPAL:
ALTER DATABASE AppDB SET PARTNER = N'TCP://SQL02.corp.local:5022';
-- Додавання witness (якщо потрібен автоfailover):
ALTER DATABASE AppDB SET WITNESS = N'TCP://SQL03.corp.local:5022';
-- Перевірка стану:
SELECT mirroring_state_desc, mirroring_role_desc, mirroring_safety_level_desc FROM sys.database_mirroring WHERE database_id = DB_ID('AppDB');
Нормальний стан — SYNCHRONIZED (synchronous) або SYNCHRONIZING (asynchronous). SUSPENDED свідчить про проблему.
Як уникнути типових помилок?
Класична ситуація: після налаштування endpoint'ів зв'язок є (перевірено telnet'ом на порт 5022), але ALTER DATABASE SET PARTNER зависає з помилкою 1418. Причина — службові облікові записи SQL Server не мають права CONNECT на endpoint'и один одного. Рішення — явний GRANT:
-- На SQL01 дозволити SQL02
GRANT CONNECT ON ENDPOINT::Mirroring TO [CORP\SQL02SvcAccount];
-- На SQL02 дозволити SQL01
GRANT CONNECT ON ENDPOINT::Mirroring TO [CORP\SQL01SvcAccount];Якщо SQL працює під Local System або Network Service — використовуйте сертифікати замість Windows-аутентифікації. Інша поширена помилка — забувають налаштувати DNS або додати записи в hosts, що призводить до збоїв при спробі з'єднання.
| Помилка | Причина | Рішення |
|---|---|---|
| Помилка 1418 при SET PARTNER | Немає CONNECT на endpoint | GRANT CONNECT |
| SUSPENDED після мережі | Втрата зв'язку, переповнення журналу | Перевірити logs, ALTER ... RESUME |
| Автоfailover не спрацьовує | Немає witness або асинхронний режим | Додати witness, переключити в synchronous |
Що входить в роботу з налаштування mirroring
Наші інженери виконують повний цикл: аудит поточної конфігурації (версія SQL Server, редакція, мережева зв'язність), проектування схеми (вибір режиму, рішення про witness), налаштування endpoint'ів та прав доступу, ініціалізація mirror-бази з перенесенням на нові LUN'и, тестування всіх сценаріїв failover (ручного та автоматичного), розробка runbook'а та скриптів моніторингу з оповіщенням в Telegram/Slack. Середній час налаштування — 2–3 дні, включаючи тестування. При міграції на Always On AG терміни збільшуються до 5–7 днів, але downtime не перевищує 10 хвилин.
Терміни та вартість
Терміни налаштування mirroring — від 2 до 3 робочих днів. Якщо потрібна міграція на Always On AG — від 5 до 7 днів. Вартість розраховується індивідуально після аудиту: враховуються версія SQL Server, складність схеми та вимоги до RPO/RTO. Зв'яжіться з нами для аудиту вашої інфраструктури — наша команда реалізувала такі переходи для 30+ замовників. Отримайте консультацію щодо вибору оптимальної стратегії відмовостійкості.
