У цій статті ми розглянемо всі технології SQL Server, які можуть забезпечити високу доступність даних і відмовостійкість для вашого SQL Server.
Резервні копії - це добре, але, коли рахунок йде на хвилини, а деколи і секунди, допоможе тільки надмірність даних і чіткий план відпрацювання відмови. SQL Server надає різні способи для реалізації надмірності і високої доступності даних.
зміст:
- Віддзеркалення баз даних (Database mirroring) в SQL Server
- Доставка журналів (Log shipping) в SQL Server
- Реплікація в Microsoft SQL Server: огляд методів
- Групи доступності Always On в SQL Server
Віддзеркалення баз даних (Database mirroring) в SQL Server
- Доступно в редакціях: Standard (Тільки синхронний режим), Enterprise, Web / express - тільки режим Witness
- Працює на рівні: Бази даних
- Версія SQL Server: SQL Server 2005, SQL Server 2008
Віддзеркалення працює на рівні бази даних (може ще бути на рівні об'єктів) і забезпечує автоматичний / ручний перехід між серверами в разі відмови. Резервна база в будь-якому з режимів роботи зеркалирования буде перебувати в стані постійного відновлення, тому звертатися до неї не вийде.
У зеркалирования є 2 режиму роботи: Синхронний і асинхронний.
синхронний режим означає що головний сервер і резервний повністю синхронізовані. Синхронізація досягається за рахунок того, що дані які приходять на головний сервер, відразу ж відправляються на резервний сервер. Резервний сервер якомога швидше записує дані в транзакційний журнал на диск. Як тільки резервний сервер закінчив записувати дані, він посилає сигнал головного сервера, після чого головний сервер записує дані на диск. В цьому режимі час транзакції збільшується, через те, що головного сервера доводиться чекати, поки дані запишуться на диск на резервний сервер, але при такому підході ймовірність втрати даних мінімальна.
У синхронному режимі є можливість використовувати Witness сервер. Сервер в режимі свідка стежить за працездатністю серверів зеркалирования і може ініціювати відпрацювання відмови, тобто перехід резервного сервера в активний стан.
Потрібно мати на увазі, що вузькі місця на резервному сервері будуть впливати на головний.
асинхронний або режим високої продуктивності - працює також, за винятком того, що головний сервер після відправки транзакційного балки не чекає відповіді від резервного про успішну записи на диск.
В цьому режимі транзакції проходять швидше і продуктивність резервного сервера ніяк не впливає на основний, але в разі відновлення резервного сервера як основного є ризик втрати даних, так як дані на серверах не синхронізовані.
Віддзеркалення варто використовувати тільки якщо у вас збіг по всім умовам
- SQL Server 2008 або SQL Server 2005
- Низька мережева затримка (latency) між основним сервером і резервним
- Вам критична втрата навіть однієї транзакції
Якщо ваш випадок не підпадає під усі умови, варто розглянути інші варіанти.
Доставка журналів (Log shipping) в SQL Server
- Доступно в редакціях: Standard, Web, Enterprise
- Працює на рівні: Бази даних
- Версія SQL Server: SQL Server 2005 і вище
Технологія доставки журналів (Log shipping) дозволяє автоматично відправляти резервні копії журналів транзакцій з бази даних джерела в одну або більше баз даних одержувачів і потім відновлює їх в базах даних одержувачів. Опціонально може бути третій сервер, який буде виконувати роль служби моніторингу - відстежувати виконання операцій резервного копіювання та відновлення журналів.
Засоби моніторингу і діагностики SQL Server розглянуті в окремій статті.Після настройки доставки журналів створюються Завдання (jobs). Принцип роботи такий:
- Перше завдання відповідає за резервне копіювання журналу транзакцій на основному сервері
- Друге завдання відповідає за поширення бекапу на все сервера-одержувачі
- Третє завдання відновлює журнали в усі бази даних одержувачів. Відновлення є в режимах No recovery mode або Standby mode
Це більш проста технологія, щодо віддзеркалення і Always On. Доставку журналів варто використовувати, коли:
- Допустима різниця в даних між основним сервером і серверами одержувачами. Стандартне розклад виконання завдань - кожні 15 хвилин. Можна поставити і менше, але потрібно враховувати швидкість передачі даних по мережі і час на відновлення журналів.
- Ви хочете звертатися до баз даних одержувачів для read доступу. Це можливо, коли режим відновлення встановлений в Standby mode. Але майте на увазі, звертатися до бази ви зможете тільки в проміжках між відновленням журналу.
Реплікація в Microsoft SQL Server: огляд методів
- Доступно в редакціях: Standard і Web - з обмеженнями, Enterprise
- Працює на рівні: Об'єкта бази даних
- Версія SQL Server: SQL Server 2000 і вище
Існує різні типи реплікації:
- реплікація транзакцій
- Тимчасова реплікація транзакцій
- Реплікація моментальних знімків
- реплікація злиттям
Є ще 2 топології, засновані на реплікації транзакцій:
- Двунаправленная реплікація транзакцій
- Оновлювані підписки для реплікації транзакцій (функція підтримується в версіях SQL Server з 2012 по 2016)
Реплікація може застосовуватися для різних цілей, але в основному її використовують для розвантаження OLTP серверів select запитами і для високої доступності. Хоча Microsoft не позиціонує реплікацію як засіб для досягнення високої доступності, вона цілком може виконувати цю роль.
Замітка: в моделі реплікації SQL Server є 3 типи серверів:- Publisher (Видавець) - сервер який видає статті
- Distributor (Розповсюджувач) - сервер який поширює статті на сервера-передплатники
- Subscriber (Передплатник) - сервер який отримує поширювані статті
Зміна які проходять в обраних об'єктах на видавця, відправляються спочатку на розповсюджувача, потім розповсюджувач розсилає ці зміни передплатникам.
Розглянемо 4 основні типи реплікації
Реплікація транзакцій (Transactional Replication)
Цей тип реплікації використовується для "near real time" реплікації даних, тобто дані на передплатників з'являються практично відразу, з урахуванням часу копіювання даних по мережі.
Транзакції з видавця відправляються на розповсюджувач, розповсюджувач відправляє ці транзакції на передплатників. Розповсюджувач може відправляти дані передплатникам негайно, або за визначеним розкладом. Об'єкти на передплатника, які беруть участь в реплікації повинні використовуватися тільки для read only доступу, інакше дані стануть неузгоджені і виникне конфлікт.
Тимчасова реплікація транзакцій (Peer-To-Peer Transactional Replication)
Тимчасова реплікація або Peer-To-Peer Transactional Replication схожа на звичайну реплікацію транзакцій, але вона може працювати відразу з декількома серверами.
Однорангову реплікацію можна назвати master-master репликацией (для звичайної транзакционной реплікації було б master-slave). Розглянемо схему з документації Microsoft
Кожен екземпляр SQL Server який бере участь в тимчасовій реплікації може обробляти read і write операції. Так само в такому типі реплікації передбачений механізм вирішення конфліктів, коли на кілька серверах одночасно приходить одна і та ж операція, наприклад, update запит. Але навіть з урахуванням цього механізму не рекомендується записувати дані в кілька примірників одночасно.
Такий тип реплікації може використовуватися для балансування навантаження, в тому числі для update / insert / delete операцій.
Реплікація моментальних знімків (Snapshot replication)
Це особливий тип реплікації, який не відслідковує зміну даних на видавця, а за певним розкладом створює моментальний знімок і відправляє його передплатникам (через розповсюджувача).
Реплікація знімків не застосовує всі транзакції послідовно, як у випадку з доставкою журналів і транзакционной репликацией, а копіює дані через bcp.
Цей вид реплікації варто використовувати коли:
- Дані рідко змінюються
- Допустима різниця в даних між видавцем і передплатником
- Великий обсяг змін за короткий період часу
Реплікація злиттям (Merge replication)
Механізм роботи схожий на однорангову реплікацію транзакцій, але є кілька важливих відмінностей:
- Реплікація злиттям може мати тільки одного видавця і кілька передплатників, коли як в peer-to-peer реплікації всі екземпляри рівні між собою (одночасно є і видавцями, і передплатниками
- У реплікації злиттям передплатники можуть отримувати різні дані, коли в тимчасової реплікації все сервера мають одні дані
- Реплікація злиттям може вирішувати конфлікти, однорангова - немає
- Тимчасова реплікація доступна тільки в Enterprise редакції
Реплікацію злиттям варто застосовувати тоді, коли вам потрібно консолідувати дані.
Двунаправленная реплікація транзакцій іОбновляемие підписки для реплікації транзакцій
Двунаправленная реплікація (Bidirectional Transactional) це топологія, коли звичайна реплікація транзакцій налаштована на реплікацію одні тих же даних. Параметр @loopback_detection parameter в sp_addsubscription повинен бути виставлений в TRUE
Оновлювані підписки для реплікації транзакцій схожі на реплікацію злиттям. Ця технологія досить швидка стала застарілою, так як практично не використовувалася і замінюється іншими типами реплікації.
Групи доступності Always On в SQL Server
- Доступно в редакціях: Standard (З обмеженнями), Enterprise (
- Працює на рівні: Бази даних
- Версія SQL Server: SQL Server 2012 і вище
Always On availability groups з'явилися в релізі SQL Server 2012. Це альтернатива (хоча швидше за розвиток) технології зеркалирования баз даних.
Групи доступності Always On працюють на основі Windows Server Failover Cluster, але починаючи з 2017 версії з'явилася можливість використовувати Always On без WSFC. Always on схожий на віддзеркалення баз даних (синхронний і асинхронний режими) але вторинних реплік може бути до 8 штук. Always On підтримує автоматичний відробіток відмови (тобто, при падінні основного примірника кластера WSCF вибирає нову основну репліку і перенаправляє write запити на неї).
Кожен екземпляр в групі доступності може бути або primary (Основним), або secondary (Вторинним). Вторинні репліки можуть бути або в read-only, або в режимі No recovery. Кожен екземпляр в групі доступності містить в собі копії баз даних групи доступності. Майте на увазі, що в синхронному режимі швидкість проведення транзакцій буде залежати від самого "повільного" учасника групи доступності.
У базовому налаштуванні Always On простий, після установки SQL Server все можна налаштувати за допомогою майстра (WSFC через оснащення в Windows, а самі групи доступності через майстер в SSMS). Але при великій кількості серверів і складної інфраструктури доведеться добре вивчити документацію.
Рекомендується використовувати Always On в тих же ситуаціях, коли і віддзеркалення, або якщо вам потрібна балансування навантаження select запитів. Також резервні копії рекомендується робити саме з вторинних реплік, це ще одне застосування груп доступності.
Більш детально ми про групах доступності Always On в SQL Server читайте в статті.SQL Server надає багато різноманітних рішень для забезпечення високої доступності даних. При наявності Enterprise редакції і SQL Server 2012 (і вище) краще використовувати Always On. Реплікацію можна використовувати для розвантаження OLTP систем select запитами і для часткової надмірності (хоча одноранговая реплікація позиціонується як повноцінний засіб надмірності даних). Доставку журналів транзакцій і віддзеркалення баз даних можна використовувати в більш старих версіях SQL Server або якщо умови змушують використовувати саме ці технології.
Майте на увазі, що всі перераховані вище технології забезпечення високої доступності даних в SQL Server не замінюють собою резервне копіювання.
