Висока доступність в реплікації SQL Server 2008 з дзеркалювання і доставкою журналів, Інші СУБД, Бази даних, статті

Автор: Олександр Юрійович Гладченко

Стаття написана за мотивами технічного документа Майкрософт: “SQL Server Replication: Providing High Availability using Database Mirroring” і опису в електронній документації SQL Server 2008 Books Online (Далі BOL): “Реплікація і дзеркальне відображення бази даних”.
У цій статті ми розглянемо нові можливості забезпечення високої доступності тиражованих даних, використовуючи для цього Реплікацію транзакцій, Доставку журналів і дзеркальні копії баз даних.
Заснована на Реплікації транзакцій розподілена система зберігання даних може забезпечити високу стійкість до відмов серверів баз даних. Подібні рішення дозволяють досягти високого ступеня доступності, за рахунок підтримки надлишкових копій даних. Крім Реплікації, надмірність на рівні баз даних здатні забезпечити декілька механізмів SQL Server 2008. Це такі можливості, як резервне копіювання з подальшим відновленням, Доставка журналів і Дзеркальне відображення бази даних. Причому, Дзеркальне відображення є єдиним механізмом, який підтримує точну копію захищається бази даних практично в реальному масштабі часу, і гарантує відсутність втрат даних.
У цій статті на прикладах ми подивимося, як можна використовувати Дзеркальне відображення реплицируемой бази даних для підвищення її доступності. Ми розглянемо як Реплікація і Дзеркальне відображення впливають один на одного, а також, як Дзеркальне відображення сумісно з Доставкою журналів і як Доставка журналів сумісна з реплікацією. Крім того, в цій статті ми торкнемося можливостей використання для первісної синхронізації баз даних механізмів Доставки журналів, і коротко розглянемо принципи роботи ініціалізації передплатника, заснованої на логічних номерах віртуальних журналів (LSN), яка дозволяє скоротити час відновлення після відмови при наявності дзеркальної копії бази даних передплатників.



Працює Доставки журналів з Дзеркальним відображенням і реплікацією

У цій статті ми не ставимо за мету повністю розкрити тему суміщення Доставки журналів з Дзеркальним відображенням баз даних та реплікацією. Ця тема досить докладно розкрита в BOL. Тут ми розглянемо тільки ті аспекти Доставки журналів, які нам знадобляться для початкової синхронізації основної бази даних Дзеркального відображення і баз даних Підписчиків в топології реплікації. Коротко буде сказано і про те, як можна використовувати Доставку журналів з метою резервного копіювання беруть участь в Реплікації баз даних.
Метою Доставки журналів SQL Server 2008 є забезпечення автоматичної синхронізації баз даних, яка здійснюється шляхом резервного копіювання журналів транзакцій в базі даних Джерела, і подальшої доставку та відновлення копій журналу транзакцій в базі даних Отримувача. Сервер, який обслуговує базу даних Отримувача, виступає в ролі резервного сервера або сервера звітів. Сервер звітів надає можливість обробки запитів користувачів на читання даних. Одна база даних Джерельну може синхронізуватися з одного або з декількома базами даних Одержувачів. Доставка журналів застосовна до тих баз даних, які використовують повну модель відновлення або модель відновлення з неповним протоколюванням.
Давайте домовимося, що сервер, спочатку обслуговуючий базу даних Джерела, будемо називати сервером джерела (термін “основний сервер” був би зручніше, але він використовується в Дзеркальному відображенні, і ми його не будемо використовувати, щоб не було плутанини), а сервер, спочатку обслуговуючий базу даних Отримувача, називати резервним сервером. Після настройки, сервер джерела обслуговує базу даних Джерела, але може змінити роль і обслуговувати базу даних Отримувача. Зміна ролі призводить до одночасного зміни налаштувань на всіх що беруть участь в Доставці журналів серверах, оскільки сервер джерела може бути тільки один.
В Доставці журналів передбачені засоби моніторингу та оповіщення про всі штатних і позаштатних станах учасників процесу Доставки журналів. Починаючи з SQL Server 2008, підтримується стиснення резервних копій, і такі копії можна використовувати для Доставки журналів. Копії журналів створюються і доставляються за допомогою завдань автоматизації служби SQL Server Agent, всього таких завдань чотири: завдання резервного копіювання Джерела, завдання копіювання файлів Одержувачу, завдання відновлення копій на Одержувача і завдання розсилки попереджень.
Формат зберігання даних на диску для SQL Server x64 і x86 однаковий, тобто в Доставці журналів можуть брати участь сервера баз даних під керуванням 32-х і 64-х розрядних операційних систем. Доставка журналів підтримується наступними редакціями SQL Server 2005: Enterprise Edition, Standard Edition та Workgroup Edition. Сервери, задіяні в доставці журналів, повинні мати однакові параметри сортування, а бази даних джерела і одержувачів можуть використовувати тільки модель повного відновлення (Full) або модель відновлення з неповним протоколюванням (Bulk Logged).
Доставка журналів може бути засобом тиражування даних, однак, у цій статті ми розглянемо можливість використання Доставки журналів для початкової синхронізації баз даних в Дзеркальному відображенні і Реплікації.
З BOL ми знаємо, що Доставку журналів допустимо суміщати з Дзеркальним відображенням. У такому разі база даних Джерела повинна бути основною базою даних Дзеркального відображення. Причому, Дзеркальне відображення може бути налаштований в будь-якому з трьох режимів його роботи. Бази даних Одержувачів не повинні знаходитися на тому ж примірнику сервера, що і база джерела або на примірнику Дзеркального відображення бази Джерела. Оскільки Дзеркальне відображення дозволяє робити резервні копії тільки бази даних основного сервера, використання в якості бази даних Джерела дзеркальної копії основної бази неможливо. Налаштовувати Доставку журналів і Дзеркальне відображення на основному сервері можна в будь-якому порядку.
Припустимо поєднувати Доставку журналів з реплікацією, і це справедливо для видається бази даних, баз даних підписок, і для бази даних Розповсюджувача. Слід враховувати, що процес реплікації буде перерваний в разі переходу на резервний сервер, оскільки агенти реплікації не вміють правильно реагувати на зміну ролей серверів в Доставці журналів, і це призведе до того, що транзакції перестануть тиражуватися передплатникам. Після того, як роль бази даних Джерела повернеться в первинний стан, реплікація відновлюється, і всі ті транзакції, які були скопійовані Доставкою журналів з резервного сервера на сервер джерело, реплікуються передплатникам. У разі безповоротної втрати бази даних Джерела, достатньо перейменувати Отримувача, щоб відновити процес реплікації.
Первісна ініціалізація бази даних Отримувача в процесі настройки Доставки журналів здійснюється шляхом відновлення повної резервної копії бази даних джерела з параметрами NORECOVERY або STANDBY. Для організації доставки журналів необхідно створити мережевий ресурс, в якому будуть створюватися резервні копії журналів транзакцій і який буде доступний усім учасникам в Доставці журналів серверів. У нашому прикладі як такого ресурсу буде використовуватися каталог сервера джерела C: MSSQLLogShip.
Існує можливість синхронізувати процес доставки журналів з тиражуванням даних в реплікації транзакцій. Така синхронізація встановлюється за допомогою системної процедури sp_replicationdboption, яка дозволяє для публікується бази даних і бази даних Розповсюджувача встановити опцію “sync with backup”. Коли ця опція встановлена ​​для бази даних Розповсюджувача, це гарантує, що транзакції в журналі публікується бази даних не будуть усічені до тих пір, поки не буде створена їх резервна копія в базі даних Розповсюджувача. Усічення журналу транзакцій публікується бази даних відкладається до завершення резервного копіювання усікається транзакцій в базі даних Розповсюджувача. Установка цієї опції дозволяє управляти точкою усікання бази даних Публікації. Нове значення набуває чинності після чергового запуску Агента читання журналу або після закінчення заданого параметром агента-MessageInterval інтервалу часу, якщо Агент читання журналу працює в безперервному режимі. За рахунок того, що в базі даних розповсюджувача не буде транзакцій, яких немає в резервної копії інформації, що публікується бази даних, можна не бояться рассогласованности видається бази даних і бази даних Розповсюджувача в разі відновлення видається бази даних з резервної копії. Проте, слід пам’ятати, що такий спосіб синхронізації додає затримку в процес тиражування транзакцій і не гарантує відсутності втрат даних, у разі пошкодження журналу транзакцій. Крім того, для Доставки журналів опція важлива тільки для видається бази даних.
В рамках цієї статті ми не будемо розглядати спільну роботу Доставки журналів і Реплікації. Доставка журналів нами буде використовуватися тільки для цілей початкової синхронізації баз даних передплатників і Дзеркального відображення бази даних Видавця. Тому сценарії включення Доставки журналів будуть використовуватися в прикладах з демонстрацією включення Дзеркального відображення і Реплікації.
Додаткову інформацію про доставку журналів можна отримати в наступних статтях BOL:


Не всі бази даних в топології тимчасової реплікації транзакцій допускають Дзеркальне відображення (віддзеркалення). Наприклад, це неможливо для бази даних Розповсюджувача. В Реплікації транзакцій дзеркалювання бази даних абонентів вимагає врахування деяких обмежень, яких немає для видається бази або в однорангової топології. Можливість використання в реплікації зеркалирования залежить від того, наскільки будуть здатні задіяні агенти реплікації відпрацьовувати стан відмови основної бази даних і автоматично перемикатися на дзеркальну копію. Так, наприклад, жоден з відповідних агентів реплікації не може правильно відреагувати на відмову бази даних Розповсюджувача і переключитися на роботу із дзеркальною копією цієї бази даних. Для забезпечення високої доступності Розповсюджувача його слід винести на виділений комп’ютер і віддати його під управління відмовостійкого кластера. Однак, ті агенти реплікації, які з’єднуються з публікується базою даних, вміють переключатися на дзеркальну копію, і в разі відмови здатні підключитися автоматично, забезпечивши безперервність процесу реплікації.
З передплатниками все не так просто, як з видавцем. На жаль, жоден з працюючих з базами на передплатника агентів реплікації не призначений для автоматичного перемикання в разі відмови. Самим природним шляхом перемикання потоку даних реплікації є видалення підписки і створення її заново.
Додаткові відомості можна отримати в наступній статті BOL: “Реплікація і дзеркальне відображення бази даних”.



Вплив зеркалирования на роботу Агента читання журналу

Віддзеркалення публікується бази даних впливає на поведінку Агента читання журналу, його стан стає залежним від стану зеркалирования. Агент читання журналу зеркаліруемой бази даних буде копіювати з журналу спочатку записи тих транзакцій, які були до цього скопійовані і завершені в журналі реєстрації транзакцій дзеркальної бази даних (процес, за допомогою якого пишуться записи в журнал транзакцій дзеркальної бази даних, в документації називають hardening – закріплення). Тобто реплицироваться будуть тільки записи з таким LSN, який більше LSN останньої закріпленої в журналі транзакцій дзеркала.
Це дозволяє виставити з топології основний сервер (дзеркало доступно, але існують такі записи в журналі транзакцій, які ще не були закріплені на дзеркалі) або ізолювати його (коли дзеркало недоступно). В обох випадках, поки основний сервер працездатний і його база даних доступна, будь-які зміни в його базі даних не будуть реплицирована, поки відповідні записи журналу транзакцій не будуть закріплені на дзеркалі.
Така поведінка додає затримки в потік реплікації, і якщо відбудеться відмова зеркалирования, буде гарантовано, що записи в журналі передплатників не обженуть фіксацію в основній базі даних.
Їли Агент читання журналу змушений чекати закріплення записів в журналі транзакцій дзеркальної бази даних, в хронології роботи Агента читання журналу будуть з’являтися повідомлення наступного вигляду: “Replicated transactions are waiting for next Log backup or for mirroring partner to catch up” .



Зміна поведінки Агента читання журналу при установці прапора трасування 1448

У рідкісних випадках, ефект затримок через зеркалирования для логіки роботи використовують реплікацію програм може виявитися не прийнятний. Для вирішення цієї проблеми доданий новий прапор трасування 1448, який наказує реплікації тривати навіть у тих випадках, коли основна база даних виставлена ​​або ізольована. Зазвичай, Агента читання журналу чекає, поки не будуть закріплені записи в журналі реєстрації транзакцій дзеркальної бази даних, після чого він копіює їх в базу даних Розповсюджувача. Коли сервер запущений з прапором трасування 1448, це очікування виключається, і Агента читання журналу може відразу копіювати зміни, незалежно від стану зеркалирования.
Цей прапор трасування можна застосовувати в SQL Server 2008, а для SQL Server 2005 він з’явився в складі Cumulative update package 2 для SQL Server 2005 Service Pack 2. Подробиці про прапор трасування № 1448 можна дізнатися у статті бази знань Майкрософт № 937041.
Зверніть увагу на потенційну небезпеку виключення затримок тиражування в реплікації. Для додатків відсутність затримок може мати вирішальне значення, і це може послужити причиною установки прапора трасування № 1448 при використанні зеркалирования з реплікацією. Треба розуміти, що існує ймовірність того, що використання цього прапора призведе до проблем в разі відмови Дзеркального відображення. Ці проблеми будуть розглянуті нижче.


Вплив відмови зеркалирования на роботу Агента читання журналу

Коли відбувається автоматична або ручна відпрацювання відмови Дзеркального відображення, Агент читання журналу повинен автоматично з’єднатися з новим основним сервером і продовжити копіювати транзакцій (якщо параметр-PublisherFailoverPartner був встановлений правильно, як це буде описано нижче). Є два випадки, коли цього може не статися. Перший, це коли відмова не може бути відпрацьований правильно, тому що дзеркальний сервер з якихось причин не може стати основним сервером. Другий випадок може статися тільки тоді, коли включений прапор трасування № 1448, про який тільки що згадувалося вище.
Коли Дзеркальне відображення не працює в режимі високої доступності або основний сервер був виставлений або ізольований, може виявитися, що на основному сервері є завершення транзакції, яких ще не були закріплені на дзеркалі. Якщо основна база даних стане недоступною, і відбудеться передача її ролі дзеркала, може статися втрата тих транзакцій, які були завершені на основному сервері, але ще не були закріплені на дзеркалі. Якщо до того ж включений прапор трасування № 1448, деякі з завершених транзакцій основного сервера можуть бути скопійовані, але ще не закріплені на дзеркалі. Це призведе до того, що стан метаданих про тиражованих транзакціях на розповсюджувачів буде випереджати реальний стан транзакцій на прийняв роль основної бази даних дзеркалі. Тобто Агент читання журналу вже передавав Розповсюджувач деяку кількість транзакцій. Після виявлення таких розбіжностей, Агент розповсюджувача видасть помилку: “The process could not execute” sp_repldone / sp_replcounters “on” GLADCHENKO-TEST “”. Крім цього повідомлення про помилку, будуть і деталізують ситуацію повідомлення, з яких можна дізнатися, який номер віртуального часопису намагався вважати Агент читання журналу. Виправити положення можна запустивши за допомогою системної процедури sp_replrestart примусову синхронізацію метаданих Видавця та Розповсюджувача. Однак, велика ймовірність того, що через розбіжності в метаданих частина не синхронізованих в результаті відмови основного сервера транзакцій вже може потрапити в бази даних Підписчиків. Це призведе до того, що Агент розповсюджувача теж припинить свою роботу, видавши повідомлення про помилку синхронізації даних. Оскільки в результаті збою синхронізації Розповсюджувач просто повторить зміни, що передаються не пройшли синхронізацію транзакціями, для подолання помилки роботи Агента розповсюджувача достатньо змінити його профіль на стандартний профіль з іменем: “Continue on data consistency errors”.



Як впливає порушення зеркалирования на роботу Агента читання журналу

Як уже зазначалося, у разі відмови Дзеркального відображення Агент читання журналу стане працювати з журналом транзакцій дзеркала основної бази даних. Можливість перемикання на який змінив свою роль новий основний сервер забезпечується параметром запуску агента-PublisherFailoverPartner. Поки між обома учасниками Дзеркального відображення діє партнерство, тобто вони продовжують працювати за схемою основна база – дзеркало основної бази, в разі відмови основної бази даних Агент читання журналу підключиться до прийняла роль основної, дзеркальної базі даних.
Якщо основний сервер буде недоступний дуже довго, краще всього видалити дзеркалювання, що дозволить уникнути проблем із зростанням журналу транзакцій дзеркальної бази даних. Якщо відмова призведе до того, що буде порушено партнерство основної та дзеркальної баз даних, Агент читання журналу буде продовжувати працювати з дзеркалом, поки ситуація з партнерством не відновиться або дзеркальне відображення не буде видалено. Якщо потім агента перезапустити, він спробує з’єднуватися з основною базою даних, яка більше не є видаваної базою даних, що призведе до збою реплікації. В хронології роботи Агента читання журналу з’являться повідомлення такого типу: “User-specified agent parameter values:-Publisher GLADCHENKO-TEST” “. Також будуть більш детальні повідомлення про відмову підключення. Для того щоб вирішити подібну проблему, і змусити Агент читання журналу продовжити свою роботу, створіть на розповсюджувачів псевдонім чинного сервера видавця.



Налаштування періоду зберігання Розповсюджувача

За замовчуванням на розповсюджувачів значення періоду зберігання транзакцій встановлено в нуль. Це означає, що транзакції очищаються відразу ж, як тільки вони будуть доставлені всім Передплатникам. При використанні Дзеркального відображення, в момент, коли через відмову Агент розповсюджувача перемикається на роботу із дзеркальною копією бази даних, потрібно щоб в базі даних розповсюджувача ще залишалися транзакції, які вже доставлені всім Передплатникам. Таке трапляється, коли дзеркалювання працює в високопродуктивному режимі, тобто передача транзакцій дзеркала йде асинхронно і стан дзеркала може сильно відставати від стану основної бази даних. Тоді, при необхідності додавання нового передплатника, якого небажано ініціалізувати, у Агента розповсюджувача повинна існувати можливість довантажити новому Передплатники ті транзакції, які на момент додавання передплатника ще не встигли закріпитися в дзеркалі. Інший такий випадок може статися при відмові сервера Видавця, коли дані в базі даних публікації більше не доступні, і це не дозволяє коректно ініціалізувати нову базу даних передплатника. В такому випадку, за відсутності транзакцій на розповсюджувачів, може відбутися втрата даних.
Щоб уникати втрати даних або тривалого простою в системі з дзеркалювання бази даних абонентів, рекомендується встановити адекватний період затримки транзакцій у розповсюджувача.
В наших прикладах ми будемо використовувати наступний варіант настройки параметра затримки розповсюдження:


Типи ручної синхронізації передплатника


Реплікація не підтримує автоматичний перехід на дзеркальне відображення підписаної на публікацію бази даних, тобто хоча дзеркалювання і можливо, Агент розповсюджувача не зможе переключитися на дзеркало після відмови основної бази даних Дзеркального відображення. Робота Агента розповсюджувача закінчиться помилкою відразу, як тільки він зрозуміє, що не може підключитися до бази даних, що є основною у партнерстві Дзеркального відображення. Віддзеркалення передплатника можна настроювати як до, так і після передплати. Однак, якщо планується ініціалізація передплатника моментальним знімком Публікації, ефективніше буде налаштовувати Дзеркальне відображення після ініціалізації бази даних передплатників.
У разі відмови Дзеркального відображення бази даних передплатників, необхідно перенаправити Реплікацію на дзеркальний сервер, туди, де тепер розташовується нова база даних передплатників, на новому основному сервері. Хоча цей метод вимагає заново оформити підписку, повної її ініціалізації не буде потрібно, і це завдяки новому типу синхронізації SQL Server 2008.
Всі методи ручної ініціалізації передплатника засновані на тому, що база даних наводиться в узгоджений з Видавцем стан, і це стає відправною точкою тиражування послідували за цим станом транзакцій Видавця. Після створення Підписки з ручною синхронізацією, Агент розповсюджувача повинен мати інформацію про те, які транзакції потрібно тиражувати, не втративши при цьому нові дані або зміни в наявних даних. В якості такої відправної точки використовується той номер LSN, який можна застосувати до відповідного методу ініціалізації. Наприклад, в методі із зазначенням параметра “replication support only “визначення LSN відбувається автоматично. Коли ж ініціалізація здійснюється відновленням з резервної копії, LSN береться з заголовка файлу резервної копії. У разі ініціалізації по LSN, необхідний номер віртуального часопису задається користувачем. Цей номер потрібно вказувати акуратно, тому що відносяться до нього транзакції повинні бути присутніми на цей момент в базі даних Розповсюджувача. Ось чому так важлива затримка транзакцій у Розповсюджувача, це дуже допомагає в разі відмови.



Приклади

Для демонстрації нових можливостей забезпечення доступності Реплікації SQL Server 2008 нам потрібно сервер Розповсюджувач, який в представленому нижче сценарії створення Розповсюджувача називається GLADCHENKO-VHD:




Дзеркальне відображення видається бази даних

Ми будемо використовувати сервер GLADCHENKO-TEST в якості основного сервера в дзеркалі і сервера видавця в Реплікації. Публікуватися буде база даних MIR, і вона ж буде мати своє Дзеркальне відображення. Публікація теж буде називатися MIR. Сервер, на якому розміщуватиметься дзеркало, називається GLADCHENKO-VHD і цей же сервер є в нашій тестовій топології реплікації Розповсюджувачем. В якості сервера передплатника буде виступати примірник GLADCHENKO-ASUB, на якому база даних підписки буде називатися MIR. Хоча реплікацію можна налаштувати за допомогою SQL Server Management Studio, ми будемо її налаштовувати за допомогою системних процедур Transact-SQL.
Для простоти демонстрації, всі облікові записи, від імені яких будуть запускатися служби, та імена входу, в контексті безпеки яких будуть виконуватися роботи на серверах, будуть зведені до однієї, доменної облікового запису користувача AG@troika.ru. Цей користувач є локальним адміністратором на всіх серверах, і включений в серверну роль sysadmins всіх зазначених вище серверів баз даних.



Крок 1. Створення Публікації

Публикуемая база даних MIR складається з чотирьох таблиць: PerformanceCounter, PerformanceSignature, PerformanceSignatureData і PerformanceSignatureHistory. Насправді, ці таблиці тиражуються засобами реплікації транзакцій з сервера, на якому розміщена база даних System Center Operations Manager 2007 SP1. Зроблено це для того, щоб емулювати роботу “живого” програми, оскільки дані моніторингу інфраструктури серверів надходять в ці таблиці постійно і без тривалих перерв. Саме цей потік реплицируемой інформації ми і буде реплицировать з сервера GLADCHENKO-TEST на сервер GLADCHENKO-ASUB.


Нижче представлений сценарій створення Публікації.

Спочатку, потрібно дозволити на розповсюджувачів ще одного Видавця. Для цього на сервері GLADCHENKO-VHD виконайте наступний сценарій:


Після цього можна приступити до створення Публікації, для чого на сервері GLADCHENKO-TEST потрібно виконати наступний сценарій:




Крок 2. Налаштування Доставки журналів для ініціалізації передплатника

На цьому кроці ми повинні підготувати базу даних на сервері передплатника, для того, щоб вона могла бути инициализирована з резервної копії. Оскільки потік транзакцій в базі даних нашого Видавця не переривається 24 години на добу, 7 днів на тиждень і 365 днів у році, нам буде зручно задіяти для цього механізм Доставки журналів.
Для включення Доставки журналів потрібно ініціалізувати базу даних Отримувача шляхом відновлення повної резервної копії бази даних Джерела. В нашому випадку, резервним сервером, а заодно і сервером передплатника буде комп’ютер GLADCHENKO-ASUB.
Робимо повну копію видається бази даних, для чого, на сервері GLADCHENKO-TEST виконуємо наступний сценарій:


Чекаємо отримання підтвердження успішності цієї операції, у вікні результатів з’явиться приблизно такий текст:


Після того, як копія успішно створена, потрібно її скопіювати на сервер Джерела. В нашому випадку, потрібно взяти файл з комп’ютера GLADCHENKO-TEST з папки C: MSSQLBACKUPMIR.bak і скопіювати його на комп’ютер GLADCHENKO-A, в папку: C: MSSQLBACKUPMIR.bak.
Після того, як файл резервної копії опиниться на сервері Отримувача, потрібно відновити базу даних Отримувача, що ми і зробимо на примірнику GLADCHENKO-ASUB, використовуючи наступний сценарій:


Після успішного відновлення бази даних, приступаємо до налаштування Доставки журналів між публікується базою даних на видавців, і щойно відновленої базою на передплатника. Детальний опис настройки Доставки журналів можна знайти у статті електронної документації: “Як включити доставку журналів (Transact-SQL)”. Створимо папку для обміну резервними копіями журналів транзакцій: C: MSSQLLogShip. На цю папку у облікових записів служб повинен бути повний доступ.
Далі, налаштовує базу даних Джерела разом із завданням резервного копіювання, а також записами локального та віддаленого моніторів:



Значення ідентифікаторів вийшли відповідно такі:


Якщо процедура відпрацювала без помилок, має з’явитися нове завдання, що передбачає один крок, в якому виконується наступна команда:

c:Program FilesMicrosoft SQL Server100ToolsBinnsqllogship.exe” -Backup 3346F94D-3DB6-4A56-BE99-DF2E60E0A25F -server GLADCHENKO-TEST”

Створюємо розклад для завдання резервного копіювання журналів транзакцій бази даних MIR:


Це розклад передбачає виконання завдання кожні 10 хвилин протягом доби.
Ми не плануємо створювати повне рішення Доставки журналів, наша задача тільки полегшити первісну ініціалізацію передплатника. Однак, давайте повністю слідувати згаданій вище інструкції BOL по включенню Доставки журналів.
Далі, нам потрібно на сервері Джерела задати базу даних Отримувача:


Після цього, на сервері Отримувача (Передплатник, в нашому прикладі це комп’ютер GLADCHENKO-ASUB) потрібно запустити процедуру, яка створить всі необхідні завдання із застосування резервних копій на базі даних Одержувача.



Отримуємо наступний набір ідентифікаторів:


Після цього, серед завдань примірника GLADCHENKO-ASUB з’являться два нові завдання, для яких визначені кроки, але ще не налаштовані розкладу їх роботи. Перше завдання з ім’ям: LSCopy_GLADCHENKO-TEST_MIR. У цього завдання лише один крок і він виконує наступний сценарій:


Ця інструкція копіює файли резервних копій журналів транзакцій з сервера Джерела на сервер Отримувача.
Додати типове розклад роботи цього завдання можна за допомогою наступного сценарію:


Друге завдання називається LSRestore_GLADCHENKO-TEST_MIR і призначене для відновлення скопійованих з Джерельну резервних копій на базі даних Отримувача. Єдиний крок цього завдання виконує наступну інструкцію:


Для додавання цього завдання розкладу запуску необхідно на сервері GLADCHENKO-ASUB виконати наступний сценарій:


І тепер залишилося тільки додати в Доставку журналів базу даних Отримувача, що можна зробити, виконавши наступний сценарій на сервері GLADCHENKO-ASUB:


Наступним дією в налаштуванні Доставки журналів буде підготовка сервера моніторингу, в якості якого буде виступати примірник GLADCHENKO-A. На цьому примірнику потрібно виконати наступний сценарій:


Після цього, потрібно включити ті завдання обслуговування Доставки журналів, які були відзначені як вимкнені. Це повинно привести до того, що Доставка журналів почне свою роботу і буде підтримувати актуальність бази даних MIR на сервері GLADCHENKO-ASUB в автоматичному режимі.
Тепер, коли прийде час створювати Передплату, достатньо буде ненадовго вимкнути клієнтів від бази даних Видавця, дочекатися або запустити вручну по черзі всі завдання Доставки журналів на Джерелі і потім на Одержувача, відключити всі ці завдання, і підготувати базу даних Отримувача до налаштування Підписки, виконавши цей сценарій:




Крок 3. Налаштування Підписки

Після успішної ініціалізації бази даних передплатників резервної копією, яку ми підтримували в актуальному стані засобами Доставки журналів, можна приступати до підписки на Публікацію. Для цього, на сервері GLADCHENKO-TEST потрібно за допомогою представленого нижче сценарію оголосити сервер і базу даних абонентів:


Всі подальші дії з оформлення Підписки потрібно виконувати на сервері GLADCHENKO-ASUB. Наступний сценарій створює Передплату на вимогу:


І нарешті, наступний сценарій потрібно виконати для створення завдання запуску Агента розповсюджувача, який буде доставляти зміни безпосередньо Передплатники:


Коли всі необхідні дії з оформлення передплати завершені, на сервер GLADCHENKO-ASUB можна повністю видалити Доставку журналів і подбати про видалення створених там завдань Доставки журналів.



Крок 4. Віддзеркалення публікується бази даних

В реплікації транзакцій існує дуже небезпечна точка відмови, це Видавець, про забезпечення високої доступності якого раніше було важко піклуватися. Тепер, для підвищення доступності Видавця, можна створити Дзеркальне відображення його бази даних та забезпечити автоматичне перемикання на дзеркальну копію в разі відмови. Для прикладу, ми спробуємо налаштувати Дзеркальне відображення бази даних Публікації на сервері Видавця і імітуємо відмову з перемиканням Агента читання журналу на дзеркальну копію публікується бази даних.

В останній з перерахованих вище статей говориться, що попередньо на дзеркальному сервері повинна бути відновлена ​​резервна копія основної бази даних, і всі наступні резервні копії журналу транзакцій, відновлені з використанням пропозиції WITH NORECOVERY. Як уже зазначалося вище, найкраще підготовку синхронної копії зеркаліруемой бази даних дозволяє зробити Доставка журналів. Оскільки в цій статті ми вже приділили багато уваги налаштуванню Доставки журналів, повторення цієї процедури для ініціалізації копії основної бази даних ми опустимо, будемо вважати, що всі ці процедури вже виконані. Копія бази даних на момент початку настройки Дзеркального відображення повинна знаходитися в актуальному по відношенню до основної бази даних стані.
В нашому прикладі, основною примірник і дзеркало настроюються так, щоб використовувати одного і того ж Розповсюджувача. У конфігурації Агента читання журналу ми змінимо настройки, щоб отримати потрібне нам поведінка агента в разі відмови сервера Видавця. Для цього на сервері Розповсюджувача GLADCHENKO-VHD потрібно встановити значення для параметра запуску Агент читання журналу-PublisherFailoverPartner, наприклад так:


Для прийняття змін профілю, потрібно перезапустити завдання Агента читання журналу.
Віддзеркалення публікується бази даних почнемо зі створення кінцевих точок зеркалирования. У першу чергу створимо кінцеву точку на видавців, це у нас комп’ютер GLADCHENKO-TEST:


На сервері Дзеркального відображення GLADCHENKO-VHD (це у нас Розповсюджувач) теж потрібна кінцева точка:


Перевірити, що кінцева точка була успішно створена і запущена, можна за допомогою наступної інструкції:


Одного створення кінцевих точок недостатньо, необхідно ще видати права на роботу з ними тим іменах входу, які будуть до них підключатися. Приклад відповідної інструкції нижче:


Після роздачі прав, потрібно оголосити учасників Дзеркального відображення. На сервері Дзеркального копії GLADCHENKO-VHD виконаємо наступну команду:


Після цього, з основного сервера GLADCHENKO-TEST запустимо симетричну команду:


Після цього має відбутися синхронізація основної та дзеркальної баз даних. Дзеркальне відображення має бути запущено. Якщо цього не сталося, спробуйте уважно вивчити повідомлення про помилку. Частіше все, причина в неузгодженості баз, тобто бракує останніх змін, які могли бути не перенесені Доставкою журналів, або щось подібне. Якщо причина не в цьому, спробуйте скасувати роль Дзеркала і повторити настройку спочатку. Сценарій скасування ролі Дзеркала представлений нижче:


Сучасні серверні операційні системи оснащуються вбудований брандмауер. Такі мережеві екрани теж здатні перешкодити підключенню до порту кінцевої точки. Перевірити можливість підключення з основного сервера до сервера дзеркальної копії можна за допомогою консольної команди операційної системи:



Крок 5. Перемикання Публікації на дзеркальну копію

Ну а тепер ми перейдемо до найцікавішого, заради чого були всі ці підготовчі дії. Отже, ми маємо реплікацію транзакцій між двома серверами, і Розповсюджувача на третьому сервері. Крім того, у нас налагоджено Дзеркальне відображення бази даних Видавця на сервер Розповсюджувача. Перед нами стоїть завдання – відновити реплікацію, яка була перервана внаслідок відмови Видавця. Доступність Видавця визначається Дзеркальним відображенням бази даних, на основі об’єктів якої створена наша Публікація. Відмова цієї бази даних розцінюється нами, як відмова Дзеркального відображення і приводом для ручний або автоматичної зміни ролі, коли дзеркальна копія стає основною базою даних.
Далі, імітуємо відмова основного сервера, який у нас є Видавцем:


У відповідь отримуємо повідомлення: “Nonqualified transactions are being rolled back. Estimated rollback completion: 100%”.
Після цього основна база даних Дзеркального відображення змінюється ролями зі своїм дзеркалом. Причому, на розповсюджувачів з’являється публікація і видно, що у неї вже існує Підписка (яку ми створювали на сервері GLADCHENKO-TEST). Зміни, які користувачі будуть робити в базі даних MIR після її переїзду на сервер GLADCHENKO-VHD, будуть спочатку закріплюватися в новому дзеркалі, у базі даних на сервері GLADCHENKO-TEST. Потім вони будуть потрапляти в базу даних Розповсюджувача, лічені Агентом читання журналу, який вміє поводитися до другого партнеру Дзеркального відображення у разі відмови основного сервера або основної бази даних.
Якщо на сервері GLADCHENKO-TEST запустимо наступну команду:


Ця команда поверне ім’я вихідного видавця для опублікованій бази даних, що бере участь в Дзеркальному відображенні. Ця функція показує початкового видавця опублікованій бази даних, і тому у нас вона поверне, і завжди буде повертати: “GLADCHENKO-TEST”.
Якщо після цього виконати на сервері GLADCHENKO-VHD ту ж саму команду: “ALTER DATABASE MIR SET PARTNER FAILOVER“, То все повернеться в початковий стан. Публікація знову буде розташовуватися на сервері GLADCHENKO-TEST.
На відміну від агентів реплікації, Монітор реплікації не дуже пристосований для відстеження роботи з переміщеної на дзеркальний сервер базою даних. Хоча його інтерфейс буде показувати переміщення Публікації, інформація про сеанси реплікації може вводити адміністратора реплікації в оману. Трассіровочние маркери теж не завжди допомагають контролювати процес реплікації. У такому режимі роботи реплікації найкраще контролювати самі дані, звіряючи останні їх зміни на видавця і передплатників.
Існує небезпека, що відмова основної бази даних призведе до виникнення проблем реплікації транзакцій. Це особливо актуально, коли не дотримується порядок первісної фіксації транзакції в дзеркалі базі даних. Якщо трапитися так, що кілька некоректних транзакцій будуть перешкоджати продовженню реплікації даних, можна примусово проігнорувати ці транзакції, що дозволяє зробити системна процедура sp_setsubscriptionxactseqno.



Висновки

Дзеркальне відображення можна використовувати для підвищення доступності Видавця в топологіях Реплікації транзакцій і Реплікації злиття. Якщо важливо, щоб клієнти продовжували отримувати можливість зміни даних в видається базі даних і автоматично переключалися на її дзеркальну копію у випадку відмови, застосування зеркалирования є виправданим.
У згаданому на початку цієї статті технічному документі Майкрософт: “ SQL Server Replication: Providing High Availability using Database Mirroring“Пропонується варіант вирішення для віддзеркалення баз даних Підписчиків. Там же ви знайдете аргументи для вибору такого рішення.
Для підвищення доступності бази даних Розповсюджувача існує поки тільки одне рішення – відмовостійка кластеризація.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*